App firewall through netfilter & landlock

[rcoscali]

Hi Mickaël

First thanks for your marvelous job. This is not an issue, more a feature request. Second for being able to create an app firewall it would be interesting to be able to have a landlock syscall for installing a process bound netfilter firewall rule. Of course a specific netfilter patch could be necessary (at least a netfilter module). What could be also interesting would be to let an application activate some packet validation modules (through queues that could then be used in userland in a dedicated app as suricata). Providing a packet inspection should be easy at the app level. And finally a sandboxer with a GUI would be something really valuable (didn't yet check the rust sandboxer, I will). It could generate the locking code. I'd like to hear your thoughts about these and if it is something you think achievable. For the netfilter part I'll try to propose a PR soon but as it could imply also a netfilter PR (to manage the link between ruleset & nf table in some way) ...

Best

[rcoscali]

Just thinking a little bit more about the sandboxer GUI. It should be able to startup from a sandbox free binary package of the app. This will allow to setup all startup file access rules. It should be able to select a kind of application for which a sandbox is wanted (console based, GUI, server, etc ...). These app templates should allow to setup some startup rules (a console app should have access to a term, a GUI app should have access to an X11 session and its related network comm, same for a server). Of course this template can then be customized. Perhaps the best way to then customize such rules would be through a VScode extension (for ex). We could also use elf for adding rules for loadable libraries. Specific ruleset for each language (C, C++, rust, go, all have some specific needs). Another interesting feature would be to enumerate all syscalls and add a rule for limiting their use to the lowest possible set (attack surface reduction through a seccomp wrapper ?? or direct seccomp usage -- i saw a pledge port based on seccomp bpf in github). I think to another feature that would be nice, being able to use a call graph for verifying chains of syscalls (this is not an easy stuff, but could it be something supported by landlock/seccomp in the future...). Once the dev finished his sandbox rules, an activate_sandbox function is generated and could be added through a compiler feature (ex GNU_IFUNC allowing to deploy several levels of sandboxing ??? just another idea) or by rebuilding/relinking app.

Hope some will find these ideas and use it ...

[l0kod]

Hi Mickaël

Hi Rémi,

First thanks for your marvelous job.

Thanks, I bootstrapped the project but we're now a few working on Landlock. :wink:

This is not an issue, more a feature request. Second for being able to create an app firewall it would be interesting to be able to have a landlock syscall for installing a process bound netfilter firewall rule. Of course a specific netfilter patch could be necessary (at least a netfilter module). What could be also interesting would be to let an application activate some packet validation modules (through queues that could then be used in userland in a dedicated app as suricata). Providing a packet inspection should be easy at the app level.

An application firewall able to filter the content of packets would be interesting, but that poses some challenges. The main one is that Netfilter is not designed to handle rules written by attackers, so I think it would not be trivial to get such guarantee, and of course the Netfilter maintainers need to be convince this is a good idea.

Landlock's design is flexible enough and should not require a new syscall but new access rights and rules, but it's not clear to me how to create safe and simple filtering rules that would still be flexible.

Our thinking about the current Lanlock's TCP port filtering is that it is simple and it addresses a lot of app firewall requirements. For instance, controlling remote peer addresses may not make sense without name resolution. There is also a work in progress with socket creation control #6 and UDP port filtering #10. Help for such work is welcome!

And finally a sandboxer with a GUI would be something really valuable (didn't yet check the rust sandboxer, I will). It could generate the locking code. I'd like to hear your thoughts about these and if it is something you think achievable.

I started working on a new sandboxer, but there is a lot of foundational work required before thinking about a GUI.

For the netfilter part I'll try to propose a PR soon but as it could imply also a netfilter PR (to manage the link between ruleset & nf table in some way) ...

I'm looking forward this RFC! As a reminder, Linux development doesn't happen on GitHub with PRs. Please make sure the Netfilter community is in the loop.

Just thinking a little bit more about the sandboxer GUI. It should be able to startup from a sandbox free binary package of the app. This will allow to setup all startup file access rules. It should be able to select a kind of application for which a sandbox is wanted (console based, GUI, server, etc ...). These app templates should allow to setup some startup rules (a console app should have access to a term, a GUI app should have access to an X11 session and its related network comm, same for a server). Of course this template can then be customized. Perhaps the best way to then customize such rules would be through a VScode extension (for ex). We could also use elf for adding rules for loadable libraries. Specific ruleset for each language (C, C++, rust, go, all have some specific needs). Another interesting feature would be to enumerate all syscalls and add a rule for limiting their use to the lowest possible set (attack surface reduction through a seccomp wrapper ?? or direct seccomp usage -- i saw a pledge port based on seccomp bpf in github). I think to another feature that would be nice, being able to use a call graph for verifying chains of syscalls (this is not an easy stuff, but could it be something supported by landlock/seccomp in the future...). Once the dev finished his sandbox rules, an activate_sandbox function is generated and could be added through a compiler feature (ex GNU_IFUNC allowing to deploy several levels of sandboxing ??? just another idea) or by rebuilding/relinking app.

Hope some will find these ideas and use it ...

All this would be nice but it's out of scope for Landlock which is a kernel feature focused on sandboxing (i.e. access control).

However, feel free to share your progress on implementing such sandboxing app using Landlock, seccomp, and other security features!

[rcoscali]

All this would be nice but it's out of scope for Landlock which is a kernel feature focused on sandboxing (i.e. access control).

Sure, I was just in a silly mood ... but I think at last it could become useful for developers and for helping security. I'm looking at landlock code in the meantime and i'll try to enter it by looking at the issues you enlighten #6 & #10. 👍