
Hardening macOS - ricardbejarano
https://blog.bejarano.io/hardening-macos.html
======
miles
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-...](https://www.howtogeek.com/188346/why-browser-extensions-can-be-
dangerous-and-how-to-protect-yourself/)

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://gist.github.com/joepie91/5a9909939e6ce7d09e29)
[https://news.ycombinator.com/item?id=16371030](https://news.ycombinator.com/item?id=16371030)

~~~
infogulch
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.

~~~
miles
> _Those permissions are necessary for any blocker to perform its function._

Not blockers for Safari like Wipr that use Content Blocking Extensions:
[https://giorgiocalderolla.com/wipr.html](https://giorgiocalderolla.com/wipr.html)

~~~
infogulch
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.

~~~
ianai
Especially when you can block many things on a local router.

------
Karunamon
There are some issues here...

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?

------
konart
>Go to System Preferences > Security & Privacy > Firewall > Firewall Options…
and check Block all incoming connections

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.

~~~
pfschell
What do you need it for that it actually prevents? I've used this for close to
a decade, and it has never broken anything. Sounds like FUD mate.

~~~
idle_zealot
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.

~~~
staticassertion
Why not block all incoming connections except on those ports?

~~~
konart
That's what you usually do (preferably on your router if you are using one).

But the article says "and check Block all incoming connections". That's my
point.

------
mjlee
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.

------
no_wizard
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:

[https://github.com/drduh/macOS-Security-and-Privacy-
Guide](https://github.com/drduh/macOS-Security-and-Privacy-Guide)

Very good also if you liked this

~~~
ricardbejarano
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.

Thanks for the kind words!

------
zakk
Thanks for the nice guide. I wouldn’t use Google DNS as a default though, they
don’t have a good record when it comes to respecting privacy.

~~~
floatingatoll
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.

~~~
ricardbejarano
IIRC, Google DNS and Cloudflare DNS both support "DNS over TLS" and "DNS over
HTTPS", that's the reason I recommend them in the first place.

~~~
vladvasiliu
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".

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-...](https://blog.because-
security.com/t/use-cloudflare-dns-with-tls-on-mac-os-x-gui-and-cli-way/315).

------
drtse4
For those who want more: [https://github.com/drduh/macOS-Security-and-Privacy-
Guide](https://github.com/drduh/macOS-Security-and-Privacy-Guide)

~~~
ricardbejarano
One of my sources was this guide, it's great.

------
comboy
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.

~~~
chmars
Just one example: In Safari, Open 'safe' files after downloaded is enabled by
default …

(Yep, 'safe' files, not safe files, it's almost like a long-running joke by
some Safari developer.)

~~~
ricardbejarano
Thanks for pointing that out! I can't believe I missed that!

------
weeks
"I recommend rolling your own email server"

This is actively harmful advice. Do not roll your own email. Use a well-known
provider with a solid security track record.

------
TazeTSchnitzel
Why disable the captive portal detection? Is macOS detecting MITMing for you
bad?

~~~
ricardbejarano
> 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.

See [https://github.com/drduh/macOS-Security-and-Privacy-
Guide#ca...](https://github.com/drduh/macOS-Security-and-Privacy-
Guide#captive-portal)

~~~
TazeTSchnitzel
Ah, I suppose if you're using a VPN that makes sense.

------
opsroller
Or you know, you could just download the DOD profiles from their website.

~~~
ricardbejarano
Could you elaborate?

~~~
nixgeek
[https://iase.disa.mil/stigs/os/mac/Pages/index.aspx](https://iase.disa.mil/stigs/os/mac/Pages/index.aspx)

------
doctorless
“Warning: if your threat model is a state-sponsored agency, you are better off
without macOS, see OpenBSD.”

While my excessively paranoid self is inclined to agree, I am curious as to
the author’s reasoning here.

~~~
ricardbejarano
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.

------
ravivyas
That is a comprehensive list, which I know most normal folks could never do.

More importantly, how secure are my parents on iOS devices vs the Mac for most
of the vectors described here?

------
notafraudster
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)

~~~
ricardbejarano
Thanks for the feedback!

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!

~~~
notafraudster
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.

~~~
miles
> _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_

Users don't appear in /etc/passwd on Mac OS X
[https://superuser.com/questions/191330/users-dont-appear-
in-...](https://superuser.com/questions/191330/users-dont-appear-in-etc-
passwd-on-mac-os-x)

------
chris_wot
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.

~~~
ricardbejarano
The sources I recall while writing this:

\- [https://github.com/drduh/macOS-Security-and-Privacy-
Guide](https://github.com/drduh/macOS-Security-and-Privacy-Guide)

\- [https://github.com/CISOfy/lynis](https://github.com/CISOfy/lynis)

\-
[https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.s...](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-179.pdf)

\-
[https://help.apple.com/machelp/mac/10.12/index.html#/mh11389](https://help.apple.com/machelp/mac/10.12/index.html#/mh11389)

\-
[http://newosxbook.com/files/moxii3/AppendixA.pdf](http://newosxbook.com/files/moxii3/AppendixA.pdf)

Hope it helps!

------
ianlevesque
See also (slightly dated)
[https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.s...](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-179.pdf)

------
chmars
Interesting: If I deny System Services location access for 'Setting Time
Zone', my iMac 5K changes the color temperature …

(Security & Privacy / Location Services / System Services / Details / Setting
Time Zone)

~~~
ricardbejarano
It's due to Night Shift, set it to a custom schedule (or enable location
services but only for time zone settings)

~~~
chmars
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.)

~~~
saagarjha
You can use Night Shift, just not with a dynamically changing schedule.

------
teddyh
The appearance of this is significant.

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.

~~~
matthewmacleod
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.

~~~
ricardbejarano
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.

------
winrid
Curious, what are some opinions of those "endpoint security" solutions that
companies make engineers install on their laptops? Effective, intrusive?
What's your experience.

~~~
marcc
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.

~~~
chmars
Thanks for mentioning Fleetsmith, I have been looking for such a service for
some time!

(Jamf Now usually gets mentioned but it's not my thing …)

------
mproud
Oh come on. The article suggests disabling features altogether because of
their possibility of becoming insecure? Then how about these things:

• Don’t use any messenging apps.

• Remove your email accounts.

• Turn off Wi-Fi.

------
tom4000
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.

------
mvanbaak
Please provide a list of 'defaults write' commands to do this. I got tired of
clicking all this after the third bullet point

------
dlfharris
Is Brave browser not recommended for a reason?

