4 ms·

> 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. I think this is true f

> 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. I think this is true for simple programs, and less true the more complex a program is. What about programs that due to their nature need to frequently make new network connections, or to periodically check config files? > 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? This could be done with seccomp, although it would be more work than it is to use pledge (although a pledge 'port' also exists), it could also be done with things like SELinux. > Pledge makes everything you're talking about work trivially, I was talking about more complete sandboxing, and pledge doesn't allow for that. Pledge is substantially more limited in scope. > the only thing that's needed is for the program to opt in That's actually a pretty big issue. If all the software you want to use is in the ports tree I guess it's fine, but what about for untrusted or complex code? Say, running an instance of Oracle, or a torrent program that by it's nature constantly needs to make network connections and write/read different files? Pledge is little help in these cases, and especially ineffective as any attempt at sandboxing such applications.

ori_b 2y ago
> I think this is true for simple programs, and less true the more complex a program is. Chrome and Firefox have both been successfully pledged and unveiled. What programs more complex than them are you considering?
- ruthmarx 2y ago
  I gave examples at the end of my previous reply.
  - ori_b 2y ago
    > Say, running an instance of Oracle, or a torrent program that by it's nature constantly needs to make network connections and write/read different files? Yes, those seem relatively simple to pledge (source availability aside); there are a lot of permissions that they should be able to drop once they decide on, say, where the database lives or what files they're saving to. It gets even better if you're willing to privsep the torrent program, though that could take some refactoring. Note that you can trivially do a looser sandbox around unmodified processes using exec pledges and unveil, even for proprietary code. These kinds of sandboxes need to be permissive, though, since they're not aware of program phases. So they're not nearly as tight as a sandbox written by the developer with knowledge about expected program behavior.
    - ruthmarx 2y ago
      > It gets even better if you're willing to privsep the torrent program, though that could take some refactoring. Now you're talking about modifying the code substantially which is out of scope of the thought experiment. Pledge can't really help with the torrent program since it needs to make new network connections and write and read arbitrary files constantly. Unless as you say, you substantially modify the code. If substantially modifying the code is off the table, can you give an example of how pledge can prevent an attacker leveraging an RCE in the torrent program? To what extent would they be restricted? You can't say, limit execution to only certain files/libraries or restrict the ability to delete or overwrite files, right? > Note that you can trivially do a looser sandbox around unmodified processes using exec pledges and unveil, even for proprietary code. These kinds of sandboxes need to be permissive, Yeah, I wouldn't consider that to be a sandbox. Imposing limitations on a program isn't by itself a sandbox, nor is every instance of doing so sandboxing.
      - ori_b 2y ago
        > Pledge can't really help with the torrent program since it needs to make new network connections and write and read arbitrary files constantly. Unless as you say, you substantially modify the code. Unveil helps with the "arbitrary files" part. There's a reason Linux is cloning that interface with landlock.
        ruthmarx 2y ago
        > Unveil helps with the "arbitrary files" part. How? The torrent program needs read and write access to create whatever files it needs to, which can't be predicted ahead of time. Imagine a worst case scenario for an RCE in a torrent program, and then what is your best case scenario for pledge and unveil being able to confine an attacker? Because I'm pretty sure it would be a lot less restrictive than what proper sandboxing can provide. > There's a reason Linux is cloning that interface with landlock. Sure, because it has advantages as part of defense in depth. I never said it was useless or without value. Besides that, from memory landlock actually preceded unveil having started development in 2016, so I don't know that it's fair to say Linux is cloning anything if they had a solution first.

ori_b 2y ago

> I think this is true for simple programs, and less true the more complex a program is. Chrome and Firefox have both been successfully pledged and unveiled. What programs more complex than them are you considering?

ruthmarx 2y ago
I gave examples at the end of my previous reply.
- ori_b 2y ago
  > Say, running an instance of Oracle, or a torrent program that by it's nature constantly needs to make network connections and write/read different files? Yes, those seem relatively simple to pledge (source availability aside); there are a lot of permissions that they should be able to drop once they decide on, say, where the database lives or what files they're saving to. It gets even better if you're willing to privsep the torrent program, though that could take some refactoring. Note that you can trivially do a looser sandbox around unmodified processes using exec pledges and unveil, even for proprietary code. These kinds of sandboxes need to be permissive, though, since they're not aware of program phases. So they're not nearly as tight as a sandbox written by the developer with knowledge about expected program behavior.
  - ruthmarx 2y ago
    > It gets even better if you're willing to privsep the torrent program, though that could take some refactoring. Now you're talking about modifying the code substantially which is out of scope of the thought experiment. Pledge can't really help with the torrent program since it needs to make new network connections and write and read arbitrary files constantly. Unless as you say, you substantially modify the code. If substantially modifying the code is off the table, can you give an example of how pledge can prevent an attacker leveraging an RCE in the torrent program? To what extent would they be restricted? You can't say, limit execution to only certain files/libraries or restrict the ability to delete or overwrite files, right? > Note that you can trivially do a looser sandbox around unmodified processes using exec pledges and unveil, even for proprietary code. These kinds of sandboxes need to be permissive, Yeah, I wouldn't consider that to be a sandbox. Imposing limitations on a program isn't by itself a sandbox, nor is every instance of doing so sandboxing.
    - ori_b 2y ago
      > Pledge can't really help with the torrent program since it needs to make new network connections and write and read arbitrary files constantly. Unless as you say, you substantially modify the code. Unveil helps with the "arbitrary files" part. There's a reason Linux is cloning that interface with landlock.
      - ruthmarx 2y ago
        > Unveil helps with the "arbitrary files" part. How? The torrent program needs read and write access to create whatever files it needs to, which can't be predicted ahead of time. Imagine a worst case scenario for an RCE in a torrent program, and then what is your best case scenario for pledge and unveil being able to confine an attacker? Because I'm pretty sure it would be a lot less restrictive than what proper sandboxing can provide. > There's a reason Linux is cloning that interface with landlock. Sure, because it has advantages as part of defense in depth. I never said it was useless or without value. Besides that, from memory landlock actually preceded unveil having started development in 2016, so I don't know that it's fair to say Linux is cloning anything if they had a solution first.