How easy is it for a developer to "sandbox" a program?
kristaps.bsd.lv
kristaps.bsd.lv
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.
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
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.
judge or kludge?
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.
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.
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's a design decision of Whatsapp, because they want your full address book so that they can build a social graph and sell you more ads.
You don't need a new OS for that.
(A secondary problem is design of Android system, which allows app to know difference between "permission not granted" vs "permission granted, user has empty address book". But a change like that is fully backward compatible, Google can retrofit this at any moment)
Using proxy capabilities would allow you to make a "permission granted, user has empty address book" (or some subset of the data, or even made up random data) even if you do not have a empty address book, so that is what I think will be better. (Another way to do it might be to use a separate app for the address book, which does not use the address book in the system. This might work if the app cannot detect the presence of other apps.)
Yes, we need something like "no network" group, and every programm belonging to that group shall not be able to go on the internet.
My model would be: For a program to access the internet, it must be given a capability (possibly in the initial message, but could also be in a different message), which it can communicate with in order to access the internet. The receiver can't know what capability it is (although it can request a specific capability in the type signature), so it might connect directly or it might use a proxy or simulate slow speeds or error conditions.
The permission should be "communicate with www.example.com" and if the app needs more than that, you come up with a different permission that is broader.
You want common use cases to have clear permissions so that users can make an informed decision when an app requires much broader access than other apps needed.
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.
so the user is at fault because the browser ignores the user's setting
> and I'm not the only one. Research shows people will click "allow" without thinking
It is because "app developers" insist until the user gives up. Earlier was " ok and " cancel", then " ok and don't ask me again" and now " ok and ask me later".
> and leave apps running and updating in the background for months before cleaning house.
Apps which run by default in the backgroung, with no possibility to stop them. Why does Android does not respect my "force stop" ? Why does it restart the app ?
But yes, blaming the "idiot user" is the way to better UX.
jeroenhd is absolutely correct that people, generally speaking, do not care about fine-grained permissions. We try telling them to use different usernames and passwords, to use pseudonyms, to only give the minimum required access, etc, and yet it just keeps happening. This isn't an access to education issue, it's a stubbornness issue: they don't care to learn it. And in fact, they will look at us weirdly for caring about it so much: I've seen people say that anyone with a protonmail email should get their harddrives checked because only paedos would want that kind of service.
This doesn't AT ALL absolve the app developers for engaging in hostile dark patterns. But I do have to agree that even if the permission system was fixed to be perfect, it wouldn't matter for the vast majority of people because they'll allow everything anyway.
Even if many people don't care, still it should possible if someone does want fine-grained permissions, to be able to do so (although I think proxy capabilities that I had described elsewhere, would be better than merely "allow" or "disallow", regardless of how fine-grained these "allow" and "disallow" might be).
You are right that it does not absolve app developers.
This works fine with Open contacts from F-Droid.
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.)
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.
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).
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!
shell my:sandbox
The easiest solution is to give up and use Linux (Docker).
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.
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.
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).
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.
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.
MSIX is integrated with the (new) Win32 sandboxing mechanism, yes. You can activate an app container by requesting one in the manifest. But that only works on the very latest Win11 and you'll definitely encounter bugs.
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.
I want a solution I can distribute to other people where the first step isn't "install Docker".
The main reasons to prefer a Linux container are:
• The agent can install new software packages if it needs them. If you use a native Mac sandbox then it'd need to ask permission to use homebrew. Maybe you can find a way to run homebrew inside a Mac sandbox but it won't be straightforward.
• Simpler boundary. The bug I reported (in an AI agent sandbox using Seatbelt) was that it failed to properly block off access to the user's home directory dotfiles and ~/Library. This sort of mistake is easy to make with Seatbelt but harder to make with containers. There are many other sandbox escapes in the policy I saw. Note that using Apple's standard sandbox APIs would avoid this type of error.
• You can edit the SSL root store for just the agent, meaning you can MITM traffic from the agent to the internet. Doing that with native Mac apps isn't possible unless the user actually modifies the root store, which they may not want to do.
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
Still, pretty neat and I do see where I will use it in the future.
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'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.
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.
These sandboxing tools aren't designed to make it safe to run arbitrary untrusted code. If you want that then you're looking at a VM- either a full VM like firecracker or a software VM like V8.
In fact I'd argue it's precisely the lack of such knowledge which makes sandboxing useful: after all, if I knew that the program won't touch or call anything sensitive, I would just simply run it as-is; contrariwise, if I knew it would steal my bank login info and send it to Serbia, I would just not run it at all.
EDIT: Don't get me wrong, I don't have anything against applications putting themselves into restricted modes, and splitting potentially sensitive logic into separate processes; but that functionality really should also be exposed to an end-user as well, akin to
$ pledge --promises=stdin --chroot=/var/empty --cwd=/ -- suspicious_programFor 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.
This is especially bad for the second part - if you are comparing existing open-source sandbox solution, you should not ignore the most common method on Linux!
https://source.chromium.org/chromium/chromium/src/+/main:san...
Devs are forced to build an entire isolation infrastructure from scratch, or to use a complex compute platform like RunPod or Modal for simple code execution. You end up having to manage the ops overhead just for a simple feature.
We found this exact issue quite frustrating and needed an API with its primary feature being dead-simple, high-security ephemeral execution. And so we're building Stonebox, an API that provides that strong, gVisor-based isolation for arbitrary code without any of the setup or maintenance complexity.
Here's our approach if you're curious: https://stonebox.plust.click/
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.
1) Developers flag "every permission"
2) No checks are happening at the distribution level
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.
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.
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...
Not available on the home edition of windows though.
Does anyone know its name?
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
sandboxie is quite old yes; and `dog` vs `god` LOL; did you drop your question in to an LLM? copilot gave me (re dog) winpatrol - though i dont think it has task any application based api stuff https://www.bleepingcomputer.com/download/winpatrol/
there was also things like vmwares thinstall which would wrap up an exe's installation process to make a more or less portable application (edit was here)
there were apps like InstallSheild's system monitoring software which could really monitor a systems changes before and after and build installations of files/registries changed
then there stuff like Deep Freeze which made windows more or less immutable (to a degree) where a reboot would "restore" the system - useful in schools ect
That's why I said Sandboxie is closer to in spirit to what I remembered.
It's been closer to 20 years since I used it, I remember a lot of popups, I think, and you could break programs in all sorts of creative ways :-)))
Maybe I’m hallucinating like a LLM
https://learn.microsoft.com/en-us/windows/security/applicati...
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?