Hacker News Reader

Comment by Cloudef | Hacker News Reader

Its opposite. Windows and MacOS lacks proper sandboxing. While openbsd has pinsyscalls and linux has seccomp-bpf. Windows and MacOS only have filesystem and worse version of user namespace sandboxes, anything else and you need to write a kernel extension or rely on a hypervisor.

> Unfortunately implementing an Apple style architecture on Linux would be very difficult.

The apple apps kind of thing already exists and its called flatpak.

View on HN

Windows has virtualisation based sandboxing and NT has object-level security (albeit not often used correctly and granularly) and macOS has (among other things) SIP and a subsystem called sandbox that does exactly what it says: it sandboxes. It can sandbox in comparable namespace terms (like cgroups v1 or v2, but more in translocation style execution since it's a MAC framework) yet it also does it a much more fine-grained level depending on what you need. It is used by launchd and applications by default, some entitlements require it so if you want to do some broad kind of elevated application, you also have to have a specific sandbox profile. It's also been around for 16 years, and comes with a ton of examples if you wanted to use it yourself to constrain some process. Yes, it can do filesystem (would be pointless without it), but also does ipc, io, network, memory, fcntl, sysctl, mach ports, sys calls, processes, ui, sockets, messaging, events and all of that including context-aware filtering and compound matching for all of them. And if that's not enough there is also ESF and NEF, the latter only working on networking. You can compare those two to eBFP LSM and XDP. If you want all of this on linux, you'll need to add a lot of custom eBPF and LSM as well as always run in a hypervisor for guaranteed IOMMU usage, but you can't use bare KVM for that either, so you'll either need to never touch the privileged kernel (not even give it a console) or you need to run Xen and use XSM.

Flatpak is just a cheap container copy. Can't do anything beyond what cgroups and things like apparmor and selinux can do, and uses a runtime to do soft higher-level policy functions that translate down to the same primitives. If anything, it's a great bundler, but doesn't do anything new policy-wise.

So, can you get the macOS-level capabilities (both low-level and higher abstractions)? On Linux, yes, but they don't exist yet. On Windows: technically possible, but since that would break most GUI workflow it's not likely that anyone is going to bother, and you're going to have a hard time recompiling windows yourself to make that happen.

Hello, can you tell me if I can filter syscalls made from a memory address in macos without virtualizing the process, or requiring special entitlements and root? I currently have a project where sandboxing is important and i need to prevent all syscalls from a region. This is very simple in linux, and on openbsd i dont have to do anything because openbsd by default does not allow untrusted callsites from making syscalls (and the region in this case is not loaded by openbsd's dynamic loader).

On macos i currently virtualize the process itself, but this has virtualization overhead and some emulation overhead because macos does not let you map all the host process pages to a guest.

I don't think so, the XNU and macOS LS architecture doesn't assume you're going to do policies based on the internal memory topology of a process. It's usually done with multiple processes and having one be very constrained doing only some very specific calls and the other not being able to do any calls at all.

You can probably get by with mprotect or mach internals, but if you're developing at that level you've probably already either implemented or dismissed that.

It's a bit of a different architecture with PAC/MIE/APRR (and to a degree AMFI) being used to prevent abuse that would require syscall filtering in the first place. While I personally don't think that's airtight, it does appear to work out well for their ecosystem.

Edit: come to think of it, region-based call filtering is never really going to be enough on its own, if you don't combine it with other techniques it's basically a rop gadget fest. Probably also why SBX went for intent rather than trying to do it based on location/origin.

Windows has a brokered sandbox architecture too these days, but it's very new and nobody uses it.

This isn't the case at all. Please learn about Apple's security architecture before making sweeping claims like this, it is very deep and has nothing to do with user namespace sandboxes. Windows also has a sandboxing architecture, it's just not as good as Apple's.

FlatPak's security architecture is an attempt to sort of head in the same direction, but they are a decade+ behind and will probably never get there.

macOS absolutely has sandboxing, what are you talking about? But the reality is that you need custom sandboxing tools less when you don't have basic problems like "anything that runs ever can read my ~/.ssh directory without problem" or "you can hijack my password by interposing sudo and thus do anything". This does not matter because macOS will see a program signed by Corp XYZ is trying to read data not owned by that cryptographic signature, and it can't escape the code signature check, and it will flag it. A program cannot simply read your password from stdin and elevate privileges silently, because granting new privileges requires communicating with a higher privilege program so it can delegate to you, and that program has a non spoofable prompt. And so on.

You can use Linux's sandboxing functionality to make a pretty hardened server. If you take in mind the physical deployment and go the extra mile, it can be very secure. The Linux desktop is not and will never be secure in its current form from things like extremely basic local malware. You would have to redesign much of the desktop stack from the init system downward so you could easily do things signature-based identity, proper per-identity secure storage and key management, securitizing elevation of privileges, getting rid of setuid, etc.

They purposefully used a weasel word - "proper" - to shift the argument to being about their opinion on what a proper sandboxing system is.

Reply on news.ycombinator.com