thr3ads.net - freebsd security - Malicious root user sandboxing [May 2020]

If this information is useful, please help other people find it:
Share via:

Ihor Antonov

2020-May-17 00:02 UTC

Malicious root user sandboxing

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.

Threat Model:
------------

Assumption is that attacker have gained remote control of the smtp server
process. It is necessary to limit the blast radius in case of the RCE.

What I want to achieve:
-----------------------

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.

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.

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

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

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.

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

How to get there?:
-----------------

- securelevel=3 pretty much solves requirement 7

- firewall can prevent undesired incoming or outgoing connections. Although
firewall does not distinguish between applications(other apps need other
ports) and so requirement 1 can't be satisfied without putting smtp server
in its own VNET jail.

This is as far as I was able to go before I started researching MAC Framework.
And it seems at first to be able to solve some of the problems, but not quite.

- mac_bsdextended can be used to satisfy requirements 2 and 8 but it operates
on UIDs so access will be restricted for any root process, which
is undesired.
Is there a way to target specific process or login class with bsdextended?

- Same goes for mac_portaclmac - operates only on UID level. So requirement 1
can't be satisfied without impacting the rest of the system

So it seems that there is no way to sandbox an untrusted application with
MAC without severely restricting whole OS usability.

And this warning in man pages confirms my suspicions:
> man 4 mac
> While the MAC Framework design is intended to support the containment of
> the root user, not all attack channels are currently protected by entry
> point checks. As such, MAC Framework policies should not be relied on,
in
> isolation, to protect against a malicious privileged user.

Questions I did not find any answers to:
----------------------------------------

- Is it possible to restrict login class change for a root process?
(requirement 3)

- How to enforce resource limits? rctl seem to target process, user,
loginclass or jail.
using it for all root process is undesired.
login class is coupled with the question above
process - can be escaped by forking a child.

- Is it possible to satisfy my requirements with Biba/MLS?

- Is it possible to label an executable with MLS so that the running process
will inherit the label?

- Is it possible to shake-off Biba/MLS the label by forking a
child or changing login class?

So far it seems that my endeavor is doomed. Any comments or suggestions are
appreciated.

Thanks
------------
Ihor Antonov

--
Ihor Antonov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freebsd.org/pipermail/freebsd-security/attachments/20200516/4d6f6163/attachment.sig>

Eugene Grosbein

2020-May-17 00:28 UTC

head link

Malicious root user sandboxing

17.05.2020 7:02, Ihor Antonov wrote:
> So far it seems that my endeavor is doomed. Any comments or suggestions are
> appreciated.
You'll need to write and test lots of kernel-level code to achieve this.

I'd suggest you re-think your decision about jails because it seems jails
can really be the solution
if you combine jail with other system abilities. For example, sharing subtree
with r/o access is easily achieved using read-only nullfs mount.

Also, shared PAM does not mean duplication of system user database,
take a look at: man -k pam_|fgrep '(8)'

Usage of jails does not require any modification of the application.
I did it for multiple setups and it works perfectly.

As last resort, you may run nested FreeBSD system using bhyve(8).

Ed Maste

2020-May-25 16:37 UTC

head link

Malicious root user sandboxing

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.

freebsd security - May 2020 - Malicious root user sandboxing

Malicious root user sandboxing

Malicious root user sandboxing

Malicious root user sandboxing