Hardening macOS
blog.bejarano.io
blog.bejarano.io
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)
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
Permission denied
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
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.
No. Just no.
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.
Again, thanks for the feedback!
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.
Users don't appear in /etc/passwd on Mac OS X https://superuser.com/questions/191330/users-dont-appear-in-...
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:
Don't use VPN services. https://gist.github.com/joepie91/5a9909939e6ce7d09e29 https://news.ycombinator.com/item?id=16371030
I agree with your points and I updated the post so.
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.
Not blockers for Safari like Wipr that use Content Blocking Extensions: https://giorgiocalderolla.com/wipr.html
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?
Thanks, but no, I need this one.
The whole guide is for people feeling paranoid.
PS: I'm not trying to say you should not make your machine more secure, but blocking\locking "all the stuff" is not a sane option either.
But the article says "and check Block all incoming connections". That's my point.
Less important with T2 on the latest macs, but still worth considering.
https://github.com/drduh/macOS-Security-and-Privacy-Guide
Very good also if you liked this
Thanks for the kind words!
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.
Thanks for the feedback!
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".
I don't actually use this, as my home router handles DNS over TLS for everything, but a quick google search turns this up: https://blog.because-security.com/t/use-cloudflare-dns-with-....
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.
(Yep, 'safe' files, not safe files, it's almost like a long-running joke by some Safari developer.)
They've missed a few things. This is a memorable one: https://news.ycombinator.com/item?id=15800676
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.
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.
This is actively harmful advice. Do not roll your own email. Use a well-known provider with a solid security track record.
See https://github.com/drduh/macOS-Security-and-Privacy-Guide#ca...
While my excessively paranoid self is inclined to agree, I am curious as to the author’s reasoning here.
- 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.
More importantly, how secure are my parents on iOS devices vs the Mac for most of the vectors described here?
- https://github.com/drduh/macOS-Security-and-Privacy-Guide
- https://github.com/CISOfy/lynis
- https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.s...
- https://help.apple.com/machelp/mac/10.12/index.html#/mh11389
- http://newosxbook.com/files/moxii3/AppendixA.pdf
Hope it helps!
(Security & Privacy / Location Services / System Services / Details / Setting Time Zone)
(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.
I envy OpenBSD's way of delivering a secure system out-of-the-box, instead of everyone else's "pretty much secure but...".
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.
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.
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.
(Jamf Now usually gets mentioned but it's not my thing …)
• Don’t use any messenging apps.
• Remove your email accounts.
• Turn off Wi-Fi.