tptacek's criticisms are quite valid. However, "it's not good" seems oversimplified to me? I found lots of interesting information in this.
For example: information about the activation process for Macs, importance of setting a firmware password, disable some of the Spotlight services, and binary whitelisting through Santa. The repo also has the most comprehensive discussion I've seen about evicting FileVault keys from RAM on sleep: https://github.com/drduh/macOS-Security-and-Privacy-Guide/is...
Also, I'm not sure if this has been changed more recently than the comment you linked, but it seems like they actually don't recommend AV software anymore: "Therefore, the best anti-virus is Common Sense 2020. See discussion in issue #44."
I grant you that having someone follow this top to bottom might be bad, but to say "it's not good" seems to both lack nuance and also to discard some useful, hard work done in good faith.
A guide that can't be used safely by non-specialists while being aimed at them is not a good guide. It is a very simple conclusion with the added benefit of also being almost tautologically true.
The thing probably does contain a bunch of interesting information but it's not good at its stated purpose.
I love how this is offered fully in Chinese, and that reminds me of something. Every operating system like macOS has its place, no matter what one's threat model is. Don't just say 'move to Linux if you're really worried about security or privacy'.
Maybe someone in China or another authoritarian regime needs to look less suspicious on the outside by using macOS instead of Linux. For those people, this information is gold.
BTW, this is indeed the famous Github guide many of us have known for years, just now renamed and updated.
> Maybe someone in China or another authoritarian regime needs to look less suspicious on the outside by using macOS instead of Linux.
There's even an official Chinese Ubuntu spin. You're probably more suspicious with macOS, since these tend to be in the hands of high-profile businessmen and such.
In an authoritarian regime everyone looks suspicious because by definition the government trusts no one except themselves and even then it's not very true.
> Don't just say 'move to Linux if you're really worried about security or privacy'.
In China Linux rocks exactly in security & privacy like "lone star". Windows - shitload of telemetry by design; macOS & iOS - there's no secret anymore about Chinese iCloud & Chinese government.
If I were in China doing anything even slightly over the line, windows telemetry would be the least of my worries, keeping my vital organs and freedom would be at the top.
I'm somewhat surprised that this guide recommends Homebrew. I agree that using a package manager is a good way to keep software updated from a central, trusted repository--always a good thing--but Homebrew makes a number of trade-offs for convenience instead of security. MacPorts has most of the same common packages and doesn't mess up filesystem permissions like Homebrew does. If I remember correctly, the all-inside-the-home-directory technique used in this guide is unsupported by the Homebrew developers as well.
Thank you for this comment, and thanks to saagarjha for the blog post. I’ve had the feeling over the past year or so, that Homebrew is getting in the way of other steps that I’d like to take to secure my system.
(And I’ve been confused by the policy of “absolutely no root until something goes wrong; then we tell you to use sudo to run terrifyingly broad commands.”)
> MacPorts has most of the same common packages and doesn't mess up filesystem permissions like Homebrew does.
This is more a convenience than security question. I understand that Homebrew can install not only open source command-line tools, but also third-party binaries (via `cask`) and Mac App Store apps (via `mas`), and that all three types of software can be installed, updated, or removed via the same `brew` command or synced `Brewfile`.
Does MacPorts offer something similar? In that case, how is its coverage compared to the systems above?
(Context: I’m a long-time Linux user in the process of migrating to macOS.)
As I understand it, MacPorts is a fair bit more limited in that regard. For my purposes, I haven't found a need for the ability to install third-party binaries and Mac App Store apps through my package manager, since every third-party binary I have installed includes its own updater and the Mac App Store updates apps as well. I can see how setting up everything in one place could be useful, but I haven't run into a situation where it has been useful in my macOS usage quite yet.
Homebrew and MacPorts are philosophically pretty different from each other and neither can be directly compared to Linux package managers. I think you'll find the solution of MacPorts for OSS command-line tools + Mac App Store for Xcode and other random stuff + third-party installers for things like Sublime Text and Microsoft Office works pretty well in practice, although it's not quite as clean as using one package manager for everything.
> I can see how setting up everything in one place could be useful, but I haven't run into a situation where it has been useful in my macOS usage quite yet.
What appeals to me personally is having a list of apps (the “Brewfile”), that I can sync between my work and personal computer via my dotfiles, and let the system mirror what apps are installed on both devices (“brew bundle” installs or uninstalls apps based on that app list). And that if I need to replace my machine, I can just sync my dotfiles to new machine and let Homebrew autorestore apps, including third-party apps and things from App Store.
I’ve tried some “declarative package managers“ before and enjoyed that, so when articles like this [1] said Homebrew can apparently do the same across open-source software, Mac App Store apps, and third-party apps, via a single synced Brewfile, that seemed interesting. The same Brewfile also appears to be usable on Linux for open-source apps (via Linuxbrew).
But I don’t yet have any experience with it, so I have no idea how well it works or whether it’s worth it. If we disregard third-party apps, do you know if MacPorts has an equivalent to Brewfile?
Somewhat, it does have a way of recreating your current setup (generally intended to be used across OS upgrades, but doesn't have to be limited to that usecase): https://trac.macports.org/wiki/Migration
Cask doesn't just handle packaged GUI apps, but also binary distributions of command-line apps that are hard to compile from source; or are proprietary/closed-source; or are actually sandboxed point-release distributions of {software written in a scripting language + its vendored deps + its runtime}. None of these will have any sort of updater built into them, but they'll all be updated through `brew cask upgrade`. (Any random Golang binary you might download off of Github? Before I even Google it, I type `brew search $whatever` into my terminal. Way easier to keep updated than even the `go get`-installed version, and also doesn't require that you have go installed.)
As well, even for GUI software that has Sparkle-like update support built in, if you don't use it very often, it won't get updated until the next time you launch it, and even then will only get updated if you're online at the time you launch it. This leaves you vulnerable in the specific case that the software is offline but opening an untrusted document (e.g. one you originally downloaded from the network.) The vulnerability in the app will likely be exploited immediately upon launch of the app, before the app gets to update itself. Doing a periodic `brew cask upgrade` also takes care of these (at the annoying expense of constantly upgrading apps that put out a new release every few days. Looking at you, Etcher.)
Also, besides upgrading, brew is useful just for grabbing all this third-party software without having to run hither and thither to find it. Sometimes the only web route to downloading a piece of software involves one of those skeezy download-hosting sites that redirects you through several ad walls, or requires that you make an account to download. With brew, you skip all that — just e.g. `brew cask install megasync` or `brew cask install plex-media-server`.
Also, brew suppresses any interactive GUI elements of the install/update process, if it possibly can. `brew cask install java`, besides skipping navigating through ten pages of links to links to TOS agreements to links on Oracle's website, also does not summon forth the Java installer GUI, but rather does everything in the command-line. (As far as I can tell, it doesn't install the Java updater, either; brew takes over responsibility for upgrading Java, so there's no need for an independent update checker.)
And there's also `brew cask zap`, which is an uninstaller that actually cleans up after the program, removing not only the application itself, but also all the stuff the app either installed, or later created at runtime, under /Library. This takes advantage of Apple .pkg BOM manifests if it can; but also has a manually-specified section in brew formulae, to allow it to zap away the cruft of apps that don't bother to keep track of themselves (e.g. Zoom, zerotier, usboverdrive, switchresx, etc.)
There's also `brew services` — brew packages (and I think brew casks, too) can install launchd unit-file templates; and you can then enable/disable these (i.e. [un]link them in ~/Library/LaunchDaemons), and manage the lifecycle of (start/stop/status) these (i.e. call into launchctl), through `brew services`.
(My own `brew services` currently contains: docker-machine, ifs, postgresql, reds, ssh-askpass, unbound. I use it quite a lot! Much less arcane than launchctl itself.)
-----
Oh, and disregarding all that, and addressing the assumption underlying your arguments (that homebrew "messes with the filesystem"): you can keep a brew installation that doesn't mess with the filesystem at all (see https://docs.brew.sh/Installation#untar-anywhere).
It's just that doing so will confuse exactly the type of pre-compiled CLI (or POSIX-y GUI) tools that `brew cask` is meant to help you install. These would be the ones where important paths (e.g. $PREFIX/etc, $PREFIX/share) are burned into the compiled binary, and so by necessity one fixed prefix has to be selected to burn in at compile time. Usually the fixed prefix chosen is `/usr/local`.
People install Homebrew to /usr/local (or rather, allow Homebrew to link casks into /usr/local) because it's better than the alternative — where that alternative isn't "all that stuff gets installed in a clean way instead" but rather "all that stuff makes a mess of /usr/local on its own, but now there's nothing watching it do it, so your /usr/local is now a permanent, opaque mess rather than a set of managed overlays." (Ever install LaTeX on macOS from its upstream download? Or how about calibre? PostGIS? R? They all make exactly these kinds of messes in /usr/local. At least, by letting brew install them, you can now upgrade or remove them; and it'll notice if one package's files are trampling over another's.)
mas is independent of Homebrew and available on MacPorts: https://github.com/macports/macports-ports/blob/master/sysut.... There's discussion on the mailing list on whether MacPorts should have a sort of "caskroom" type thing–currently it tries to avoid this except in cases where it's impractical to build from source (e.g. Java).
MacPorts is an implementation of BSD family ports package managers. I don't know much about modern ports, but when I was an active FreeBSD user, it did not install binaries, compiling the package with all dependencies instead - that is why it offers only open-source packages by definition.
Darwin itself a BSD family, so I guess MacPorts were the first package manager implementation. However, proprietary applications is a common thing on Mac, unlike Linux/BSD systems, that is why Homebrew offers much wider choice of packages.
MacPorts offers prebuilt binaries for many packages these days, although you can generally install them from source if you so wish (and it will do so if you are on a release for which the package is not built).
FWIW I use Homebrew Casks to install binary stuff, which MacPorts doesn't offer, and MacPorts to install everything else. (Oops, other than stuff that is only available on the Mac App Store, for which I use mas, which will probably fatally break some day.)
I can't say I've needed to use anything outside the appstore and macports, I'm very satisfied with them. For macports you have to install the CLI tools for Xcode.
When are we going to see the unix filesystem reflect a threat model other than protecting users from each other? The filesystem permissions you're referring to being messed up work off threat model assumptions that pre-date unix.
I mean maybe if Apple provided a decent way to sandbox processes or restrict them outside the traditional unix user-owned-process model, but all their efforts here seem designed to pimp their app store.
/usr/local is just one place where this friction arises. SIP does not point to improvements here in the near future.
Hmm, I am not sure we are using the term the same way. The processes built still run with my user id with full access to everything that entails.
In any case, the App Store sandboxing is pretty useless at enabling end-users to control what the process does. I mean little snitch should be built in to the OS by now and given user experience considerations outside the control or snitch—say, shipping apps with explicit whitelisted routes to the internet you can view before launching one.
/usr/local is a remnant of a time that makes no sense anymore for most developers in a time of dedicated workstations and I can hardly blame homebrew for pushing back against any of the cruft that's built up over the years but is now difficult to justify.
Homebrew silently reports your IP address (and thus coarse location), a unique identifier (that allows your location to be tracked over time), as well as any packages you install, to Google (and by extension the US military intelligence community), each time you use it.
I was looking at Yabai [1] as a window manager and it requires SIP[2] to be disabled for advanced features... Is SIP really needed ? I see that it didn't even exist since "since OS X 10.11 "El Capitan".".
Bricking means that the computer is no more useful for computing than a brick (or that you might as well use it as a brick). Don't use it for stuff that can be fixed with software.
Where do you draw the line, though? Something that might be a brick to a web developer would probably be perfectly serviceable to me as a firmware engineer
Meanwhile, something that's a brick to me is often perfectly serviceable to someone who can operate a soldering iron
Something that's a brick to a competent hardware tech might still be serviceable to a 3 letter agency
Sure, the line is porous, but if it can be fixed by doing something with software that is documented by the manufacturer then I think it's definitely not bricked. In this case booting from recovery.
This debate showed up in the original HN discussion too, which also used the term. I think it’s more appropriate to draw the line at “as useful as a brick without taking actions not exposed as part of the normal user interface”. Drawing the line between hardware and software yields false negatives (corrupted read-only firmware is indeed bricked), false positives (discharged battery is not bricked), and messy grey areas (if it’s non-functional but fixable with a trivial chip replacement, is it bricked?), and moreover is frustratingly antagonistic to non-programmers, who have a computer that is as useful as a brick to them until they take it to a professional, yet you tell them not to say so just because you also have the skills necessary for this particular repair.
Yabai is awesome. You can partially disable SIP, which I believe is required since the scripting extension needs it to interact with the dock. But you don't need to completely disable it.
Probably from a pure safety perspective, however since a lot of your life is uploaded to google I'd rather deal with apple. I've used them for years with zero problems other than 1 HD crash, but I always back up my data so that's never an issue. If you're really worried install dockers and use limited user accounts to run apps. There's always a way.
This guide is great. It's a pity there is no easy to use (maybe GUI) tool for the average user go be able to implement a lot of the things mentioned here. There used to a few scripts around but most seem outdated. I'm thinking along the lines of Harden Tools for Windows. Great open source project for someone.
https://objective-see.com have pretty good security related GUI tools for macOS. Things like ransomware protection, firewalls, task explorers. They also do malware analysis for macOS, definitely an interesting website.
Ironically, it's way more difficult to harden OS X compared to hardening W10, due to the lack of community. Although OS X is more secure by default, there are pretty glaring security holes that aren't easy to fix without tools.
The guide seems to say, "the best anti-virus is Common Sense 2020. See discussion in issue #44." I take this to mean that they recommend common sense instead of anti-virus software.
It does also say, "Anti-virus programs are [...] possibly useful for catching 'garden variety' malware on novice users' Macs", so maybe that's what you disagree with, which is reasonable.
I just wanted to point out that their main recommendation does not, to my reading, suggest to use AV.
Nice guide. I didn't realize the security implications of iOS devices and the Touch Bar (being practically an iOS device itself).
I'd be interested to see an equivalent guide for Android devices. My current suspicion is that I'd be far more alarmed by Android than iOS but it would be nice to verify this.
That part about iOS is confused. The focus on activation is weirdly myopic. If Apple wants to track your identity, location, and activities and send it to the Chinese government, they are going to be able to do that with or without that specific activation mechanism. They can do this in iOS or in macOS.
The fear of the potential iOS-ification of macOS due to the use of Apple silicon in macs also has some logic holes. Apple can iOS-ify macOS with or without Apple silicon, and vice-versa. This is conflating hardware with the software it runs.
> You can pretty much do anything with Android, the same cannot be said about Apple's dictatorship.
The problem is that app developers can also do anything with Android, often against the users‘ will.
Before I switched to iPhone, my choices for location access on Android apps were basically “access location 24/7”, or “no location support at all”; and even that was an improvement upon the earlier “the app will get these permissions, don’t install it if you disagree” model. iPhone, in contrast, had a sensible “only access location when the app is open” option. Similarly, uploading a single photo to Facebook on Android required the app to get full access to your whole SD card; on iPhone, I can send a photo without the app getting access to my storage at all (that single photo is copied into the Facebook sandbox by the OS). Perhaps Android has improved since, but so has iOS (see e.g. the feature list for iOS 14).
For some of us, controlling our data without turning the phone into a full-time hobby is more important than having full system access.
> I am not even sure about stock installs given Apple's poor security record.
Do you have a link supporting that Apple’s security record is worse than other systems, relative to market share?
As far as I know, the macOS permission system provides better sandboxing than either Windows or Linux by default. (Though if you work for it, you can harden Linux more.)
And although there is a lot of malware for macOS, last I checked nearly all of it was in the form of Trojans and similar vectors, where a user has to download and execute untrusted code. That is an issue on any platform; a user running a malicious bash-script with sudo shouldn’t count the same as remote exploits in my opinion.
It’s good to hear that Android supports this as well now, but I think you understate the difference in when these features arrived. From a quick search, the location example was fixed in iOS 8 in 2014 [1], and in Android 10 in 2019 [2], putting Apple 5 years ahead of Google on privacy features. Based on the list of privacy features being introduced in iOS 14, my impression is that this is still the case?
Thanks for looking up the timeline, I was not sure. Also full disk encryption on phones is another thing Apple did way earlier.
I agree it's not exactly apples to Apples. Does Apple still have special permissions for their own apps which allows them to run unobstructed, but other apps need to jump hoops with callbacks and other workarounds?
Are we expecting for Apple to always be 5 years ahead of Google on privacy features? Or did Google shift priorities with Android 10?
Honestly if we're talking about buying an iOS device or an Android device in 2014, I'd lean towards iOS for sure. I don't feel the same way about it today.
> Are we expecting for Apple to always be 5 years ahead of Google on privacy features? Or did Google shift priorities with Android 10?
Good question! My personal impression is that Google, being primarily a tracking company, reluctantly added just enough privacy features for people not to flock to Apple. (I think people have grown more privacy-conscious over the past few years, and Apple has marketed their privacy features heavily.) Links like this [1], listing the iOS 14 privacy features that will arrive in late 2020, appear to still be ahead of what Google has done yet – and e.g. Facebook’s reaction to the cross-app tracking block appear to indicate that this isn’t something they’ve encountered from Google.
But being an iPhone user now, I of course notice more easily what’s happening in the Apple world than Google world. If you have an overview of new privacy features in Android, which aren’t in iOS, I’d be very happy to be proven wrong. I’d love to see a full arms race between Google and Apple on privacy, with both parties introducing novel features.
> Does Apple still have special permissions for their own apps which allows them to run unobstructed, but other apps need to jump hoops with callbacks and other workarounds?
Unfortunately, yes. There is e.g. no way to get as reliable background sync with things like Nextcloud and Resilio as you do with iCloud, since there’s no “run in the background” permission. Not sure about this, but I don’t think any other app can take over the lock screen in the same way as Apple Maps. You can’t set a default browser than Safari, but I believe this is changing in iOS 14.
While I respect Apple for their stance on privacy and therefore use an iPhone, I do disagree with some of these missing permissions, and hope that a new round of anti-trust investigations may force them to open up on this.
Does anyone knows of a similar collection of tweaks, but for getting performance out of macOS?
Things like disabling Spotlight so it's not indexing node_modules and other folders, or adding tools to the Developer Tools to disable network checks with apple servers when you want to run a binary
i've increasingly been having issues with hands off![0] on my machine (intermittent high cpu usage, regular kernel panics), and was actually looking at this guide a while back to decide whether i should switch to pf instead[1].
but pf seems to require much more configuration and management. anyone have experience/pointers in this regard?
[0] i used to use little snitch many years ago, but ran into similar issues with it over time (maybe it's better now).
No, you can’t stop “an agency” but you can make their job harder and slow them down. Using a hardened O/S is part of the mix but not connecting to the net if you can avoid it is another. A good overview of how to configure you computer for privacy can also be found on episode 177 of Michael Bazzel’s “Privacy, Security, and OSINT Podcast”:
Are you kidding? You still have to do work, but a third party doesn't get to decide if you can boot and what image you boot.
> What is particularly worrying about this process is that it is a network-linked secure boot process where centralized external servers have the power to dictate what the device should boot.
Firstly, your quote is about iOS not macOS as far as I can tell, so the competitor here would be Android not OpenBSD.
Secondly, I interpreted your comment as “that list is long enough to make one want to switch to Linux”. I then stand by my comment that most of the suggestions on the list require at least the same amount of work on Linux. (Source: I’m a Linux user that has setup things like fscrypt, ufw, openvpn on my devices.)
https://hn.algolia.com/?query=macOS%20Security%20and%20Priva...
It's not good. See:
https://news.ycombinator.com/item?id=17904304