Hacker News Reader

Comment by threeseed | Hacker News Reader

What you call dumbing down I call incredibly useful security features.

Apps shouldn’t be able to read my entire hard drive unless I give it permission. And the core OS should be immutable.

Also not sure what you’re talking about. Custom mouse drivers of course still work.

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.

References:

[0]: https://en.wikipedia.org/wiki/FreeBSD_jail

[1]: https://www.freebsd.org/cgi/man.cgi?query=jail&sektion=8&for...

oh beauty! Perhaps you could share those scripts on a github?

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.

Refs:

[0]: http://erdgeist.org/arts/software/ezjail/

[1]: https://www-legacy.freebsd.org/doc/en_US.ISO8859-1/books/han...

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.

dumb q: can you change the path to this file?

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.

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.

Yes, because awareness does not automatically mean ability to circumvent.

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?

I don’t think so.

Windows, VMS and some mainframes/micros have had such capabilities based file systems for years, it was not pioneered in mobile devices.

Now if some people just give access to everything instead of using ACLs, that is another matter.

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.

If you see no access even as root as problematic, why are you avoiding disabling SIP? That sounds like exactly what you want.

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.

It sure sounds nice, doesn't it?

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.

https://sneak.berlin/20210202/macos-11.2-network-privacy/

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.

Why would you want Docker to be able to bind any folder? Or even edit "anything" in your IDE? Don't you have a /projects folder somewhere?

..and, office?! Do you keep spreadsheets in system folders?

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?

Reply on news.ycombinator.com