Hacker News new | past | comments | ask | show | jobs | submit login

> IIRC the big thing that changed with 10.15 for CLI applications is that BSD-userland processes (i.e. ones that don't go through all the macOS Frameworks, but just call libc syscall wrappers like fopen(2)) now also deal with sandboxing, since the BSD syscall ABI is now reimplemented in terms of macOS security capabilities.

Is this actually new in macOS 10.15? I seem to recall this being a thing ever since sandboxing was a thing, even all the way back to when it was called Seatbelt.

> That means that any CLI process that "walks" the filesystem is going to generate huge amounts of sandboxd traffic, which bottlenecks sandboxd and so slows down the caller process.

Is this not implemented in the kernel as an extension? I thought the checks went through MAC framework hooks. Doesn't sandboxd just log access violations when told to do so by the Sandbox kernel extension?

> Unlike macOS app-bundles, regular BSD-userland executable binaries don't have a capabilities manifest of their own, so they don't start with any process-local capabilities (with some interesting exceptions, that I think involve the binary being embedded in the directory-structure of a system framework, where the binary inherits its capabilities from the enclosing framework.)

I am fairly sure you can just embed a profile in a section of your app's binary and call the sandboxing Mach call with that…






> I seem to recall this being a thing ever since sandboxing was a thing, even all the way back to when it was called Seatbelt.

Maybe you're right; I'm not sure when they actually put the Seatbelt/TrustedBSD interpreter inline in the BSD syscall code-path. What I do know is that, until 10.15, Apple tried to ensure that the BSD-userland libc-syscall codepath retained mostly the same behavioral guarantees as it did before they updated it, in terms of worst-case time-complexities of syscalls. Not sure whether that was using a short-circuit path that went around Seatbelt or used a "mini-Seatbelt" fast path; or whether it was by hard-coding a pre-compiled MAC ruleset for libc calls that only relied upon the filesystem flag-bits, and so never had to do anything blocking during evaluation.

Certainly, even as of 10.12, BSD-userland processes weren't immune to being exec(2)-blocked by the quarantine xattr. But that may have been a partial implementation (e.g. exec(2) going through the MAC system while other syscalls don't.) It's kind of opaque from the outside. It was at least "more than nothing", though I'm not sure if it was "everything."

One thing that is clear is that, until 10.15, BSD processes with no capabilities manifest, still had the pretty much exactly the same default set of privileges that they had before capabilities, which means "almost everything" (and therefore they almost never needed to actually hit up the security system for more grants.) I guess all Apple really needed to have done in 10.15 to "break BSD", was to introduce some more capabilities, and then not put them in the default/implicit manifest.

I suppose what actually happened in 10.15 can be determined easily-enough from the OSS code that's been released. :)

> Is this not implemented in the kernel as an extension? // I am fairly sure you can just embed a profile in a section of your app's binary and call the sandboxing Mach call with that…

Yeah, sorry, you're right; updated my assertions above. I'm not a kernel dev; I've just picked up my understanding of this stuff from running head-first into it while trying to do other things!


It's a new behavior that doing 'find ~' will trigger a MacOS (GUI) permissions warning dialog when `find` tries to access your photos directory, contacts file, etc.

That is new, but I believe the groundwork for that was mostly laid in 10.14 and is also mostly in the kernel.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: