I like the title and premise of the article, but a list of tips with no description makes this feel like the standard "Tweak Ur Registry" article. I know OP is the author so I'm not trying to be a jerk, but I think adding details would improve things.
To give specific examples, it is totally unclear why the article recommends creating an unprivileged account (the default user account is already unprivileged without entering a password for anything and it is unclear how e.g. su admin -> sudo command is any more secure than sudo command). If someone has local access to the machine and the admin password, you're toast whether you are logged in as admin or as an unprivileged user. Is the risk malicious processes? Maybe there is some specific authentication procedure somewhere in MacOS where defaulting to an unprivileged user makes sense, but the site does not describe one.
Another example: The article recommends going into Gatekeeper and making it less secure. The default option, I believe, is to only allow App Store programs to launch without complaining. So "only App Store and code signed apps" is actually the more convenient, LESS secure option. I do it immediately because I don't want to be stuck with the App Store, which is useless. But turning off a security feature for convenience isn't hardening.
Later; on second boot, turn off apps that want access to Camera/Microphone/Full Disk. This seems straightforward enough and worth doing, except the first step in this list was to format your computer and if you've been following the steps thusfar, no apps have access to Camera, Microphone, or Full Disk. If I remember correctly, after installing new applications, they need to do a system API prompt to gain access to those things.
And then the back half is mostly about replacing Google stuff with privacy-focused alternatives. Privacy and security aren't diametrically opposed, but they aren't the same thing either. Also, despite arguing to opt-out of Google things, the earlier "change your DNS" tip recommends using Google DNS. Also, while I use a VPN for certain use cases, recommending installing a commercial VPN places an enormous amount of trust in the VPN provider -- it's true that they probably have more incentive than Google to respect your privacy from a logging perspective, but from a security point of view, it would seem it would be way easier to compromise a small VPN provider and try to MITM some of their connections without detection than to do the same to a commercial ISP.
So overall I think the article could use a title change to reflect that much of the advice is not MacOS-specific; fleshing out to make clear how some of the changes actually prevent against security threats; and more thought given to whether this is an article about privacy, security, or both, and thus whether readers should be given information about cases when the two might be at odds with each other.
(You may have very good answers to all of these things, but adding them to the article would be more useful than replying with them here)
Standard accounts are recommended by Apple itself as a best practice in lieu of administrator accounts. Also, sudo is not available in standard accounts which protects against any would-be vulnerability.
I updated the post regarding application sources.
I changed Google DNS with Cloudflare's 1.0.0.1. Others also mentioned the fact that suggesting a VPN provider is risky, so I also removed it.
I know some steps are redundant coming from a brand new installation, but not everyone is willing to format their drive right now, so those steps are included as well.
I didn't say for the standard account to use sudo; I said for it to use su to switch to an admin account, and then use sudo from the admin account -- as a point of illustration that if you have the admin password, it's game over, whether or not you're currently signed in as an admin or an unprivileged user.
Unless standard accounts don't have access to "su" at all, but I can't see that being the case without locking off access to terminal functions altogether, which would make macOS completely unusable for I would wager most of the people on this site. Looking at /usr/bin/, su is 0755 permissions.
Even if you didn't know the username of the admin account, /etc/passwd is 0644 so you could look it up as an unprivileged user -- again, unless macOS has some system level thing blocking all access to the terminal.
To give specific examples, it is totally unclear why the article recommends creating an unprivileged account (the default user account is already unprivileged without entering a password for anything
That's not correct. The first account created is an Admin account. It has more privileges than a Standard account.
Try the following in macOS High Sierra 10.13.6 as a Standard account then again as an Admin account. Open a terminal shell, and:
cd /Applications
touch fubar
That will succeed in one of the accounts and fail with
Permission denied
in the other account. It is left as an exercise for the user to figure out which is which. :)
It's true the group on /Applications is "admin", and thus mechanically there exist things that the default user account can do than an unprivileged account can't do. Not to put you on the spot, but, can you think of an example that isn't a toy example and actually reflects a potential harm? Okay, so I can write to Applications. But I can't use that ability to install an application that actually has permissions to do anything real, right?
Okay, so I can write to Applications. But I can't use that ability to install an application that actually has permissions to do anything real, right?
Apple's System Integrity Protection only applies to pre-installed programs. I just now screwed around with the following object and the system let me do it:
/Applications/Firefox.app/Contents/MacOS/firefox
If I can do that from Terminal, then what's to stop some malicious JavaScript from doing that IRL? Once user installed programs in /Applications are fair game, it becomes much easier to subvert macOS.
By allowing untrusted binaries, you're essentially saying to the world "Go ahead, run any binary you want on my computer as an unprivileged user. macOS will protect my system from you".
Not me. I'd rather make it just that much more difficult to keep malware off my computer. Setting aside everything else, the whole meltdown/spectre thing is enough for me to want to minimize the random untrusted code I run.
And even if macOS itself is safe, those random binaries can still exfiltrate all my user data as an unprivileged user. They can mine Monero. They can participate in a botnet. All of that is possible without subverting macOS.
Thanks to the author for compiling and sharing this guide.
Two of the recommendations have the potential to make your Mac less secure:
1. > …install an ad blocker (I recommend uBlock Origin)
While uBlock Origin has a great track record, it requires these permissions:
* Access your data for all websites
* Read and modify privacy settings
* Access browser tabs
* Access browser activity during navigation
That is a lot of exposure, especially if a bad actor managed to take over the extension, e.g.,
In August 2017, the very popular and widely recommended Web Developer extension for Chrome was hijacked. The developer fell for a phishing attack, and the attacker uploaded a new version of the extension that inserted more advertisements into web pages. Over a million people who trusted the developer of this popular extension ended up getting the infected extension. As this is an extension for web developers, the attack could have been a lot worse—it doesn’t appear that the infected extension functioned as a keylogger, for example.https://www.howtogeek.com/188346/why-browser-extensions-can-...
2. > Consider tunneling your traffic through a VPN when connected to untrusted networks (I recommend rolling your own VPN server, or else I really like Mullvad, see ThatOnePrivacyGuy’s VPN comparison)
Again, Mullvad appears to be one of the best VPN services, but connecting to third party VPNs creates new risks and may not provide the security you expected:
Those permissions are necessary for any blocker to perform its function. And while the threat models for blockers and vpns are different, I agree that I would trust a local blocker [threat: extension hijack via auto-update; mitigation: very public source and update policy] much more than I would trust any third party vpn [threat: their 'no logging' policy is insufficient or they don't honor it; mitigation: 'we promise, mmkay?']
A self-hosted vpn would be better, but has its own problems [threats: you're uniquely identifiable by your vpn ip, you don't update fast enough to avoid security breaches, you don't configure it correctly and expose yourself to additional security breaches]. Given the difficulty of hosting and managing your own vpn infrastructure I couldn't recommend it for almost anyone.
Content Blocking Extensions are pretty neat from a privacy perspective, but they're quite limited in functionality since they're basically glorified block lists (why you'd pay $2 for a list that's freely published is another question) and it requires support from the platform. uBlock supports a lot of features that CBE apps can't.
uBlock origin has a lot of features beyond being a simple ad domain blacklist. You can remove elements from websites at wish. It can spoof information about which fonts you have installed to websites, block WebRTC and more. A pure ad blocker with a smaller feature scope will require fewer permissions. While I have not read the source code my self I have a hard time believing that uBlock origin is not limited to the lowest amount possible of required permissions to do the job it does.
2: Modifying system level settings, even with an admin account, requires re-authentication. Mac OS prompts for passwords more often than Vista-era UAC prompted for a go/nogo. What's the purpose of the second user account? An "admin" account os Mac OS is not equivalent to root.
6: Strictly lowers your security since it means now native apps outside the store can run. Store apps have the highest requirements for sandboxing and other system level protections. This might be a usability step, but it has no place in a "hardening" article.
9-10: Redundant - you'll be asked if you want to enable reporting and location services on first boot.
11: You are never supposed to use different DNS providers between your primary and secondary, this can lead to hard-to-troubleshoot intermittent errors. Given the lack of recommending Chrome over Firefox, and the anti-Google stuff in the second step 4, and given Firefox's poor security history, it is strange that they recommend using Google DNS servers. Either way - use 1.0.0.1/1.1.1.1 or 8.8.8.8/8.8.4.4, don't mix them.
13: Spotlight indexes belong to the user. There is literally no security gained by "blacklisting sensitive directories", as if your account is compromised, both your spotlight index and those 'sensitive directories' are.
17: What security is gained by denying the ability of the OS to ask me if I trust a specific cert or not?
Ssh and p2p stuff are two examples off the top of my head. For p2p, you lose the ability for peers to initiate a connection with you if you block incoming traffic.
Are you running a server on your mac? If not, then who do you want to allow remotely connecting to your mac? Connections established/initiated by your machine still go through when you enable that setting.
I'd also consider adding a firmware password if you're at all worried about unattended physical access to your mac. It will prevent your OS/boot order from being tampered with, preventing a variety of attacks.
Less important with T2 on the latest macs, but still worth considering.
Very interesting! I’m reading it quite thoroughly so I don’t have any immediate thoughts but this did remind me of another similar guide in the spirit of things if you haven’t seen it:
I was inspired in part by this guide, it's very full-featured, but I wanted to give the community a simplified version of it, it contains too much text/bloat/detail which, don't get me wrong, it's awesome for those who want to learn about macOS security, but the everyday user would rather have a simple checklist.
I put it as a failover for Cloudflare's 1.1.1.1 because they both support DNS over TLS and DNS over HTTPS and even though DNS servers are rarely down, I didn't want to recommend a single point of failure with Cloudflare's 1.1.1.1 and 1.0.0.1, but you are free to choose whatever resolvers you want.
It’s ironic to see a guide to securing anything recommend using plaintext MITM-able DNS rather than instructing users to build and configure a safe DNS-over-HTTPS resolver to the exact same IPs.
It's not enough for the servers to support it, the resolver has to actually use it too. Your guide instructs people to configure the Cloudflare / Google DNS in system preferences, which will query those via plaintext DNS on port 53.
GP's point is that if you want to secure DNS, it's a bit more involved, hence the build in "instructing people to build and configure a HTTPS resolver".
Give me a good reason why defaults chosen by a macOS user would be more secure than those chosen by a security team working full time on developing the system.
This article isn't even that bad if you are willing to make your system less practical, but even here you are potentially making your system less secure as suggested in some other comments.
Because the security team doesn't choose the defaults. They have some input, but other teams also have input and will cause settings to be enabled that have negative security consequences. E.g. "tell Apple everytime you connect to a wifi network to check for captive portals".
Because the security team's goal is MacOS as a whole, and not your individual computer. So they have an incentive to enable things like automatic bug reports that harm your personal security but contribute to the overall security (not to mention usability) of the MacOS ecosystem.
Because security and usability are inherently at odds, and Apple has always erred on the side of usability, until the security downsides are simply to great to ignore. This has been the pattern for every single security improvement in Mac OS X.
If you understand the tradeoffs, you can do a wide variety of things to massively increase the inherent security of your Mac by changing system and app configurations.
You're putting the macOS team on a pedestal. Accounts I read elsewhere are it's a pretty barebones crew and I bet there are many components sitting unmaintained release to release with bad defaults to boot.
> An attacker could trigger the utility and direct a Mac to a site with malware without user interaction, so it's best to disable this feature and log in to captive portals using your regular Web browser, provided you have first disable any custom dns and/or proxy settings.
I consider Apple to be the only respectable bigtech left, that said, I can't avoid to make the following reasoning:
- Apple is US-based, therefore subject to PRISM (and any other surveillance program we don't know about)
- There's a long record of companies going rogue on users for legal reasons
- Apple makes macOS
- macOS is not fully open-source
This means that there's the possibility of macOS turning it's back on users, and that would make me refuse macOS if I were the target of someone with enough money and time.
On why OpenBSD, it's because of it's excellent track of security vulnerabilities (only 2 in 20+ years).
Tails and Qubes are also great, but they haven't been out there for as long as OpenBSD has and I think the BSDs deserve some more love.
Edit: CoreOS has some great security features too, such as a read-only /usr. I also believe ChromeOS has some similar features.
This is great, but does anyone have a good in-depth reference for administering MacOS systems? I constantly have difficulties doing in-depth analysis and administration of MacOS systems, and that's really only because I just don't know where to go for good information.
Yep, but why can't I run Night Shift without locations services? My time zone is, after all, known … And I would even enter my exact location if possible.
(I don't really mind location services with regard to Apple, however, for an iMac, location services are pretty useless.)
For many years, I was annoyed whenever I saw one of these “hardening” or “securing” guides (for any platform), without knowing why. But I eventually figured it out: If you have to do extra steps to your system to “harden” it or otherwise secure it, it is either a toy system not meant for production use, or it is an old system which has ossified and needs hardening because of a lack of upstream updates and maintenance. And it annoyed me because you shouldn’t be running any such systems in production anyway – “hardening” such systems is not tenable in the long run.
The fact that macOS has been neglected by Apple should not be news to anyone (earlier it was especially obvious for the Unix parts, but lately it has been all of it), but this is another sign of it.
You’re talking nonsense. There have been hardening guides for macOS for ages. Linux too.
In reality, security is a sliding scale between “everything is root and there’s no password lmao” and “so secure it’s impossible to actually do anything useful”. Different risk levels are appropriate for different users in different situations. For example, this guide talks about turning off a bunch of features that I use a lot - like continuity and handoff between iOS and macOS. These features might feasibly be a security burden—as in, they might increase the attack area, despite having no known vulnerabilities—but in exchange they improve usability.
I can’t reasonably agree that this is some kind of indication of failure. MacOS is a consumer operating system; it seems like the security it offers is generally reasonably optimised for that role.
I don't think he meant "failure" so much but rather criticise the fact that operating systems sometimes deliver not-the-greatest defaults. To be fair, macOS has a very strong default set, this just takes it the extra mile.
It's been a truism in security that the less usable you make your systems, the more your users will work around it, thereby defeating the security. E.g. passwords written stickies to defeat password expiration rules.
There's a sweet spot for security for the average user, where it's secure but usable enough that the user doesn't attempt to defeat it. For users who are willing to put up with less usable systems, more security can be had.
Curious, what are some opinions of those "endpoint security" solutions that companies make engineers install on their laptops? Effective, intrusive? What's your experience.
They can be effective or intrusive, it depends on the implementation. I've used one (Fleetsmith) on MacOS and configured it to be non-intrusive. It was able to enforce some of the items in this blog post (encrypted drives with key escrow, screen saver with password time), and it also was able to require latest updates for some software such as Chrome, Docker, Slack, etc.
We don't use this for engineers only, we use endpoint security for every laptop in the company. We did decide to set up a different profile for engineers though, and remained thoughtful about what to enforce. Additionally, we set up a canary profile to roll out new changes or policies and listen to feedback and problems before blindly rolling out changes to every developer machine in the company.
Recommending Google's and Cloudflare's DNS is not privacy friendly at all. Even when you use an VPN and push all your domain name requests to either or.
To give specific examples, it is totally unclear why the article recommends creating an unprivileged account (the default user account is already unprivileged without entering a password for anything and it is unclear how e.g. su admin -> sudo command is any more secure than sudo command). If someone has local access to the machine and the admin password, you're toast whether you are logged in as admin or as an unprivileged user. Is the risk malicious processes? Maybe there is some specific authentication procedure somewhere in MacOS where defaulting to an unprivileged user makes sense, but the site does not describe one.
Another example: The article recommends going into Gatekeeper and making it less secure. The default option, I believe, is to only allow App Store programs to launch without complaining. So "only App Store and code signed apps" is actually the more convenient, LESS secure option. I do it immediately because I don't want to be stuck with the App Store, which is useless. But turning off a security feature for convenience isn't hardening.
Later; on second boot, turn off apps that want access to Camera/Microphone/Full Disk. This seems straightforward enough and worth doing, except the first step in this list was to format your computer and if you've been following the steps thusfar, no apps have access to Camera, Microphone, or Full Disk. If I remember correctly, after installing new applications, they need to do a system API prompt to gain access to those things.
And then the back half is mostly about replacing Google stuff with privacy-focused alternatives. Privacy and security aren't diametrically opposed, but they aren't the same thing either. Also, despite arguing to opt-out of Google things, the earlier "change your DNS" tip recommends using Google DNS. Also, while I use a VPN for certain use cases, recommending installing a commercial VPN places an enormous amount of trust in the VPN provider -- it's true that they probably have more incentive than Google to respect your privacy from a logging perspective, but from a security point of view, it would seem it would be way easier to compromise a small VPN provider and try to MITM some of their connections without detection than to do the same to a commercial ISP.
So overall I think the article could use a title change to reflect that much of the advice is not MacOS-specific; fleshing out to make clear how some of the changes actually prevent against security threats; and more thought given to whether this is an article about privacy, security, or both, and thus whether readers should be given information about cases when the two might be at odds with each other.
(You may have very good answers to all of these things, but adding them to the article would be more useful than replying with them here)