7 ms·

I hope eventually, with systems like landlock making sandboxing a bit more accessible, developers just start sandboxing their software by default. 3rd parties m

I hope eventually, with systems like landlock making sandboxing a bit more accessible, developers just start sandboxing their software by default. 3rd parties maintaining policies is less than ideal.

the8472 5y ago
Landlock still falls short of pledge() in some ways, one of them is that inheritance is mandatory which disincentives its use in tools that spawn other processes. I hope that linux will adopt something pledge-like one day.
- staticassertion 5y ago
  Not sure what you mean. Why would you not want inheritance to be mandatory?
  - the8472 5y ago
    If an executable spawns child processes by design then inheritance means you need the union of all capabilities. Without inheritance each executable can apply a smaller set of privileges to itself. Anyway, pledge[0] provides both options separately. You can restrict capabilities for just the current process and then for child processes. [0] https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2
    - staticassertion 5y ago
      But of course the parent needs the union of its child permissions. Otherwise how could it delegate them? A child process is still able to restrict itself further if it wants to, for example you could let it make the prctl syscall.
      - the8472 5y ago
        > But of course the parent needs the union of its child permissions. Otherwise how could it delegate them? By restricting which syscalls can be used during the current process to a narrow, non-inheritable Set A while, restricting which child executables can be called to Set F and those child executables have their own permission Sets B, C, etc. Additionally you can also put an inheritable Supersets B' and C' on the children if you don't trust them entirely to self-sandbox properly, but those will be less narrow because the executables may need a few more syscalls during program init, before self-isolating. That's one of the ideas behind pledge. You do some setup in the beginning, then lock yourself down. Similar to dropping root privs in network services, just more fine-grained. This works best if each process can limit itself tightly even when it spawns some helpers later which may transiently need some less tight restrictions. A union of permissions for multiple executables is going to looser than necessary.
        staticassertion 5y ago
        Sorry, I'm not getting it. This all sounds like normal sandboxing. Also, if you don't trust your child processes to sandbox you can fix that with an intermediary process.
        the8472 5y ago
        With sandboxing of the bubblewrap or firejail flavor you have one externally applied ruleset to a tree of processes. This ruleset must be lax because it is the union of all the permissions the processes may need at any time and on any execution path. This is bad because it makes your sandbox more permissive than necessary and specific points in time for specific processes pledge on the other hand allows a process to gradually drop privileges as it goes down different code paths. E.g. it could initially retain permissions to open files and enumerate directories because it has an option to do things recursively. But after checking arguments and no recursive option was requested it just opens a fixed list of files and then drops those caps. But it's a fancy tool (like ripgrep) that might spawn helper programs to parse the content and those may still have to open files on their own. So just because it locally dropped its own capability to open files (but retained the cap to spawn processes) doesn't mean its child processes should inherit that restriction, they can lock themselves down. It can still choose to impose separate restrictions on child processes externally, but that's orthogonal to the self-restrictions. This makes things more composable and allows for tighter sandboxing after program init.
gnoack 5y ago
I hope so too :) There are libraries at https://github.com/landlock-lsm https://github.com/landlock-lsm to simplify that, I'm using these productively for a few months. (In fact, I'm sending this from a landlocked web browser. :)) This also ties into the discussion thread about firejail being suid-root - Other than namespaces, Landlock is an unprivileged sandboxing mechanism and doesn't need to escalate privileges in order to drop privileges.
- staticassertion 5y ago
  Honestly, user namespaces might be scarier to me than setuid lol hopefully one day that will change.
  - gnoack 5y ago
    Sorry, my English... :) I meant "Unlike namespaces", not "Other than namespaces" -- Landlock does not use namespaces.
    - staticassertion 5y ago
      Yeah, I realized after that that was probably the case. I assume it uses unpriv ebpf? A bit less scary lol
      - gnoack 5y ago
        eBPF was the initial proposal, but Landlock didn't go with it in the end. It's just using a set of regular system calls, the logic behind it is just implemented in C in the kernel as a LSM.
WhyNotHugo 5y ago
> developers just start sandboxing their software by default For many kinds of software, I'd rather see the distribution or package maintainer work on the sand-boxing itself. I'm thinking stuff like Zoom or Skype where you actually wouldn't trust the app developer.

I hope eventually, with systems like landlock making sandboxing a bit more accessible, developers just start sandboxing their software by default. 3rd parties maintaining policies is less than ideal.

the8472 5y ago

Landlock still falls short of pledge() in some ways, one of them is that inheritance is mandatory which disincentives its use in tools that spawn other processes. I hope that linux will adopt something pledge-like one day.

staticassertion 5y ago
Not sure what you mean. Why would you not want inheritance to be mandatory?
- the8472 5y ago
  If an executable spawns child processes by design then inheritance means you need the union of all capabilities. Without inheritance each executable can apply a smaller set of privileges to itself. Anyway, pledge[0] provides both options separately. You can restrict capabilities for just the current process and then for child processes. [0] https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2
  - staticassertion 5y ago
    But of course the parent needs the union of its child permissions. Otherwise how could it delegate them? A child process is still able to restrict itself further if it wants to, for example you could let it make the prctl syscall.
    - the8472 5y ago
      > But of course the parent needs the union of its child permissions. Otherwise how could it delegate them? By restricting which syscalls can be used during the current process to a narrow, non-inheritable Set A while, restricting which child executables can be called to Set F and those child executables have their own permission Sets B, C, etc. Additionally you can also put an inheritable Supersets B' and C' on the children if you don't trust them entirely to self-sandbox properly, but those will be less narrow because the executables may need a few more syscalls during program init, before self-isolating. That's one of the ideas behind pledge. You do some setup in the beginning, then lock yourself down. Similar to dropping root privs in network services, just more fine-grained. This works best if each process can limit itself tightly even when it spawns some helpers later which may transiently need some less tight restrictions. A union of permissions for multiple executables is going to looser than necessary.
      - staticassertion 5y ago
        Sorry, I'm not getting it. This all sounds like normal sandboxing. Also, if you don't trust your child processes to sandbox you can fix that with an intermediary process.
        the8472 5y ago
        With sandboxing of the bubblewrap or firejail flavor you have one externally applied ruleset to a tree of processes. This ruleset must be lax because it is the union of all the permissions the processes may need at any time and on any execution path. This is bad because it makes your sandbox more permissive than necessary and specific points in time for specific processes pledge on the other hand allows a process to gradually drop privileges as it goes down different code paths. E.g. it could initially retain permissions to open files and enumerate directories because it has an option to do things recursively. But after checking arguments and no recursive option was requested it just opens a fixed list of files and then drops those caps. But it's a fancy tool (like ripgrep) that might spawn helper programs to parse the content and those may still have to open files on their own. So just because it locally dropped its own capability to open files (but retained the cap to spawn processes) doesn't mean its child processes should inherit that restriction, they can lock themselves down. It can still choose to impose separate restrictions on child processes externally, but that's orthogonal to the self-restrictions. This makes things more composable and allows for tighter sandboxing after program init.

gnoack 5y ago

I hope so too :) There are libraries at https://github.com/landlock-lsm https://github.com/landlock-lsm to simplify that, I'm using these productively for a few months. (In fact, I'm sending this from a landlocked web browser. :)) This also ties into the discussion thread about firejail being suid-root - Other than namespaces, Landlock is an unprivileged sandboxing mechanism and doesn't need to escalate privileges in order to drop privileges.

staticassertion 5y ago
Honestly, user namespaces might be scarier to me than setuid lol hopefully one day that will change.
- gnoack 5y ago
  Sorry, my English... :) I meant "Unlike namespaces", not "Other than namespaces" -- Landlock does not use namespaces.
  - staticassertion 5y ago
    Yeah, I realized after that that was probably the case. I assume it uses unpriv ebpf? A bit less scary lol
    - gnoack 5y ago
      eBPF was the initial proposal, but Landlock didn't go with it in the end. It's just using a set of regular system calls, the logic behind it is just implemented in C in the kernel as a LSM.

WhyNotHugo 5y ago

> developers just start sandboxing their software by default For many kinds of software, I'd rather see the distribution or package maintainer work on the sand-boxing itself. I'm thinking stuff like Zoom or Skype where you actually wouldn't trust the app developer.