A practical guide to securing macOS | Hacker News Reader

A practical guide to securing macOS

github.com

62 pointsmigueldemoura30 comments

There is some seriously folkloric jibber-jabber in here. For instance, you do not need to wait until after installation to enable FileVault because "there is more entropy available to the system". Nor can you test the security of a CSPRNG by running "ent" on it!

In the same vein: don't run out and sign up for a commercial OpenVPN hosting service, and for Christ's sake don't install AV software on your Mac.

I kind of love how this is like 19 pages of rubber chicken "defaults write" commands, followed by advice to use Transmission to torrent videos to watch in VLC.

Agreed. Some of those commands are actually deprecated, and it reads like voodoo incantations. I would actually advise people coming to this kind of thing to ignore most of it altogether.

(I wrote https://taoofmac.com/space/HOWTO/Switch in 2007, and over the years have always resisted contributions or “tweaks” of this sort since they often cripple the OS experience just for the sake of paranoia)

If you want to secure your Mac, install Little Snitch and don’t run stuff from outside the App Store. Period.

I thought I was a bit out of touch when the guide suggested to serve a macOS installation image over an HTTP server to a VMware VM for installing, but it sounds like this guide is just terrible.

Did you read the section carefully? It's serving the image over a local network interface. There's no risk to using HTTP in this context whatsoever.

The FileVault suggestion doesn't even match the page it links to. That other page specifically says that there's more entropy right after a reboot, while this page says simply to do it after initial installation, with no mention of uptime. Even if that other page is correct, the crucial piece of information was lost.

Do you know of a guide in similar spirit that is actually good?

Get an iPad with a keyboard. A guide to securing something like macOS would mostly turn it into that, except more annoying and less secure.

Noted! Where does a Chromebook stand in relation to iOS devices?

In general, materially less secure than an iPhone, but more secure than a Macbook or a Dell Windows/Linux laptop. We like Chromebooks a lot; more companies should issue them to non-engineer employees.

I'm not a security expert but people who are seem to view them positively. My (granted, rather glib) comment is really based on the uncontroversial and I feel fairly-easy-to-arrive-at-yourself-if-you-are-any-sort-of-software-person-and-think-about-this-for-two-minutes-in-the-shower notion that the basic operational model of a typical desktop OS is just not designed for very common current threats and trying to fix this retroactively is exceptionally difficult. Newer designs address some of these problems more directly and effectively.

Security-wise very good (comparable, maybe a bit better, because more locked-down). Of course, if you root the Chromebook all bets are off.

Privacy-wise, I'd pick Apple any day.

Why shouldn't you install AV software on a Mac? It's the least hardened of all current OSes. Luckily it's not attacked very often.

Because antivirus software itself is pretty terrible? https://arstechnica.com/information-technology/2017/01/antiv... seems a pretty decent overview.

It seems unlikely that that could be the case: that Macs, which have massive market share in the kinds of places that attackers would want to compromise, have the least hardening and also aren't attacked very often.

Can you clarify which other OSes you'd consider to be more hardened?

Where do we get the idea that attackers target Macs? The DNC hack, to pick one notable example, primarily targeted Windows computers.

> For instance, you do not need to wait until after installation to enable FileVault because "there is more entropy available to the system".

Looks like the author of the original Filevault paper thinks otherwise: https://github.com/drduh/macOS-Security-and-Privacy-Guide/is...

> Nor can you test the security of a CSPRNG by running "ent" on it!

Curious how then to test the PRNG output?

> In the same vein: don't run out and sign up for a commercial OpenVPN hosting service, and for Christ's sake don't install AV software on your Mac.

Ironically, the guide specifically says these exact two things ;)

> followed by advice to use Transmission to torrent videos to watch in VLC.

Transmission and VLC are better alternatives to most of the ad- and malware-ridden crapware out there, usually dominating search results. Of course, torrenting is bad for security and privacy - why don't you send a pull request with a strongly worded statement for effect?

That link does not say what you appear to think it says.

Ent will show a perfect distribution of bits on a counter ticking 1, 2, 3, ... through MD5; that construction will to all appearances be a deterministic random bit generator, but it obviously is not. If you're at the point where you're wondering why you can't use "ent" to test if a CSPRNG is seeded, you're probably too far out from understanding the issues to resolve this in the middle of a thread.

Why not offer a constructive suggestion for testing the PRNG quality on macOS? It seems like you know a lot on the topic, perhaps you could even send a few PRs to the guide ...

I'm not interested in contributing to your guide, sorry.

It isn't my guide, I'm only pointing out your comments could be put to helpful use instead of being bitter condescension only.

I am even less clear why we're discussing this, then. You understand now why you can't use "ent" to evaluate a modern CSPRNG, right? That's all I want to accomplish.

>a modern Apple Macintosh computer ("MacBook")

I don’t get this. Does the author think Apple only makes laptops now? Don't the iMac and Mac Mini qualify as modern?

The current Mac mini? Probably not...

Yeah, unintended joke there.

Ridiculous guide.

> Care should be taken when installing new software. Always prefer free and open source software (which macOS is not)

“Free” doesn’t have anything g to do with security and there are plenty of profound security flaws with all software — open source doesn’t make it inherently more safe.

One of the most serious security issues of the past few years came from OpenSSL/Heartbleed. Equifax was from unpatched Apache Struts — while the cause was negligence on the part of Equifax, happened due to a vulnerability in open source software. I am definitely not arguing that closed source is more secure, but I am arguing that open and closed source can have significant vulnerabilities. One is not inherently safer than another; it depends on how it is used. Apache Struts has a significant vulnerability before it was patched — which means that it was unsafe at some point. How many years was OpenSSL vulnerable before the exploit was discovered? Closed source certainly doesn’t fare much better, however implying that open source is always safer is just incorrect. I use “always” here because the author said to “always” prefer free and open source over closed source. His qualifier, not mine. Always is a very strong word. Many open source projects are often at the level of a hobby, with part time, occasionally unprofessional management and processes. Of course many closed source software also has unprofessional management and processes as well. I am simply disputing the implication that open source is always better: it’s not. Often and perhaps generally, but not always. I would trust Apple closed source more than some rubygem created and maintained by a single developer as a side project, with dependencies created by other hobbyists as a side project. A rubygem, for example, is dependent on the security competency of the weakest dependency. Often the projects are well secured — but definitely not always.

I am a big supporter of open source, but arguing that open source is always more secure is just factually incorrect. And the “free” aspect is a political benefit, not a security one.

The author also has a clear lack of understanding of how FileVault works as an example, which calls into question any other recommendations made in this guide.

I have been running Linux for some months now on my workplace MPB ever since the whole root with empty password fiasco. I don't trust macOS in any manner no matter how many fixes you try and apply to it, for some reason I feel like I simply can't trust macOS security wise for my part.

Only darn problem is I can't get my speakers working so I use Bluetooth headphones, but for a workmachine it's fine.

Desktop Linux is not exempt from security compromising mistakes either. There’s been plenty of equally bad ones, like pressing backspace 28 times to bypass Grub.

How does it fare when it comes to battery usage as well and keeping cool and not hot to the touch?

Goodness, I'm floored. There's an absolutely incredible amount of insight in that document. I can only imagine how many years of collective experiences and digging have resulted in this compilation.

I think it's probably worth approaching this very skeptically as a guide to improving the actual security of your Mac. Big swathes of it are really 'fun ways to nerdfiddle with your system' that don't actually do anything to make it more secure and quite a bit of the fiddling can arguably make it substantially less secure.

Reply on news.ycombinator.com