If I may just take this opportunity to moan about particular sandboxes: I use the flatpak version of Discord because of the promise of sandboxing in part because I hope it'll mitigate some of the telemetry happening but I doubt it does, but I digress. It is so annoying that anytime I want to drag a file into Discord, I first need to copy it to ~/Downloads. I'M GIVING YOU TO THE FILE, TAKE IT.
I feel this same way about Android permissions too. I don't feel like "this button opens the camera and gives me the photo you take with it" and "I can access whatever the camera is seeing at this moment" should be the same permission. Hell, the former wouldn't even need to be a permission. Ditto with photos. Why do I need to give WhatsApp access to my photos to include a picture in my message? Just allow the button to open an Android OS element that it has no access to, then I can select a photo/photos through it, and then Android gives WhatsApp those photos. And if you take a photo from WhatsApp and want to save it, that should be just as easy, like downloading a file from a browser.
I get the sense that most sandboxing/permission systems are just flags on specific API calls: you want to access a folder? well you need an fs permission for that! But don't worry, once you have permission, it's carte blanche! The only pipe-based sandboxing system I've encountered thus far is the share feature, but this is often so limited.
I think in some cases (like WhatsApp) the better model exists and is available, but isn’t used by the app - possibly as a judge to get you to give it more permissions
On iOS Strava’s app is able to access a photo picker, and the app only gets the photos I actually pick
Meanwhile WhatsApp insists on using the model where it tries to access all photos, and I limit it to specific ones via the OS
The more fine grained “only allow access to select photos” was introduced in iOS 14 and before that your only option was to ask for permissions for all photos. Not to say devs shouldn’t have converted by now but just to say it is possible they just implemented it that way at the time and never got around to updating rather than they really want the broader access.
Just checked and Android has this permission too: I can select "Allow limited access", but this requires manual configuring where you select specific photos/videos/albums to be accessible. It's so bizarre.
You're not providing a one-time access to the photo in this case, you're providing perpetual access to the uri.
If it loses access, it won't be able to display the media from your local storage. And of course, you wouldn't want it to duplicate the media because that'll take up extra storage.
Android's model, where you can ask the user for (read only/read+write) access to only specific files/a specific folder works pretty well for that.
But on Discord's side, this is also because the people repackaging Discord for Flatpak were quite conservative. If you want to break open the sandbox a bit more, you can grab Flatseal and manually approve additional directories. I'm not exactly sure what you need for drag&drop to work, but when I add a folder to Geary's whitelist (or grant all home folder permissions, I suppose), I can drag it into the Flatpak'd application like normal.
Unlike on Android, Flatseal actually lets you list those directories and lets you revoke them (at your own risk).
The point is that drag-and-dropping files should give the sandbox access to that file exclusively without needing to grant any extra permissions. I don't want discord reading my entire home directory, or even all my pictures.
Flatpak and those other systems have many problems (much more than only that), in my opinion. I do not use them (and I also do not use Discord).
My idea to solve it is an entirely new operating system design, which uses proxy capabilities. (Also it does not have file names.)
> I don't feel like "this button opens the camera and gives me the photo you take with it" and "I can access whatever the camera is seeing at this moment" should be the same permission.
I agree that they should not be the same permission, but also the permissions should not be directly like that either. They should be "still picture input" and "motion picture input" permissions. The source of the pictures is not specified by the permissions, and therefore will be independent of the hardware and independent of the implementation.
(With proxy capabilities, this becomes much more versatile in many ways, and can avoid some of the problems of doing them directly by a permission menu.)
Android already provides the "proxy" system. You never need a permission to ask the camera app to launch and pass back the photo to your app.
It's only because people want to control the camera UI.
It's slowly getting better but the API devs need a way to learn what the apps need to be better.
For example, maybe in the future, we could have an Android OS bottom sheet with the camera view finder instead of an embedded app UI that requires camera permission.
And also, don't forget that these permissions were eventually required because malicious actors like Meta kept surveiling users in the background without their knowledge.
In my phone "phone's app" I have the option to message on whatsapp next to each number, but when I click on it, whatsapp doesn't let me just message the number, it asks for permission to view all my contacts.
I feel like we have solved this a billion years ago with the tel: protocol. You don't need full access just to get passed 10 digits by another program?
It feels like permission models are stuck in engineering for low-level programs and nobody thinks about how actual people will use it, or perhaps their developers assume normal people are too stupid to manage fine-grained permissions for all the random apps they put in their PC's?
Maybe the real conspiracy is that the OS developers make the end-user security management terrible to make users afraid of running programs that weren't vetted either by their own proprietary app store where they get paid fees (or in Linux' case, by their distro). Forcing normal users to run a VM to be able to run untrusted apps is prohibitive and restricts the freedom of computer users, in my humble opinion.
As a programmer I dread writing any line of code that deletes files. I feel like there should be a low-level API that required me to say the file extension that my application is allowed to delete or something like that. It's still crazy to me that any single program can just delete all user files even though no user would ever grant it that ability. Until that is fixed the whole user permission model just feels like a big joke to me.
I think it is a problem with the design of the system (e.g. POSIX), that the permission models do not work very well, so trying to add them to a system that it does not fit, might be the problem. (In some ways, it is possible to do by a VM code, but that has its own issues.)
The other things that you mention might also be significant, although I think the problem I mentioned is also a significant reason why it is difficult to change even if you do want to improve it.
> As a programmer I dread writing any line of code that deletes files
My idea of operating system design does not have any function to delete files. You can erase the contents of a file, and you can remove all references to a file (if you can find them). If you do remove all references to the file, then the file will be deleted. However, any of these things requires a capability which can be used to modify the appropriate files; you do not automatically have the permission to do any of this. (The capability might also be a proxy capability that does copy on write so that the program's view of them can no longer see the contents and references to the file even if they are not actually modified or deleted.)
> It feels like permission models are stuck in engineering for low-level programs and nobody thinks about how actual people will use it
Not to be a perpetual curmudgeon, but I feel like a portion of the blame for this could the developers XY'ing each other into the broadest use-case possible. Allowing users to select photos to embed into their messages gets "but what are you really trying to do?"-d into just putting access to the filesystem behind a flag.
WhatsApp can be more specific but chooses not to. They want to access your entire address book and cross-match your number with all of your friends', especially if they're not on WhatsApp yet.
This isn't a technological problem with a technological solution. It's a policy problem on WhatsApp's side.
> As a programmer I dread writing any line of code that deletes files. I feel like there should be a low-level API that required me to say the file extension that my application is allowed to delete or something like that. It's still crazy to me that any single program can just delete all user files even though no user would ever grant it that ability. Until that is fixed the whole user permission model just feels like a big joke to me.
Yes, but I wouldn't want my file manager to double prompt me every time I try to delete a file (one from the FM, one from the OS). However, on Android at least, your application can request access to a specific (set of) file(s) or folder(s), so that the damage of a file deletion bug remains very limited. Your app can even request read-only access.
I don't think mobile platform have a good "recycling bin" API, though. There's one for media files, but I don't think that works for general files. Still, the Google Photos/Camera apps seems to use a system prompt to verify deleting files, so I think there's something at least.
And in my experience, users are too stupid to handle fine-grained permissions. Every time I see my parents, I need to go over all of the websites they've somehow managed to permit notifications for (despite my disabling that shit by default), and I'm not the only one. Research shows people will click "allow" without thinking and leave apps running and updating in the background for months before cleaning house. And notifications are only a minor annoyance (at least on Android, other platforms allow them to be pretty annoying), this isn't even about apps trying to track your location by accessing the metadata on your pictures.
For a few decades, we've tried educating people about how to use computers, and wave after wave of viruses proved that most people are incapable of using a computer securely, even with antivirus. In the modern dumbed-down phone landscape, downloading a virus is actually quite hard, and the viruses can do far less damage than what they could in the XP desktop computer era, but that dumbing down comes at a cost. Every unfortunate new sandboxing rule Google imposes on Android (usually) has a very good reason behind it for the vast majority of users, even if it ruins the day or week or month of tens of thousands of power users who rely on the freedom to do what they want with their phones.
The situation on macOS is so frustrating. sandbox-exec / seatbelt has been marked as deprecated for nearly a decade now (since macOS Sierra in 2016) but it's still what everyone uses - here's OpenAI using it for their new Codex CLI: https://github.com/openai/codex/issues/215
Maybe the new "containers" stuff in macOS 26 is going to be a good replacement for that? It seems like that's a different solution though.
All I want is an easy, documented, supported way to run a binary on my computer and say "it can only access these files, use this much RAM and it's not allowed to make any outbound network requests". It always surprises me how hard this is!
macOS already has a way to do that if you're a developer, but it's weirdly both obvious and non-obvious enough that people don't seem to use it: just compile a simple program that executes other programs, and then sign it with the officially supported sandbox entitlements. You will need a supervisor program that starts up the sandboxed sub-process and grants it access to the needed files via the official bookmarks API (that's what it's called):
Now you're wondering why this isn't built in to the OS. But it is! Apps from the Mac App Store are always sandboxed. Just get your apps from there, and now you know what permissions they need because the store can tell you, as can the Settings app. You can even toggle permissions on and off via Settings.
macOS has the best sandbox of any desktop OS by far. Seatbelt isn't actually deprecated and never has been. Marking it as such seems to be just a way to warn developers off trying to use it directly. Nonetheless, it's not going anywhere: Chrome's sandbox relies on it heavily and if Apple tried to remove it or even just break backwards compatibility with it they'd break Chrome, and if not done in a coordinated manner that'd open up a lot of nasty lawsuit potential and corporate relationship problems.
The reason Apple don't want you using Seatbelt directly is that you have to be an expert in macOS internals to use it correctly ... and those internals change with every release. I reported a vulnerability to a well known company just a couple of weeks ago that involved them using Seatbelt wrong! Apple's entitlements wrap up a common set of use cases under a stable API and it's then on Apple to keep them working correctly as the internals move around.
Thanks, I was wrong to say seatbelt had been deprecated, it's just sandbox-exec
This stuff is so frustrating though! If your sandboxing mechanism requires you to be "an expert in macOS internals" it's not going to get used often, and the people who DO use it are liable to make mistakes.
Clear documentation and a great developer experience are, in my opinion, essential for sandboxing mechanisms - and most of them don't have that.
Isn't MSIX packaged apps on Windows basically the same?
They will even list all the capabilities before installing, and I believe it can handle auto updates outside the MS Store as well.
But I think the main issue is that you can't give granular permissions. I would like to make my own sandbox rules, like only enable a single domain for networking for the app, only allow specific folders, etc.
I don't think you can get this granularity on macOS/Windows right now.
It mostly seems to be deprecated to encourage developers to use App Sandbox rather than doing custom sandboxing things. With custom sandboxing baking implementation details of system frameworks into the sandbox policy is almost unavoidable, and Apple would really rather you didn't do that as it limits their ability to make changes in the future.
The underlying sandbox subsystem is what App Sandbox uses.
Apple can happily rely on implementation details of system frameworks in their policies because they can update them as the system frameworks change.
The sandbox subsystem is what all of Apple's system software uses for sandboxing, as well as many security-conscious third-party programs such as web browsers. It's not going anywhere anytime soon, despite being marked as deprecated.
> All I want is an easy, documented, supported way to run a binary on my computer and say "it can only access these files, use this much RAM and it's not allowed to make any outbound network requests". It always surprises me how hard this is!
I think that if the operating system (and the computer design too) were designed better, then I think that it might be possible to do that, and other things (e.g. all outbound network requests must go through a specified proxy without the program knowing of the proxy, or must use a specific network interface, etc).
> Maybe the new "containers" stuff in macOS 26 is going to be a good replacement for that?
It is not. The Containerization framework [1] is, in its own words, "a Swift package for running Linux containers on macOS" - it's more or less an Apple-branded Docker runtime. It's not applicable to macOS software.
The ideal for me would be Asahi support from Apple, but the software support on their hardware is so far behind the hardware itself (which is amazing).
same.. I use https://github.com/jrz/container-shell to start a fresh debian+tools image under the current directory, yet still allows me to easily open multiple terminals to the same instance.
shell my:sandbox
I also use sandbox-exec with limitations to the pwd, depending on what I want to exec.
In practice, you need to do more than use existing file descriptors. You want a sandboxed program to be able to display windows, use graphic acceleration, play and record audio, have limited access to dbus, integrate with other sanboxed programs.
This is where you cannot get away with 112 lines of code.
For example, to play audio, one has to use pulseaudio protocol and create a fake ALSA device in the sandbox because pipewire doesn't have simpler way to share the access between different users. Also this does not prevent the untrusted program from reading audio card vendor and name.
Some applications like Chromium use privileged SUID helper so I am not sure if it is possible to sandbox them at all. Electron-based apps are also a pain to make work in a sandbox, for example, without /proc and graphic acceleration.
The state of sandboxing on Linux is pretty sad at present moment, and almost everything runs without any restrictions. Compare to Android or iOS where sandboxing was implemented from the start. It is easier and more reliable just to use a virtual machine with a full OS for sandboxing.
There is flatpak, but as I understand, it doesn't prevent the application from reading OS and hardware identifiers via /proc and /sys for example. Also some flatpak apps use "classic" confinement which contrary to the name means no confinement at all.
> How easy is it for a developer to "sandbox" their program?
Why on earth is that the program developer's job and/or duty? If the user (stupidly) wants to run a program completely un-sandboxed, that's their right. If they want to run all programs by default somewhat sandboxed (which is quite reasonable), that's also the user's right and their system's job. Not of the original developer who made the program.
But if you want to run some other program sandboxed, I've heard that "podman run --network=none" works reasonably well.
Another comment already mentioned Chromium. In a similar ballbark I'd mention Deno for running TypeScript/JavaScript in a Sandbox that you have to give explicit permission for filesystem and network access [1].
And WebAssembly should probably be mentioned as well [2].
Deno has "sandboxing" in the sense that it will refuse to open files and such if you don't pass the relevant permission flags, but AFAICT it doesn't do the thing that this article is talking about, of telling the kernel not to let it do those things. (I'm inferring this from the note in the documentation that native code called via FFI isn't sandboxed.) So an attacker could still do those things if they found an exploitable bug in the Deno runtime.
I'm having a hard time figuring out the details of how Wasmtime works but I don't think it does this kind of sandboxing either.
I've been playing around with deno over the past weeks. It's definitely an interesting project. However I do find the permission system to lack the granularity I would want. You quickly end up in a "all or nothing" state, where I would really like to instead differentiate between code I consider trusted and code I consider risky.
Still, pretty neat and I do see where I will use it in the future.
> instead differentiate between code I consider trusted and code I consider risky.
You’re talking about trying to enforce privilege separation within a single process? For that you’d need capabilities ant the language level and even then I’m skeptical you can really lock things down successfully within a shared memory environment (yes JS in theory is a VM but there’s so many VM escapes possible that running untrusted code in process seems futile).
I think so, yes. I would like to be able to say "import that module in no-network mode", if that makes sense (or the opposite, default imports to no fs, no network permissions, the grant explicitly).
Given the first line I think the OP should check out systemd. You can run something as a service and sandbox it that way or go to nspawn to do "chroot on steroids" or upgrade to a full virtual machine
I'm interested in this for an upcoming project, but complexity of setup doesn't seem like a great way to compare these projects. What I need to know is (a) can I run completely untrusted code in these sandboxes? (b) Which let me disable network access, file system access, and limit CPU and RAM usage? i.e. feature set.
The set up might be a pain in the butt, but I'm assuming I only have to do it once and then I can stuff arbitrary programs into it.
Bit strange to approach this from the app dev perspective. Surely it's operating systems and users who care about sandboxing apps? As a developer, I'll live with whatever restrictions I need to, but I'm not sure why I'd go to extra hassle making my life harder in order to secure your system against code that I trust (I just wrote it!)
Tangential: Are there any good methods for windows/windows software? Hyper V is fine for small code, but if you want to install a program everytime it gets old really fast. I wouldn't want to trust random files off the internet either.
You can turn off win32k calls for a process if you don't need gui. You can also run the process with a lower privilege access token to reduce file access and some kernel access.
I'd love to see one to block more kernel calls than just win32k. The best method I've come up with is to create a shared memory buffer to a seperate interface process and then unmount ntdll.dll by marking its pages `page_noaccess`. Thanks to win32 weirdness you can still allocate memory into the process without nt calls from the interface process as VirtualAllocEx, VirtualAlloc2, VirtualProtectEx, VirtualFreeEx, VirtualQueryEx, NtAllocateVirtualMemory, NtFreeVirtualMemory, etc take a process handle as an argument. This kinda requires writing a userspace kernel and your own standard library though.
MS please give me a better method to lock down kernel access beyond nowin32k. Hyperv doesn't work for consumer apps as half the consumer versions of windows don't have it.
Look at how Chrome does it if you want to learn more. The API is classic Win32 unfortunately: extremely complicated, under-documented and full of razor sharp edges. The way Chrome does it also requires custom installer logic. But, it does exist.
Why do you say the way Chrome does it requires custom installer logic? Electron is able to use Chromium's sandbox for renderer processes without imposing any installer requirements as far as I know.
Years ago I was a heavy user of Sandboxie. But those were simpler times and malware was far less advanced than it is now. No idea how good of a protection it provides there days.
Yes, a non-secure way of sandboxing is/was to hook OS functions. Hooking is used still today to modify the behaviour of existing apps and testing apps under custom virtual environments.
We develop on of this that it us used in this Microsoft product[1].
While interesting, the failure to distinguish between cooperative and unmodified programs here sort-of weakens the comparison.
I mean, the OpenBSD APIs are great and all, but most developers are not going to be aware of these, nor deploying to a platform that supports these in the first place.
And yes, kernel-mode supervisors, when available, suffer from inscrutable configurations, so it's clear a middle ground would be nice (especially one that also applies to the W-environment), but it's not clear anyone is particularly invested in this?
Indeed, if you are trying to build something cross-platform and use BSD's specific APIs for security, it is easy to end up with an #ifdef soup in some of the most sensitive parts of your code. One wrong logic step there and you have compromised your application trying to harden it. I don't know the solution :(
Maybe someone knows. There used to be a sort of Windows sandboxing or at least monitoring app named after a god, maybe 15,+ years ago. It could monitor what an app was doing at low level and I think it could even sandbox it.
MS had a tool that let you set an applications "observed" system variables, like OS ect; this was back in win2000 and before now modernization of the windows compatibility stuff, new stuff sort of superseded it. i currently recollect the exe name even after inspecting a win2000 iso - edit2: apparently apcompat.exe ( lol this archive page triggered some memories: https://ia802200.us.archive.org/view_archive.php?archive=/33... )
edit: there were even api firewalls, zonealarm had one, and a number of others. i think people lost interest in locking their systems down as they seem very unpopular nowadays
I do not remember knowing of such a thing (although I might have done and had forgotten), but I would like to see the documentation if it is available.
If I may just take this opportunity to moan about particular sandboxes: I use the flatpak version of Discord because of the promise of sandboxing in part because I hope it'll mitigate some of the telemetry happening but I doubt it does, but I digress. It is so annoying that anytime I want to drag a file into Discord, I first need to copy it to ~/Downloads. I'M GIVING YOU TO THE FILE, TAKE IT.
I feel this same way about Android permissions too. I don't feel like "this button opens the camera and gives me the photo you take with it" and "I can access whatever the camera is seeing at this moment" should be the same permission. Hell, the former wouldn't even need to be a permission. Ditto with photos. Why do I need to give WhatsApp access to my photos to include a picture in my message? Just allow the button to open an Android OS element that it has no access to, then I can select a photo/photos through it, and then Android gives WhatsApp those photos. And if you take a photo from WhatsApp and want to save it, that should be just as easy, like downloading a file from a browser.
I get the sense that most sandboxing/permission systems are just flags on specific API calls: you want to access a folder? well you need an fs permission for that! But don't worry, once you have permission, it's carte blanche! The only pipe-based sandboxing system I've encountered thus far is the share feature, but this is often so limited.
I think in some cases (like WhatsApp) the better model exists and is available, but isn’t used by the app - possibly as a judge to get you to give it more permissions
On iOS Strava’s app is able to access a photo picker, and the app only gets the photos I actually pick
Meanwhile WhatsApp insists on using the model where it tries to access all photos, and I limit it to specific ones via the OS
The more fine grained “only allow access to select photos” was introduced in iOS 14 and before that your only option was to ask for permissions for all photos. Not to say devs shouldn’t have converted by now but just to say it is possible they just implemented it that way at the time and never got around to updating rather than they really want the broader access.
Just checked and Android has this permission too: I can select "Allow limited access", but this requires manual configuring where you select specific photos/videos/albums to be accessible. It's so bizarre.
You're not providing a one-time access to the photo in this case, you're providing perpetual access to the uri.
If it loses access, it won't be able to display the media from your local storage. And of course, you wouldn't want it to duplicate the media because that'll take up extra storage.
Yeah on iOS facebook messenger app can be set to only access media one by one selected by the user
Android's model, where you can ask the user for (read only/read+write) access to only specific files/a specific folder works pretty well for that.
But on Discord's side, this is also because the people repackaging Discord for Flatpak were quite conservative. If you want to break open the sandbox a bit more, you can grab Flatseal and manually approve additional directories. I'm not exactly sure what you need for drag&drop to work, but when I add a folder to Geary's whitelist (or grant all home folder permissions, I suppose), I can drag it into the Flatpak'd application like normal.
Unlike on Android, Flatseal actually lets you list those directories and lets you revoke them (at your own risk).
The point is that drag-and-dropping files should give the sandbox access to that file exclusively without needing to grant any extra permissions. I don't want discord reading my entire home directory, or even all my pictures.
Flatpak and those other systems have many problems (much more than only that), in my opinion. I do not use them (and I also do not use Discord).
My idea to solve it is an entirely new operating system design, which uses proxy capabilities. (Also it does not have file names.)
> I don't feel like "this button opens the camera and gives me the photo you take with it" and "I can access whatever the camera is seeing at this moment" should be the same permission.
I agree that they should not be the same permission, but also the permissions should not be directly like that either. They should be "still picture input" and "motion picture input" permissions. The source of the pictures is not specified by the permissions, and therefore will be independent of the hardware and independent of the implementation.
(With proxy capabilities, this becomes much more versatile in many ways, and can avoid some of the problems of doing them directly by a permission menu.)
Android already provides the "proxy" system. You never need a permission to ask the camera app to launch and pass back the photo to your app.
It's only because people want to control the camera UI.
It's slowly getting better but the API devs need a way to learn what the apps need to be better.
For example, maybe in the future, we could have an Android OS bottom sheet with the camera view finder instead of an embedded app UI that requires camera permission.
And also, don't forget that these permissions were eventually required because malicious actors like Meta kept surveiling users in the background without their knowledge.
In my phone "phone's app" I have the option to message on whatsapp next to each number, but when I click on it, whatsapp doesn't let me just message the number, it asks for permission to view all my contacts.
I feel like we have solved this a billion years ago with the tel: protocol. You don't need full access just to get passed 10 digits by another program?
It feels like permission models are stuck in engineering for low-level programs and nobody thinks about how actual people will use it, or perhaps their developers assume normal people are too stupid to manage fine-grained permissions for all the random apps they put in their PC's?
Maybe the real conspiracy is that the OS developers make the end-user security management terrible to make users afraid of running programs that weren't vetted either by their own proprietary app store where they get paid fees (or in Linux' case, by their distro). Forcing normal users to run a VM to be able to run untrusted apps is prohibitive and restricts the freedom of computer users, in my humble opinion.
As a programmer I dread writing any line of code that deletes files. I feel like there should be a low-level API that required me to say the file extension that my application is allowed to delete or something like that. It's still crazy to me that any single program can just delete all user files even though no user would ever grant it that ability. Until that is fixed the whole user permission model just feels like a big joke to me.
I think it is a problem with the design of the system (e.g. POSIX), that the permission models do not work very well, so trying to add them to a system that it does not fit, might be the problem. (In some ways, it is possible to do by a VM code, but that has its own issues.)
The other things that you mention might also be significant, although I think the problem I mentioned is also a significant reason why it is difficult to change even if you do want to improve it.
> As a programmer I dread writing any line of code that deletes files
My idea of operating system design does not have any function to delete files. You can erase the contents of a file, and you can remove all references to a file (if you can find them). If you do remove all references to the file, then the file will be deleted. However, any of these things requires a capability which can be used to modify the appropriate files; you do not automatically have the permission to do any of this. (The capability might also be a proxy capability that does copy on write so that the program's view of them can no longer see the contents and references to the file even if they are not actually modified or deleted.)
> It feels like permission models are stuck in engineering for low-level programs and nobody thinks about how actual people will use it
Not to be a perpetual curmudgeon, but I feel like a portion of the blame for this could the developers XY'ing each other into the broadest use-case possible. Allowing users to select photos to embed into their messages gets "but what are you really trying to do?"-d into just putting access to the filesystem behind a flag.
WhatsApp can be more specific but chooses not to. They want to access your entire address book and cross-match your number with all of your friends', especially if they're not on WhatsApp yet.
This isn't a technological problem with a technological solution. It's a policy problem on WhatsApp's side.
> As a programmer I dread writing any line of code that deletes files. I feel like there should be a low-level API that required me to say the file extension that my application is allowed to delete or something like that. It's still crazy to me that any single program can just delete all user files even though no user would ever grant it that ability. Until that is fixed the whole user permission model just feels like a big joke to me.
Yes, but I wouldn't want my file manager to double prompt me every time I try to delete a file (one from the FM, one from the OS). However, on Android at least, your application can request access to a specific (set of) file(s) or folder(s), so that the damage of a file deletion bug remains very limited. Your app can even request read-only access.
I don't think mobile platform have a good "recycling bin" API, though. There's one for media files, but I don't think that works for general files. Still, the Google Photos/Camera apps seems to use a system prompt to verify deleting files, so I think there's something at least.
And in my experience, users are too stupid to handle fine-grained permissions. Every time I see my parents, I need to go over all of the websites they've somehow managed to permit notifications for (despite my disabling that shit by default), and I'm not the only one. Research shows people will click "allow" without thinking and leave apps running and updating in the background for months before cleaning house. And notifications are only a minor annoyance (at least on Android, other platforms allow them to be pretty annoying), this isn't even about apps trying to track your location by accessing the metadata on your pictures.
For a few decades, we've tried educating people about how to use computers, and wave after wave of viruses proved that most people are incapable of using a computer securely, even with antivirus. In the modern dumbed-down phone landscape, downloading a virus is actually quite hard, and the viruses can do far less damage than what they could in the XP desktop computer era, but that dumbing down comes at a cost. Every unfortunate new sandboxing rule Google imposes on Android (usually) has a very good reason behind it for the vast majority of users, even if it ruins the day or week or month of tens of thousands of power users who rely on the freedom to do what they want with their phones.
The situation on macOS is so frustrating. sandbox-exec / seatbelt has been marked as deprecated for nearly a decade now (since macOS Sierra in 2016) but it's still what everyone uses - here's OpenAI using it for their new Codex CLI: https://github.com/openai/codex/issues/215
Maybe the new "containers" stuff in macOS 26 is going to be a good replacement for that? It seems like that's a different solution though.
All I want is an easy, documented, supported way to run a binary on my computer and say "it can only access these files, use this much RAM and it's not allowed to make any outbound network requests". It always surprises me how hard this is!
macOS already has a way to do that if you're a developer, but it's weirdly both obvious and non-obvious enough that people don't seem to use it: just compile a simple program that executes other programs, and then sign it with the officially supported sandbox entitlements. You will need a supervisor program that starts up the sandboxed sub-process and grants it access to the needed files via the official bookmarks API (that's what it's called):
https://developer.apple.com/documentation/security/accessing...
Now you're wondering why this isn't built in to the OS. But it is! Apps from the Mac App Store are always sandboxed. Just get your apps from there, and now you know what permissions they need because the store can tell you, as can the Settings app. You can even toggle permissions on and off via Settings.
macOS has the best sandbox of any desktop OS by far. Seatbelt isn't actually deprecated and never has been. Marking it as such seems to be just a way to warn developers off trying to use it directly. Nonetheless, it's not going anywhere: Chrome's sandbox relies on it heavily and if Apple tried to remove it or even just break backwards compatibility with it they'd break Chrome, and if not done in a coordinated manner that'd open up a lot of nasty lawsuit potential and corporate relationship problems.
The reason Apple don't want you using Seatbelt directly is that you have to be an expert in macOS internals to use it correctly ... and those internals change with every release. I reported a vulnerability to a well known company just a couple of weeks ago that involved them using Seatbelt wrong! Apple's entitlements wrap up a common set of use cases under a stable API and it's then on Apple to keep them working correctly as the internals move around.
Thanks, I was wrong to say seatbelt had been deprecated, it's just sandbox-exec
This stuff is so frustrating though! If your sandboxing mechanism requires you to be "an expert in macOS internals" it's not going to get used often, and the people who DO use it are liable to make mistakes.
Clear documentation and a great developer experience are, in my opinion, essential for sandboxing mechanisms - and most of them don't have that.
Isn't MSIX packaged apps on Windows basically the same?
They will even list all the capabilities before installing, and I believe it can handle auto updates outside the MS Store as well.
But I think the main issue is that you can't give granular permissions. I would like to make my own sandbox rules, like only enable a single domain for networking for the app, only allow specific folders, etc.
I don't think you can get this granularity on macOS/Windows right now.
It mostly seems to be deprecated to encourage developers to use App Sandbox rather than doing custom sandboxing things. With custom sandboxing baking implementation details of system frameworks into the sandbox policy is almost unavoidable, and Apple would really rather you didn't do that as it limits their ability to make changes in the future.
The underlying sandbox subsystem is what App Sandbox uses. Apple can happily rely on implementation details of system frameworks in their policies because they can update them as the system frameworks change.
The sandbox subsystem is what all of Apple's system software uses for sandboxing, as well as many security-conscious third-party programs such as web browsers. It's not going anywhere anytime soon, despite being marked as deprecated.
> All I want is an easy, documented, supported way to run a binary on my computer and say "it can only access these files, use this much RAM and it's not allowed to make any outbound network requests". It always surprises me how hard this is!
I think that if the operating system (and the computer design too) were designed better, then I think that it might be possible to do that, and other things (e.g. all outbound network requests must go through a specified proxy without the program knowing of the proxy, or must use a specific network interface, etc).
> Maybe the new "containers" stuff in macOS 26 is going to be a good replacement for that?
It is not. The Containerization framework [1] is, in its own words, "a Swift package for running Linux containers on macOS" - it's more or less an Apple-branded Docker runtime. It's not applicable to macOS software.
[1]: https://github.com/apple/containerization
The ideal for me would be Asahi support from Apple, but the software support on their hardware is so far behind the hardware itself (which is amazing).
You want a capability based OS where by default processes are sandboxed.
I use Docker for this. Sandbox is not effective. Like if you run Firefox with "deny network" profile you will still be able to browse as usual.
same.. I use https://github.com/jrz/container-shell to start a fresh debian+tools image under the current directory, yet still allows me to easily open multiple terminals to the same instance.
I also use sandbox-exec with limitations to the pwd, depending on what I want to exec.Agreed, macOS has lagged every other OS here.
The easiest solution is to give up and use Linux (Docker).
In practice, you need to do more than use existing file descriptors. You want a sandboxed program to be able to display windows, use graphic acceleration, play and record audio, have limited access to dbus, integrate with other sanboxed programs. This is where you cannot get away with 112 lines of code.
For example, to play audio, one has to use pulseaudio protocol and create a fake ALSA device in the sandbox because pipewire doesn't have simpler way to share the access between different users. Also this does not prevent the untrusted program from reading audio card vendor and name.
Some applications like Chromium use privileged SUID helper so I am not sure if it is possible to sandbox them at all. Electron-based apps are also a pain to make work in a sandbox, for example, without /proc and graphic acceleration.
The state of sandboxing on Linux is pretty sad at present moment, and almost everything runs without any restrictions. Compare to Android or iOS where sandboxing was implemented from the start. It is easier and more reliable just to use a virtual machine with a full OS for sandboxing.
There is flatpak, but as I understand, it doesn't prevent the application from reading OS and hardware identifiers via /proc and /sys for example. Also some flatpak apps use "classic" confinement which contrary to the name means no confinement at all.
> How easy is it for a developer to "sandbox" their program?
Why on earth is that the program developer's job and/or duty? If the user (stupidly) wants to run a program completely un-sandboxed, that's their right. If they want to run all programs by default somewhat sandboxed (which is quite reasonable), that's also the user's right and their system's job. Not of the original developer who made the program.
But if you want to run some other program sandboxed, I've heard that "podman run --network=none" works reasonably well.
The developer knows the program best - what files it needs to access, what syscalls it needs to make, etc.
Another comment already mentioned Chromium. In a similar ballbark I'd mention Deno for running TypeScript/JavaScript in a Sandbox that you have to give explicit permission for filesystem and network access [1].
And WebAssembly should probably be mentioned as well [2].
[1] https://docs.deno.com/runtime/fundamentals/security/
[2] There are different runtimes, this is one of them: https://docs.wasmtime.dev/security.html
Deno has "sandboxing" in the sense that it will refuse to open files and such if you don't pass the relevant permission flags, but AFAICT it doesn't do the thing that this article is talking about, of telling the kernel not to let it do those things. (I'm inferring this from the note in the documentation that native code called via FFI isn't sandboxed.) So an attacker could still do those things if they found an exploitable bug in the Deno runtime.
I'm having a hard time figuring out the details of how Wasmtime works but I don't think it does this kind of sandboxing either.
I've been playing around with deno over the past weeks. It's definitely an interesting project. However I do find the permission system to lack the granularity I would want. You quickly end up in a "all or nothing" state, where I would really like to instead differentiate between code I consider trusted and code I consider risky.
Still, pretty neat and I do see where I will use it in the future.
> instead differentiate between code I consider trusted and code I consider risky.
You’re talking about trying to enforce privilege separation within a single process? For that you’d need capabilities ant the language level and even then I’m skeptical you can really lock things down successfully within a shared memory environment (yes JS in theory is a VM but there’s so many VM escapes possible that running untrusted code in process seems futile).
I think so, yes. I would like to be able to say "import that module in no-network mode", if that makes sense (or the opposite, default imports to no fs, no network permissions, the grant explicitly).
Given the first line I think the OP should check out systemd. You can run something as a service and sandbox it that way or go to nspawn to do "chroot on steroids" or upgrade to a full virtual machine
For obvious reasons chromium has pretty extensive sandboxing. You can read the source right here: https://source.chromium.org/chromium/chromium/src/+/main:con...
Here's a more informative doc about sandboxing in Chromium
https://source.chromium.org/chromium/chromium/src/+/main:san...
Looks like that's the subset of their sandbox that applies to GPUs, the file is content/gpu/gpu_main.cc
I'm interested in this for an upcoming project, but complexity of setup doesn't seem like a great way to compare these projects. What I need to know is (a) can I run completely untrusted code in these sandboxes? (b) Which let me disable network access, file system access, and limit CPU and RAM usage? i.e. feature set.
The set up might be a pain in the butt, but I'm assuming I only have to do it once and then I can stuff arbitrary programs into it.
Doesn't really matter as long as:
1) Developers flag "every permission"
2) No checks are happening at the distribution level
Bit strange to approach this from the app dev perspective. Surely it's operating systems and users who care about sandboxing apps? As a developer, I'll live with whatever restrictions I need to, but I'm not sure why I'd go to extra hassle making my life harder in order to secure your system against code that I trust (I just wrote it!)
Tangential: Are there any good methods for windows/windows software? Hyper V is fine for small code, but if you want to install a program everytime it gets old really fast. I wouldn't want to trust random files off the internet either.
There is windows sandbox: https://learn.microsoft.com/en-us/windows/security/applicati...
Not available on the home edition of windows though.
You can turn off win32k calls for a process if you don't need gui. You can also run the process with a lower privilege access token to reduce file access and some kernel access.
I'd love to see one to block more kernel calls than just win32k. The best method I've come up with is to create a shared memory buffer to a seperate interface process and then unmount ntdll.dll by marking its pages `page_noaccess`. Thanks to win32 weirdness you can still allocate memory into the process without nt calls from the interface process as VirtualAllocEx, VirtualAlloc2, VirtualProtectEx, VirtualFreeEx, VirtualQueryEx, NtAllocateVirtualMemory, NtFreeVirtualMemory, etc take a process handle as an argument. This kinda requires writing a userspace kernel and your own standard library though.
MS please give me a better method to lock down kernel access beyond nowin32k. Hyperv doesn't work for consumer apps as half the consumer versions of windows don't have it.
Windows has a fairly capable sandbox called app isolation levels:
https://learn.microsoft.com/en-us/windows/win32/secauthz/app...
Look at how Chrome does it if you want to learn more. The API is classic Win32 unfortunately: extremely complicated, under-documented and full of razor sharp edges. The way Chrome does it also requires custom installer logic. But, it does exist.
Why do you say the way Chrome does it requires custom installer logic? Electron is able to use Chromium's sandbox for renderer processes without imposing any installer requirements as far as I know.
Years ago I was a heavy user of Sandboxie. But those were simpler times and malware was far less advanced than it is now. No idea how good of a protection it provides there days.
https://en.wikipedia.org/wiki/Sandboxie
Yes, a non-secure way of sandboxing is/was to hook OS functions. Hooking is used still today to modify the behaviour of existing apps and testing apps under custom virtual environments.
We develop on of this that it us used in this Microsoft product[1].
[1] https://learn.microsoft.com/en-us/fslogix/overview-what-is-f...
Virtual Box
Android handles sandboxing for programs automatically. If programmers have to explicitly write code to sandbox things, most never will.
I haven't personally used it but cosmopolitan claims to provide a simple and portable sandboxing capability
Capsicum is the most sophisticated of them all. It’s pretty great what you can do with it, coupled with Casper.
While interesting, the failure to distinguish between cooperative and unmodified programs here sort-of weakens the comparison.
I mean, the OpenBSD APIs are great and all, but most developers are not going to be aware of these, nor deploying to a platform that supports these in the first place.
And yes, kernel-mode supervisors, when available, suffer from inscrutable configurations, so it's clear a middle ground would be nice (especially one that also applies to the W-environment), but it's not clear anyone is particularly invested in this?
Indeed, if you are trying to build something cross-platform and use BSD's specific APIs for security, it is easy to end up with an #ifdef soup in some of the most sensitive parts of your code. One wrong logic step there and you have compromised your application trying to harden it. I don't know the solution :(
No mentions of "Syd" anyone use this yet?
Maybe someone knows. There used to be a sort of Windows sandboxing or at least monitoring app named after a god, maybe 15,+ years ago. It could monitor what an app was doing at low level and I think it could even sandbox it.
Does anyone know its name?
there are api monitoring tools; my goto is this: https://learn.microsoft.com/en-us/sysinternals/downloads/pro...
MS had a tool that let you set an applications "observed" system variables, like OS ect; this was back in win2000 and before now modernization of the windows compatibility stuff, new stuff sort of superseded it. i currently recollect the exe name even after inspecting a win2000 iso - edit2: apparently apcompat.exe ( lol this archive page triggered some memories: https://ia802200.us.archive.org/view_archive.php?archive=/33... )
edit: there were even api firewalls, zonealarm had one, and a number of others. i think people lost interest in locking their systems down as they seem very unpopular nowadays
Vaguely recall something like that. Weird name something with a Q? Something mox?
Maybe I’m hallucinating like a LLM
I do not remember knowing of such a thing (although I might have done and had forgotten), but I would like to see the documentation if it is available.