4 ms·

Alas, no whitelisting option. A service should start in an empty filesystem root without network access - and if we had something as convenient as pledge() also

Alas, no whitelisting option. A service should start in an empty filesystem root without network access - and if we had something as convenient as pledge() also without any allowed syscalls - and then you could only add what is needed. firejail does this a bit better but it also started out with a blacklist approach and it's more geared towards desktop application use, not system services.

Icathian 5y ago
One of my favorite podcasts, Risky Business[0] regularly plugs Airlock[1]. They seem like they might be the one out front, at least as a paid service. [0] https://risky.biz/netcasts/risky-business/ https://risky.biz/netcasts/risky-business/ [1] https://www.airlockdigital.com/ https://www.airlockdigital.com/
5e92cb50239222b 5y ago
What's the problem with firejail? Start with an empty profile, blacklist everything, and whitelist only the stuff you need. It works just fine for server applications, and unlike systemd isolation flags you can setup a proper separate firewall with the `netfilter` option.
- the8472 5y ago
  > blacklist everything, That isn't a whitelist approach.
  - Someone 5y ago
    > blacklist everything, and whitelist only the stuff you need That _is_ a whitelist approach.
    - the8472 5y ago
      Not really. For example if you have a construct like "blacklist *" and that wildcard is evaluated at construction time on some overlay filesystem then additional entries may sneak in later from the lower over the overlay because the wildcard expansion doesn't get updated. On the other hand if you start with a blank slate filesystem root and only bind exactly the whitelisted paths then there is nothing to leak through. There are other ways in which blacklist-all can fail to be equivalent to whitelisting.
  - goodpoint 5y ago
    That is exactly an allowlist approach.
- Seirdy 5y ago
  Firejail has had multiple sandbox escape vulns in the past. Firejail is an SUID executable in which sandbox escapes can lead to privilege escalation. In contrast, Systemd allows you to run services as unprivileged users, and even create users on demand. Systemd also supports firewalling: it supports IP address allow/deny policies, ports, etc. For more advanced firewall policies you're probably better off using an actual firewall daemon like firewalld or ufw.
Someone 5y ago
pledge is excellent, but it protects programmers against writing security bugs that have large impact, it doesn’t protect you against the software they write. It’s those programmers who restrict what their tools can do, and who decide when to throw the switch to enable those restrictions. If you trust those programmers, it’s indeed way more convenient than other tools, if only because it removes the need for configuring things twice. For example, instead of configuring your web server to serve files from /foo/bar/ _and_ telling SELinux that your web server is allowed to read from /foo/bar, you only configure the web server, and it will tell the OS “I shouldn’t read from anything but /foo/bar, starting … now”. You’ll have to trust the web server to do that, though.
- the8472 5y ago
  That's what it is intended for. But pledge has nice properties beyond that which are also useful for external sandboxing. Such as defining easy to understand syscall groups maintained by the kernel as new syscalls are introduced. If linux had that we could for example grant stdio+rpath and not worry about the kernel introducing preadv3 and programs compiled with that getting broken or suboptimal performance when isolated and it would automatically apply to equivalent io_uring implementations block equivalent SQEs too.
- nwmcsween 5y ago
  The problem of using all-encompassing filters to secure applications is they are crap. Take for example something using Bernstein chaining where permissions are properly separated for each process, with pledge you can restrict access, with global filters it still allows the highest privilege.

Icathian 5y ago

One of my favorite podcasts, Risky Business[0] regularly plugs Airlock[1]. They seem like they might be the one out front, at least as a paid service. [0] https://risky.biz/netcasts/risky-business/ https://risky.biz/netcasts/risky-business/ [1] https://www.airlockdigital.com/ https://www.airlockdigital.com/

5e92cb50239222b 5y ago

What's the problem with firejail? Start with an empty profile, blacklist everything, and whitelist only the stuff you need. It works just fine for server applications, and unlike systemd isolation flags you can setup a proper separate firewall with the `netfilter` option.

the8472 5y ago
> blacklist everything, That isn't a whitelist approach.
- Someone 5y ago
  > blacklist everything, and whitelist only the stuff you need That _is_ a whitelist approach.
  - the8472 5y ago
    Not really. For example if you have a construct like "blacklist *" and that wildcard is evaluated at construction time on some overlay filesystem then additional entries may sneak in later from the lower over the overlay because the wildcard expansion doesn't get updated. On the other hand if you start with a blank slate filesystem root and only bind exactly the whitelisted paths then there is nothing to leak through. There are other ways in which blacklist-all can fail to be equivalent to whitelisting.
- goodpoint 5y ago
  That is exactly an allowlist approach.
Seirdy 5y ago
Firejail has had multiple sandbox escape vulns in the past. Firejail is an SUID executable in which sandbox escapes can lead to privilege escalation. In contrast, Systemd allows you to run services as unprivileged users, and even create users on demand. Systemd also supports firewalling: it supports IP address allow/deny policies, ports, etc. For more advanced firewall policies you're probably better off using an actual firewall daemon like firewalld or ufw.

Someone 5y ago

pledge is excellent, but it protects programmers against writing security bugs that have large impact, it doesn’t protect you against the software they write. It’s those programmers who restrict what their tools can do, and who decide when to throw the switch to enable those restrictions. If you trust those programmers, it’s indeed way more convenient than other tools, if only because it removes the need for configuring things twice. For example, instead of configuring your web server to serve files from /foo/bar/ _and_ telling SELinux that your web server is allowed to read from /foo/bar, you only configure the web server, and it will tell the OS “I shouldn’t read from anything but /foo/bar, starting … now”. You’ll have to trust the web server to do that, though.

the8472 5y ago
That's what it is intended for. But pledge has nice properties beyond that which are also useful for external sandboxing. Such as defining easy to understand syscall groups maintained by the kernel as new syscalls are introduced. If linux had that we could for example grant stdio+rpath and not worry about the kernel introducing preadv3 and programs compiled with that getting broken or suboptimal performance when isolated and it would automatically apply to equivalent io_uring implementations block equivalent SQEs too.
nwmcsween 5y ago
The problem of using all-encompassing filters to secure applications is they are crap. Take for example something using Bernstein chaining where permissions are properly separated for each process, with pledge you can restrict access, with global filters it still allows the highest privilege.