4 ms·

Capabilities are the only way. It is insane to me that in 2025 there is no easy way for me to run a program that, say, "can't touch the filesystem or network".

by jonahx 2y ago

Capabilities are the only way. It is insane to me that in 2025 there is no easy way for me to run a program that, say, "can't touch the filesystem or network". As you say, even a few simple, very coarse grained categories of capabilities would be sufficient for 95% of cases.

IncreasePosts 2y ago
bubblewrap?
- jonahx 2y ago
  Nothing in the container space would qualify as "easy" for me. I am talking about native OS features. Also linux only (afaik)... Or even, for that matter, some sane capabilities for browser extensions.
  - BeefWellington 2y ago
    SELinux! Half jokes aside, I'd love to be able to have a decent mobile style permissions experience on browser extensions and desktop apps.
taeric 2y ago
I'm curious what all you want to run that you don't want to access the filesystem? Or the network? Like, I get it for a few things. But it is a short path to wanting access to files I have created for other things. Pictures and videos being obvious files that I likely want access to from applications that didn't create them. Similarly, it is a short hop from "I don't want any other application to be able to control my browser" to "except for this accessibility application, and this password management application, and ..." As we push more and more to happen in the browser, it should be little surprise that we need more and more things to interact with said browser.
- jonahx 2y ago
  I think you misunderstood. Among the coarse grained capabilities I mentioned would be "access to folder X and it's subfolders" (read or write). But to answer your question there are, eg, tons of programming packages in any language that I want purely for their computational abilities, and I know this for certain when using them. In fact for the vast majority of GUI programs I use, or programming packages I use, I know exactly what kind of permissions they need, and yet I cannot easily restrict them in those ways.
  - taeric 2y ago
    It is specifically running applications that always trips me up here. As a user/operator of the computer, I have been bitten by applications being too locked down for them to be useful in the past. I /think/ we have gotten better such that it is easy to have better OS behavior when it wants to restrict an application. But specifically sandboxing by default has been a source of terrible application behavior for me, in the past. Is a lot like using a shadow banned account where everything looks correct, but nothing is actually showing up. Very confusing. Now, I think your point on restricting the libraries that are imported to a program makes a ton of sense. I'm not entirely clear where I would want the "breaker box" of what an application is allowed to do to be located, but it is crazy how much just importing some library will do in many programs.
    - jonahx 2y ago
      Well you are ofc free to give applications full reign if you want. But you should at least be able to say, "No, desktop calculator I just downloaded, you can't do anything but compute and draw things in your application window". More broadly, creating a good UI around granting capabilities is non-trivial. But that's a separate problem from simply not being able to make even the most basic kinds of restrictions that you want in most cases.
      - taeric 2y ago
        Totally fair. I just don't know of that many (any?) "desktop calculator" applications that people download. I'm far more expecting that people are downloading and running social applications than they are isolated things. Mostly fair that it would be good if we could say "on site foo.com, request for any access to not-foo.whatever that happens." I can't remember the last time I saw the sheer number of third party network accesses that happens on far too many sites. It was sobering.
zokier 2y ago
systemd-run inherits afaik all the extensive sandboxing features from systemd https://www.freedesktop.org/software/systemd/man/latest/systemd-run.html https://www.freedesktop.org/software/systemd/man/latest/syst... https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#Sandboxing https://www.freedesktop.org/software/systemd/man/latest/syst... sure, the command line get bit verbose but nothing that an alias or small wrapper couldn't solve the big problem is that modern operating systems have huge surface area and applications tend to expect all sorts of things, so figuring out what you need to allow is often non-trivial
dooglius 2y ago
Can do this with Qubes OS by running in a non-networked qube
est31 2y ago
What about Deno? https://docs.deno.com/runtime/fundamentals/security/#key-principles https://docs.deno.com/runtime/fundamentals/security/#key-pri...
- IshKebab 2y ago
  Deno controls access at the process level, so it's better than nothing but it doesn't really help with this specific problem. Also it delegates setting the permissions up to the user, and we know that in practice everyone is just going to --allow-all.
- kybernetikos 2y ago
  The key requirement to solve this problem is that you can ensure that third party libraries get a subset of the permissions that the code calling them has. E.g. My photo editor might need read and write access to my photo folder, but the 3rd party code that parses jpegs to get their tags needs only read access and shouldn't have the ability to encrypt my photos and make ransom demands. Deno took a step in a good direction, but it was an opportunity to go much further and meaningfully address the problem, so I was a bit disappointed that it just controlled restrictions at the process level.
  - nonameiguess 2y ago
    Kind of two different things being addressed here. The article is talking about doing this at the granularity of preventing imported library code from having the same capabilities as the caller, which requires support from the language runtime, but the comment being responded to was saying there is no way in 2025 to run a program and keep it from accessing the network or the filesystem. That is simply not true. There are many ways to do that, which have been answered already. SELinux. Seccommp profiles. AppArmor. Linux containers (whether that be OCI, bubblewrap, snap, app images, or systemd-run). Pledge and jails. These are different concerns. One is software developers wanting to code into their programs upper limits to what imported dependencies can do. That is poorly supported and mostly not possible outside of research systems. The other is end users and system administrators setting limits on what resources running processes can access and what system calls they can make. That is widely supported with hundreds of ways to do it and the main reasons it is perceived as complicated is because software usually assumes it can do anything, doesn't tell you what it needs, and trying to figure it out as an end user is an endless game of playing whack-a-mole with broken installs.
daveguy 2y ago
Doing this at the program level is implemented in Linux by SELinux, which defines mandatory access controls (aka limitations on capabilities). This was difficult to get right by default and make a smoothly functioning distro with policies enabled. But it is enabled by default in Fedora. https://en.m.wikipedia.org/wiki/Security-Enhanced_Linux https://en.m.wikipedia.org/wiki/Security-Enhanced_Linux To enable this at the programming level would require an enforcement mechanism at the level of a language VM or OS. It would require more overhead to enforce at that level, but the safety benefits within a language may be worth it.
fsflover 2y ago
> in 2025 no easy way for me to run a program that, say, "can't touch the filesystem or network". Qubes OS exists for more than 10 years already. My daily driver, can't recommend it enough.
- jazzyjackson 2y ago
  Windows pro also has a sandbox that can disable filesystem and network access, but they wasted the opportunity by allowing only one sandbox process at a time.
alpn 2y ago
> say, "can't touch the filesystem or network" Well, OpenBSD has pledge(2) and unveil(2), both of which are very easy to use. https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2 https://man.openbsd.org/unveil.2 https://man.openbsd.org/unveil.2
mperham 2y ago
OpenBSD has had “pledge” for quite a while. I think it’s a good idea, I wish it was supported by Linux because, as you note, a few basic patterns could help immensely. https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2
- yencabulator 2y ago
  Linux ended up with seccomp and landlock. https://docs.kernel.org/userspace-api/seccomp_filter.html https://docs.kernel.org/userspace-api/seccomp_filter.html https://docs.kernel.org/userspace-api/landlock.html https://docs.kernel.org/userspace-api/landlock.html
liontwist 2y ago
Pledge

by jonahx 2y ago

IncreasePosts 2y ago

bubblewrap?

jonahx 2y ago
Nothing in the container space would qualify as "easy" for me. I am talking about native OS features. Also linux only (afaik)... Or even, for that matter, some sane capabilities for browser extensions.
- BeefWellington 2y ago
  SELinux! Half jokes aside, I'd love to be able to have a decent mobile style permissions experience on browser extensions and desktop apps.

taeric 2y ago

I'm curious what all you want to run that you don't want to access the filesystem? Or the network? Like, I get it for a few things. But it is a short path to wanting access to files I have created for other things. Pictures and videos being obvious files that I likely want access to from applications that didn't create them. Similarly, it is a short hop from "I don't want any other application to be able to control my browser" to "except for this accessibility application, and this password management application, and ..." As we push more and more to happen in the browser, it should be little surprise that we need more and more things to interact with said browser.

jonahx 2y ago
I think you misunderstood. Among the coarse grained capabilities I mentioned would be "access to folder X and it's subfolders" (read or write). But to answer your question there are, eg, tons of programming packages in any language that I want purely for their computational abilities, and I know this for certain when using them. In fact for the vast majority of GUI programs I use, or programming packages I use, I know exactly what kind of permissions they need, and yet I cannot easily restrict them in those ways.
- taeric 2y ago
  It is specifically running applications that always trips me up here. As a user/operator of the computer, I have been bitten by applications being too locked down for them to be useful in the past. I /think/ we have gotten better such that it is easy to have better OS behavior when it wants to restrict an application. But specifically sandboxing by default has been a source of terrible application behavior for me, in the past. Is a lot like using a shadow banned account where everything looks correct, but nothing is actually showing up. Very confusing. Now, I think your point on restricting the libraries that are imported to a program makes a ton of sense. I'm not entirely clear where I would want the "breaker box" of what an application is allowed to do to be located, but it is crazy how much just importing some library will do in many programs.
  - jonahx 2y ago
    Well you are ofc free to give applications full reign if you want. But you should at least be able to say, "No, desktop calculator I just downloaded, you can't do anything but compute and draw things in your application window". More broadly, creating a good UI around granting capabilities is non-trivial. But that's a separate problem from simply not being able to make even the most basic kinds of restrictions that you want in most cases.
    - taeric 2y ago
      Totally fair. I just don't know of that many (any?) "desktop calculator" applications that people download. I'm far more expecting that people are downloading and running social applications than they are isolated things. Mostly fair that it would be good if we could say "on site foo.com, request for any access to not-foo.whatever that happens." I can't remember the last time I saw the sheer number of third party network accesses that happens on far too many sites. It was sobering.

zokier 2y ago

systemd-run inherits afaik all the extensive sandboxing features from systemd https://www.freedesktop.org/software/systemd/man/latest/systemd-run.html https://www.freedesktop.org/software/systemd/man/latest/syst... https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#Sandboxing https://www.freedesktop.org/software/systemd/man/latest/syst... sure, the command line get bit verbose but nothing that an alias or small wrapper couldn't solve the big problem is that modern operating systems have huge surface area and applications tend to expect all sorts of things, so figuring out what you need to allow is often non-trivial

dooglius 2y ago

Can do this with Qubes OS by running in a non-networked qube

est31 2y ago

What about Deno? https://docs.deno.com/runtime/fundamentals/security/#key-principles https://docs.deno.com/runtime/fundamentals/security/#key-pri...

IshKebab 2y ago
Deno controls access at the process level, so it's better than nothing but it doesn't really help with this specific problem. Also it delegates setting the permissions up to the user, and we know that in practice everyone is just going to --allow-all.
kybernetikos 2y ago
The key requirement to solve this problem is that you can ensure that third party libraries get a subset of the permissions that the code calling them has. E.g. My photo editor might need read and write access to my photo folder, but the 3rd party code that parses jpegs to get their tags needs only read access and shouldn't have the ability to encrypt my photos and make ransom demands. Deno took a step in a good direction, but it was an opportunity to go much further and meaningfully address the problem, so I was a bit disappointed that it just controlled restrictions at the process level.
- nonameiguess 2y ago
  Kind of two different things being addressed here. The article is talking about doing this at the granularity of preventing imported library code from having the same capabilities as the caller, which requires support from the language runtime, but the comment being responded to was saying there is no way in 2025 to run a program and keep it from accessing the network or the filesystem. That is simply not true. There are many ways to do that, which have been answered already. SELinux. Seccommp profiles. AppArmor. Linux containers (whether that be OCI, bubblewrap, snap, app images, or systemd-run). Pledge and jails. These are different concerns. One is software developers wanting to code into their programs upper limits to what imported dependencies can do. That is poorly supported and mostly not possible outside of research systems. The other is end users and system administrators setting limits on what resources running processes can access and what system calls they can make. That is widely supported with hundreds of ways to do it and the main reasons it is perceived as complicated is because software usually assumes it can do anything, doesn't tell you what it needs, and trying to figure it out as an end user is an endless game of playing whack-a-mole with broken installs.

daveguy 2y ago

Doing this at the program level is implemented in Linux by SELinux, which defines mandatory access controls (aka limitations on capabilities). This was difficult to get right by default and make a smoothly functioning distro with policies enabled. But it is enabled by default in Fedora. https://en.m.wikipedia.org/wiki/Security-Enhanced_Linux https://en.m.wikipedia.org/wiki/Security-Enhanced_Linux To enable this at the programming level would require an enforcement mechanism at the level of a language VM or OS. It would require more overhead to enforce at that level, but the safety benefits within a language may be worth it.

fsflover 2y ago

> in 2025 no easy way for me to run a program that, say, "can't touch the filesystem or network". Qubes OS exists for more than 10 years already. My daily driver, can't recommend it enough.

jazzyjackson 2y ago
Windows pro also has a sandbox that can disable filesystem and network access, but they wasted the opportunity by allowing only one sandbox process at a time.

alpn 2y ago

> say, "can't touch the filesystem or network" Well, OpenBSD has pledge(2) and unveil(2), both of which are very easy to use. https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2 https://man.openbsd.org/unveil.2 https://man.openbsd.org/unveil.2

mperham 2y ago

OpenBSD has had “pledge” for quite a while. I think it’s a good idea, I wish it was supported by Linux because, as you note, a few basic patterns could help immensely. https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2

yencabulator 2y ago
Linux ended up with seccomp and landlock. https://docs.kernel.org/userspace-api/seccomp_filter.html https://docs.kernel.org/userspace-api/seccomp_filter.html https://docs.kernel.org/userspace-api/landlock.html https://docs.kernel.org/userspace-api/landlock.html

liontwist 2y ago

Pledge