5 ms·

Most programs require a setup phase, where they want a great deal of access to the environment to set up the resources they use, and a steady state phase, where

by ori_b 2y ago

Most programs require a setup phase, where they want a great deal of access to the environment to set up the resources they use, and a steady state phase, where they need very little access beyond pre-opened file descriptors. An externally imposed sandboxing feature can be useful for namespacing, but is necessarily less restrictive than pledge and unveil. For example, in steady state on OpenBSD, most programs can't even their own configs.

BSDobelix 2y ago
Oh look who is here Ori!! How is gefs going and do we have in the next 9Front release?
ruthmarx 2y ago
> An externally imposed sandboxing feature can be useful for namespacing, but is necessarily less restrictive than pledge and unveil. An externally imposed sandboxing feature isn't necessarily less restrictive than pledge and unveil at all, although I'm curious why you think that is the case. To say nothing of the fact that pledge and unveil are wholly dependent on developer opt-in. A good sandboxing solution should be robust and not require the cooperation of the programs that require sandboxing.
- 0x457 2y ago
  Those are two different kinds of sandboxing. One protects application from itself - "here is what I use, if I try anything else, then it's a bug". Sandboxing you're talking about protects system from the application. You really need both. re: restrictiveness With external sandboxing, you need to restrict to a common denominator of all application states you see youself observing that application. Internal sandbox can adjust itself as it goes.
  - ruthmarx 2y ago
    > Those are two different kinds of sandboxing. I'm arguing that only one example is sandboxing, the other is imposing limitations but doesn't meet the definition of sandboxing.
- yjftsjthsd-h 2y ago
  > An externally imposed sandboxing feature isn't necessarily less restrictive than pledge and unveil at all, although I'm curious why you think that is the case. With pledge, you can read config files, open a file handle to your logs, and then completely drop the ability to open() files at all for the remaining lifetime of the program. How would you do that from outside the program?
  - ruthmarx 2y ago
    By monitoring and intercepting what the program is doing?
    - yjftsjthsd-h 2y ago
      I guess technically you could write a dynamic policy that... I guess you'd give it a list of files that the program can access exactly once? But that seems difficult and brittle. Is anyone actually doing that?
      - ruthmarx 2y ago
        No, I suppose not, but then, is there really an advantage to doing so? I'm much more concerned with blocking write and execute access than I am about a potential hacker being able to read the config files of the program they leveraged to get a shell. I think it's a good approach and part of defense in depth, but if we're comparing approaches I'll tale the former every time.
        ori_b 2y ago
        > No, I suppose not, but then, is there really an advantage to doing so? A massive one; not reading the config is just a consequence of dropping all file system access once you're done with the initial program setup. You can also set up listening sockets, and then stop the program from making any new network connections, even after a compromise. And so on, with most resources. There are a lot of resources that tend to be needed to set up a program. There tend to be very few needed once the program is running. How would you block all file system access after a program is finished reading its config files, the files they include, and the shared libraries and plugins scattered around the file system? How would you turn off all network access after the listening socket is established? With Pledge, it's trivial: load_config(); load_plugins(); open_sockets(); pledge(NULL, NULL); run(); Pledge makes everything you're talking about work trivially, the only thing that's needed is for the program to opt in to security with one line of code. You don't need to micromanage the permissions and what the program is doing to drop privileges from the outside, with all of the race conditions and fragility that implies.

by ori_b 2y ago

BSDobelix 2y ago

Oh look who is here Ori!! How is gefs going and do we have in the next 9Front release?

ruthmarx 2y ago

> An externally imposed sandboxing feature can be useful for namespacing, but is necessarily less restrictive than pledge and unveil. An externally imposed sandboxing feature isn't necessarily less restrictive than pledge and unveil at all, although I'm curious why you think that is the case. To say nothing of the fact that pledge and unveil are wholly dependent on developer opt-in. A good sandboxing solution should be robust and not require the cooperation of the programs that require sandboxing.

0x457 2y ago
Those are two different kinds of sandboxing. One protects application from itself - "here is what I use, if I try anything else, then it's a bug". Sandboxing you're talking about protects system from the application. You really need both. re: restrictiveness With external sandboxing, you need to restrict to a common denominator of all application states you see youself observing that application. Internal sandbox can adjust itself as it goes.
- ruthmarx 2y ago
  > Those are two different kinds of sandboxing. I'm arguing that only one example is sandboxing, the other is imposing limitations but doesn't meet the definition of sandboxing.
yjftsjthsd-h 2y ago
> An externally imposed sandboxing feature isn't necessarily less restrictive than pledge and unveil at all, although I'm curious why you think that is the case. With pledge, you can read config files, open a file handle to your logs, and then completely drop the ability to open() files at all for the remaining lifetime of the program. How would you do that from outside the program?
- ruthmarx 2y ago
  By monitoring and intercepting what the program is doing?
  - yjftsjthsd-h 2y ago
    I guess technically you could write a dynamic policy that... I guess you'd give it a list of files that the program can access exactly once? But that seems difficult and brittle. Is anyone actually doing that?
    - ruthmarx 2y ago
      No, I suppose not, but then, is there really an advantage to doing so? I'm much more concerned with blocking write and execute access than I am about a potential hacker being able to read the config files of the program they leveraged to get a shell. I think it's a good approach and part of defense in depth, but if we're comparing approaches I'll tale the former every time.
      - ori_b 2y ago
        > No, I suppose not, but then, is there really an advantage to doing so? A massive one; not reading the config is just a consequence of dropping all file system access once you're done with the initial program setup. You can also set up listening sockets, and then stop the program from making any new network connections, even after a compromise. And so on, with most resources. There are a lot of resources that tend to be needed to set up a program. There tend to be very few needed once the program is running. How would you block all file system access after a program is finished reading its config files, the files they include, and the shared libraries and plugins scattered around the file system? How would you turn off all network access after the listening socket is established? With Pledge, it's trivial: load_config(); load_plugins(); open_sockets(); pledge(NULL, NULL); run(); Pledge makes everything you're talking about work trivially, the only thing that's needed is for the program to opt in to security with one line of code. You don't need to micromanage the permissions and what the program is doing to drop privileges from the outside, with all of the race conditions and fragility that implies.