4 ms·

> Linux isn't like macOS, it doesn't have any kind of proper desktop sandboxing architecture that really works. I’m sorry, what? MacOS’s desktop sandboxing is

by amluto 1mo ago

> Linux isn't like macOS, it doesn't have any kind of proper desktop sandboxing architecture that really works. I’m sorry, what? MacOS’s desktop sandboxing is pathetic. Sure, it kind of sort of tries to prevent an application from rummaging until you give it permission. And that permission is hilariously coarse grained, and it gets regularly broken anyway. (Seriously, read about TCC breaks. They’re not little implementation errors — they’re giant gaping holes in the whole concept.) The entitlement mechanism basically serves to help Apple restrict what developers can do without meaningful protecting Apple’s users. If you think that it protects you when your Mac prompts to ask whether Terminal.app may access Documents, you are welcome to enjoy your warm fuzzy feelings. > Unfortunately implementing an Apple style architecture on Linux would be very difficult. Why would it be difficult? I think that mostly it would reveal to whomever implemented it how useless it is. If you mean sandbox-exec, you can do this on Linux, too. And the Linux mechanisms are not considered deprecated and undocumented, whereas Apple steadfastly refuses admit that sandbox-exec is a real mechanism.

mike_hearn 1mo ago
There can be exploits in any security system but the architecture is sound. There's no equivalent of TCC on Linux (I mean one that really sticks), and no easy way to create one. The sandboxing isn't bad. It's obviously weaker if you do everything in the Terminal and stay in old-school UNIX territory because it wasn't designed to sandbox developer workloads. But it's a lot better than nothing, which is what Linux offers. The OS does actually protect you when it asks if the terminal should be able to access ~/Documents. You can say no, and then random stuff you curl|bash can't read files in that folder unless there's an exploit. Apps that opt in to app sandboxing are much better protected and can store files/settings in an area of $HOME that other apps can't access at all without the right permissions. It would be difficult to do on Linux because an Apple style architecture requires apps to systematically use the blessed OS APIs for functionality. Not only for things like file pickers but also camera access, storing preferences, etc. In Linux it'd require the architecture to be tied to a specific desktop environment and associated set of apps. There's not enough consistency otherwise. It also needs pervasive kernel enforced app identity and equivalents to Apple's bookmarks, Mach context propagation, SBPL, app containers architecture etc. It also needs an agreed on way to handle malware reporting and detection, out of the box, and some authority that's trusted to hand out sensitive permissions (for writing debuggers, if nothing else). You can hack something together with bits and pieces Linux has, and define a way to write apps that delivers something like Apple's architecture - as Android has - but that won't bring the ecosystem with you. And it will suffer from a high degree of centralization where distributors have to approve every app, with any app you get outside your distro's package repositories being a free for all. Apple's architecture allows apps to be distributed outside the app store while still being sandboxed to a lesser or greater extent, as well as scanned for malware ahead of time and located anywhere on disk (by extension, you can have >1 version of an app installed at once and sandboxing still works).
- lrvick 1mo ago
  Mac users always like to defend some of the things Apple legitimately got right over most Linux distros, but always ignore that supply chain security and standard package management security on Apple (Homebrew) is akin to giving a bunch of internet randos root access to your machine with no oversight, vetting, or code review of any kind. At least most Linux distros do basic package signing. Someone even thinking it is reasonable to try to use a mac to manage production would be grounds for me to ensure they never have production access. Also, QubesOS is a thing, therefore QubesOS Linux users have way way better access to sandboxing than MacOS -and- signed devtools packages.
  - mike_hearn 1mo ago
    Homebrew isn't standard package management on macOS. It's an aftermarket mod that Apple didn't have any design input to at all, and which largely imports the laissez-faire Linux approach to packaging to an OS that has a totally different design for native apps. > Someone even thinking it is reasonable to try to use a mac to manage production would be grounds for me to ensure they never have production access. It should be the other way around. I'd be extremely careful before allowing anyone to manage prod from anything other than a Mac. Apple has an OS design that can be solve many serious supply chain and credential stealing attacks. SREs don't maximally exploit it today, and Apple only focuses on consumer use cases so they aren't going to use it to solve server management problems. I think there's a business opportunity in fixing that. But Apple has put in place all the infrastructure you need, whereas the Linux community simply hasn't.
    - lrvick 1mo ago
      > It's an aftermarket mod Unfortunately one I have never seen a MacOS production engineering guide that does not say "install brew" as like step one, exactly because Apple failed to provide a software suite sufficient to meet developer needs on par with that of major linux distributions. Macports is at least maintained by current/former apple employees and signs their packages, but in practice no one knows macports exists. > I'd be extremely careful before allowing anyone to manage prod from anything other than a Mac. I would never even consider letting anyone near production Linux servers if they are not comfortable enough to maintain and secure Linux on the computer in front of them. > I think there's a business opportunity in fixing that. Me too! I am in the current YC batch for exactly that reason with https://caution.co https://caution.co , built with https://stagex.tools https://stagex.tools.
KaiserPro 1mo ago
I mean SElinux plus cgroups is probably good enough. Although as soon as it talks to the desktop environment all bets are off.
- amluto 1mo ago
  In my personal opinion, SELinux is a rather poor design, and I find that it actively gets in the way of trying to do security well.

by amluto 1mo ago

mike_hearn 1mo ago

There can be exploits in any security system but the architecture is sound. There's no equivalent of TCC on Linux (I mean one that really sticks), and no easy way to create one. The sandboxing isn't bad. It's obviously weaker if you do everything in the Terminal and stay in old-school UNIX territory because it wasn't designed to sandbox developer workloads. But it's a lot better than nothing, which is what Linux offers. The OS does actually protect you when it asks if the terminal should be able to access ~/Documents. You can say no, and then random stuff you curl|bash can't read files in that folder unless there's an exploit. Apps that opt in to app sandboxing are much better protected and can store files/settings in an area of $HOME that other apps can't access at all without the right permissions. It would be difficult to do on Linux because an Apple style architecture requires apps to systematically use the blessed OS APIs for functionality. Not only for things like file pickers but also camera access, storing preferences, etc. In Linux it'd require the architecture to be tied to a specific desktop environment and associated set of apps. There's not enough consistency otherwise. It also needs pervasive kernel enforced app identity and equivalents to Apple's bookmarks, Mach context propagation, SBPL, app containers architecture etc. It also needs an agreed on way to handle malware reporting and detection, out of the box, and some authority that's trusted to hand out sensitive permissions (for writing debuggers, if nothing else). You can hack something together with bits and pieces Linux has, and define a way to write apps that delivers something like Apple's architecture - as Android has - but that won't bring the ecosystem with you. And it will suffer from a high degree of centralization where distributors have to approve every app, with any app you get outside your distro's package repositories being a free for all. Apple's architecture allows apps to be distributed outside the app store while still being sandboxed to a lesser or greater extent, as well as scanned for malware ahead of time and located anywhere on disk (by extension, you can have >1 version of an app installed at once and sandboxing still works).

lrvick 1mo ago
Mac users always like to defend some of the things Apple legitimately got right over most Linux distros, but always ignore that supply chain security and standard package management security on Apple (Homebrew) is akin to giving a bunch of internet randos root access to your machine with no oversight, vetting, or code review of any kind. At least most Linux distros do basic package signing. Someone even thinking it is reasonable to try to use a mac to manage production would be grounds for me to ensure they never have production access. Also, QubesOS is a thing, therefore QubesOS Linux users have way way better access to sandboxing than MacOS -and- signed devtools packages.
- mike_hearn 1mo ago
  Homebrew isn't standard package management on macOS. It's an aftermarket mod that Apple didn't have any design input to at all, and which largely imports the laissez-faire Linux approach to packaging to an OS that has a totally different design for native apps. > Someone even thinking it is reasonable to try to use a mac to manage production would be grounds for me to ensure they never have production access. It should be the other way around. I'd be extremely careful before allowing anyone to manage prod from anything other than a Mac. Apple has an OS design that can be solve many serious supply chain and credential stealing attacks. SREs don't maximally exploit it today, and Apple only focuses on consumer use cases so they aren't going to use it to solve server management problems. I think there's a business opportunity in fixing that. But Apple has put in place all the infrastructure you need, whereas the Linux community simply hasn't.
  - lrvick 1mo ago
    > It's an aftermarket mod Unfortunately one I have never seen a MacOS production engineering guide that does not say "install brew" as like step one, exactly because Apple failed to provide a software suite sufficient to meet developer needs on par with that of major linux distributions. Macports is at least maintained by current/former apple employees and signs their packages, but in practice no one knows macports exists. > I'd be extremely careful before allowing anyone to manage prod from anything other than a Mac. I would never even consider letting anyone near production Linux servers if they are not comfortable enough to maintain and secure Linux on the computer in front of them. > I think there's a business opportunity in fixing that. Me too! I am in the current YC batch for exactly that reason with https://caution.co https://caution.co , built with https://stagex.tools https://stagex.tools.

KaiserPro 1mo ago

I mean SElinux plus cgroups is probably good enough. Although as soon as it talks to the desktop environment all bets are off.

amluto 1mo ago
In my personal opinion, SELinux is a rather poor design, and I find that it actively gets in the way of trying to do security well.