Date: Sat, 16 May 2020 17:02:04 -0700 From: Ihor Antonov <ihor@antonovs.family> To: freebsd-security@freebsd.org Subject: Malicious root user sandboxing Message-ID: <1641188.rRC0nNcZtX@amos>
index | next in thread | raw e-mail
[-- Attachment #1 --]
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
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEERRGvVtv7zdxEBhtZWJxtLLeFgVIFAl7AfvwACgkQWJxtLLeF
gVL1ew/7BvokPy3flPEXb8p06jKBGejcpFcear3XwUNl6lewT5sQobqUU74gZ36q
t+t6r/UF5PWfoVOwGG2rgDNY6d0JdVJhFGwcmTss+68vlvAwOapPr91Uu1zT3V+G
aP3ddI715/p2rB9GYdPhVblRMVQcI+WLf1cE3utVivF59sQsL3lGAfjlY8nccz5A
X7Tdzspn4pRczJZAxAWeqsF/5SbEQRstSV8etPKU1EX5YLOR5wkreXEiVGSdnML2
7pEuTJGdEFgZQrv9lGBmLlyQfhKhKy+uEe9PVbF+xCNpnUhb3HcVPEAO5ALoUyNE
hXCKq3qYvCLyhr90fMBEOsA9iiMwzvZcxn524ZGFP0eti/NafskGv8hNgTACW/wM
GARb5Emi5W4ozVVsXryHB0Mr8M12VI26EtJZMWTcWkmdxa92m1tiXDnsetcF9FKY
zL5HE9qjhZZ2PgAek4nbiOkGGNomMUxCcxc8MeDcfgqGUJ2NCyRsgnMsjHl0ndrO
7ZyrzG1oP9bJkF4MYHlGeiDLEysMJETDqu2Zl0kQlgSkKiuqrDRFQAponadjlElf
X001KRWvYyXKb/Z8qDTahDgKZmK+qJMNcEW+D43Gy+A2Jw3Ol8VhA2Cm+NCl/tUt
OS/Vh8fMr9iQZa4k8ye8twY40ImNQCoysXK6eXC4SCmeDiH+hcQ=
=MoZH
-----END PGP SIGNATURE-----
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1641188.rRC0nNcZtX>