Malicious root user sandboxing

[Ed Maste]

On Sat, 16 May 2020 at 20:02, Ihor Antonov <ihor at antonovs.family> wrote:
>
> Hello FreeBSD Community,
>
> I am looking for possible options to sandbox an untrusted application that
> runs with root privileges.
>
> I can't use Jails or Capsicum as modification of the application is outside of
> the scope of my task and application needs to share the file system with
> some other applications. (several applications use PAM to authenticate
> users and they all have to have the same set of users, and I want
> to avoid duplicating system users across jails)
>
> For this write up I will use opensmptd server as an example application,
> but there are many more examples that fit the usecase.

Is the application dynamically linked? If so it's possible to do
"oblivious sandboxing" with Capsicum. There's a proof of concept in
the "Super Capsicumizer 9000" -
https://github.com/myfreeweb/capsicumizer. It builds on libpreopen
from MUN which handles filesystem access. This is not something that
will work "out of the box" today for your application, but is an area
of active interest that could benefit from a motivating use case. With
some development work (using the approach of capsicumizer +
libpreopen) it could be the basis for a quality sandbox.

> 1) Application should only be able to listen and talk to TCP port 25.
>    Initiating connections to other TCP ports and other address families
>    must be prevented.

This would be net new work, intercepting connect(2), accept(2) and
such, passing the args to a socket service, and returning the fd.

> 2) Application should only have write access to a specific directory, the
>    rest of the filesystem must be seen by the application as read-only.

Capsicumizer + libpreopen is most of the way there now. A little work
would be needed to extend it to support different permissions per
directory group.

> 3) Application should not be able to change it's login class.

This is inherent in capability mode.

> 4) Application should not be able to escape the sandbox by forking a child
>    process.

Capsicum does not address this, but the child starts in capability
mode and inherits the same sandbox restrictions. The real need then is
for comprehensive resource limits.

> 5) Application's resource usage must be limited.
>
> 6) Application should not be able to shake-off resource limits by forking
>    a child or changing login class.

This probably needs some rctl improvements.

> 7) Application should not be able to change system configuration, load/unload
>    kernel modules, modify firewall rules.
>
> 8) Application should not be able to create new system users,
>    or change passwords of existing users

These are inherent in capability mode.