Not being able to edit huge portions of the file system, even as root. Apps not having file system access at all until you grant it, and then it’s folder by folder. Those control panel plug-in things just stopped being supported at all, so good bye custom mouse drivers and such.
I completely agree. In fact, many years ago, when FreeBSD was my main OS (including on notebook) I went as far as to isolate each app that used internet into its own custom-setup jail [0][1].
I had Firefox, Thunderbird, Pidgin and a few others running in complete isolation from the base system, and from each other. I even had a separate Firefox jail that was only allowed to get out via a Tor socks proxy to avoid leaks (more of an experiment than a necessity, to be fair).
Communication between jails was done via commonly mounted nullfs. I have also setup QoS via PF for each of them.
They were all running on the host’s Xorg, which was probably also the weakness of this setup.
It was a pretty sweet setup, but required quite a bit of effort to maintain, even tho I automated most of the stuff.
Now I use macOS, and I would like more control over what apps do what. I’m not particularly impressed with the direction of the UI (it also doesn’t bother me terribly), but I welcome the finer grained security control.
Eactly, I'm moving much more towards FreeBSD now because Apple is taking so much away from us power users. Its jails (and the ports collection) are amazing.
For one thing: I always require certificate logins on SSH. On Mac I used to simply change /etc/ssh/sshd_config to this effect, but since Catalina macOS reverts this with every update. Clearly they don't want me poking around in there :(
IMO if you offer SSH you should offer certificate-only access as well, either with a glitzy on/off button or with a config file change, whatever. But nope...
With Apple you get a lot of security for 'free', however you give up a lot of customisation in return, even in terms of security features.
Not really as sshd is compiled to look for it there.
You can override it with a commandline flag but that would mean changing the launchdaemon which is protected by SIP as far as I know. But I will have a look for that to doublecheck.
Thanks :). If I'll find the time, I'll have to dig them up.
Or maybe I'll attempt to contribute the important parts to an established project, like ezjail [0][1], which seems to be quite competent at handling jails, but is specialized on running services.
Exactly. These are restrictions that have been viewed as favorable for security purposes for decades. It’s nice to see a mainstream OS actually implementing them.
The resistance to them seems to be largely due to lazy developers: it would be EASIER if the system let a developer do whatever they want with a “trust me, I’m smart” justification. But we can’t design for the occasional safe and smart developer: we need to design for the sloppy ones and the malicious ones. The smart and safe ones can find a way to work within the constraints. As for lazy and sloppy ones who can’t adapt to the constraints - adapt.
It would be more sensible to assume that "trust me, I'm smart" developers will eventually work out what they need to do - possibly after the third or fourth time they lose all their work to ransomware, but more realistically, by following the inevitable online tutorials which will appear.
OS security is generally a shit show anyway. I don't think it's bad to lock down the OS for most users, but it should still be possible for expert users to get expert access.
If there are security consequences, they should be trusted to learn how to deal with them.
Most will - and the rest will have bad experiences.
> OS security is generally a shit show anyway. I don't think it's bad to lock down the OS for most users, but it should still be possible for expert users to get expert access.
Last I checked, it still is—IIRC, you have to run some specific commands in Recovery Mode to disable the protections, but for "trust me, I'm smart" developers, that shouldn't be a problem.
Personally, I haven't seen any particular need to do that. I can count the number of times I've been blocked by SIP from doing things I wanted to do on one hand, and none of them were critical.
Usually its not about smart. Its about fixing something that is broken in the OS and SIP is blocking fixing it. A missing monitor geometry. Or an incompatibility in a default cone in. Getting rid of unwanted built in apps like News.app.
I agree... I'm looking forward to see on the desktop this capability model pioneered in mobile devices.
Unix file access permissions designed 50 years ago for multi-user shells are not adequate when dealing with potentially hostile applications accessing your data.
Today I'm more worried of a random App encrypting $HOME or hoovering up all my PII.
Are you really any more secure after you make the initial mistake installing the app? It's not like an attacker is unaware of the security measures in place.
Well, I still lock the front door with the deadbolt at night although it won't stop a mob from breaking in, it's good enough to keep me reasonably safe against normal threats.
Also, actively circumvent protection devices is proof of malice and possibly even criminal intent (remember DMCA?) so I don't see your point.
Has there been any one year period in the last twenty years (NeXTSTEP for the first few years for MacOS) where there were not plentiful kernel exploits for Linux, MacOS, and Windows?
For me it's more the "no access even as root" issue that is highly problematic.
I've been trying unsuccessfully to childproof a Big Sur laptop for a 12 year old for some time now — disable access to some built-in apps etc. I have yet to figure out how, without resorting to disable SIP.
There is Screentime, but that's an unreliable joke which has caused us a massive amount of headaches on iOS due to unreliability, has very limited features and can only be protected by a 4-digit PIN.
As a last resort, that is what I will do. But that would mean to fight the system, which is rarely a good thing in the long run. When it comes to system setup, I prefer to color inside the lines if at all possible.
"Configuring which programs a restricted user can run" is _such_ an elementary task for an OS that I cannot believe that recent macOS has no provisions for that. I _must_ be missing something.
Now how do I turn off the dozens of daemons that go everywhere on the internet without my control, uploading telemetry, etc? I've still not figured out how.
Core OS? It’s stuff like the iMessage database. Mac OS ain’t Silverblue. :)
I’m not saying it’s bad. More security is great! My kids use MacOS. I’m grateful for it. I love iOS too. But it’s absolutely dumbing the OS down and making it less of a professional machine.
It really depends on your usage. It can be a security feature for many contexts, but otherwise:
- docker - you need to be able to bind any folder
- IDE - you need to be able to edit basically anything
- office software beyond "I have some things in 'Documents'" - same
- python, ruby, any other interpreter - same
- brew, or any other package manager - same
etc. This simply doesn't work well for many developer workflows. I tried to use a dedicated app for per-app security control like that (can't remember the name anymore) - but for development it was a disaster. It just makes you click "allow" on a popup 10 times a day until you stop paying attention. Now, macos is not at that level yet, but the direction towards that is the complaint usually.
The problem is that your 'developer workflow' sounds like you are assuming a particular level of insecurity that is unwarranted. Learn about the principle of least authority and try to apply it to your workflows. None of the applications you mention need complete access to the filesystem and in every one of those cases the access could be easily limited to a few directories and you would probably never notice.
Yes/no. The security policies as they are implemented today just aren't possible to effectively use by developers. I've got a project in progress which allows you to go into the context of a specific project as a selinux policy and then work on it that way. It's hard, it's a lot of work, and there are endless edge cases. This is not me giving up, it's actually hard to build a system where you both enforce realistic restrictions and don't end up going "yeah, whatever, I've got enough of those permission questions" after a week.
Consider: An interpreter needs to run homebrew which installs new app, but the same interpreter running a script for your project should not read anything apart from those project files. Same interpreter needs to update local packages via bundle and git, but a random script you run shouldn't be able to access your ssh key via git commands. This is basically impossible to achieve without large compromises outside of selinux right now.
>Learn about the principle of least authority and try to apply it to your workflows
So how would you apply this principle to the python interpreter or to a program that gets compiled to a new executable many times during development?
I like the idea of granting folder permissions to regular third party apps I install and use. I always wanted that and I'm glad Apple is moving in this direction with the Mac.
But contrary to regular apps, language runtimes and software under development do not have a specific purpose. The whole point of software development is to create and test arbitrary code. It is pointless to grant privileges to code that changes in arbitrary ways with every keystroke.
During development, privileges have to be granted to the developer account, not to any particular software artifact. I generally think that granting privileges to software and granting privileges to people each has its legitimate place. One isn't generally better or worse than the other.
Docker bind to a project folder (common for development) allows the image to take over the shell. Taking over the shell allows taking over the package manager. That allows taking over the system.
I keep spreadsheets in project folders. Allowing full writes to a project folder allows taking over the shell. See above.
Folder-level permissions are not sufficient. Sorry, I shortened it too much, but basically - there's almost no practical difference between allowing writes to a dev project folder and allowing writes everywhere. (It would stop some really trivial attempts) Your actual system folders are safe of course... but who cares about those really?
> Apps not having file system access at all until you grant it, and then it’s folder by folder.
This is actually a feature I wish Windows had. On Windows you can enable "protected folders" and mark folders as protected. Applications cannot access those folders until you grant it.
On Windows when granting an app permission to a protected folder you grant it access to all of your protected folders.
You cannot grant a specific application access to a specific folder only eg. grant VLC access to your video folder only but will have to grant VLC permission to all your protected folders. In the default configuration this includes all your personal documents.
I wish Microsoft would make the protected folder feature just as granular as I can hear it is an a mac.
If you’re referring to Gatekeeper, that was introduced long before even Mojave. Likewise the third party kernel extension lock down was also a security move. The former can be disabled in recovery mode and you can add exceptions to the latter. Apple usually allows power users to work around their security features. Besides the introduction of new bugs, most changes in recent years have been cosmetic and the unification features are bloat at worst, for users that don’t want them.
There's other little changes. You used to be able to install and use GDB and debug stuff without doing anything. Now you need to dick around with certificates and code signing to get it to work. I never could despite following different sets of instructions to the letter multiple times because of some bug. I gave up and switched to the built in lldb as that worked at least. I think in Catalina or Big Sur they made another change, hardened runtimes, so now if I need to upgrade R I have to install it like it's 1985 and extract a tarball in root. It's shit. Every single version they seem to do something where I need to waste time tracking down some workaround to deal with "security".
I'm tired of granting every other app accessibility permissions for reasons I'm not even sure of, tired of having to grant access to my documents. It's just endless hassle and I don't feel like I'm actually safer. Every new version seems to bring something like this.
