Re: Malicious root user sandboxing
On Mon, 25 May 2020 at 14:00, Ihor Antonov wrote: > > I was looking at Capsicumizer and it looks very interesting. > The only reason I was hesitant is that this is an external application, not a > FreeBSD core. Is it going to be included in FreeBSD in some distant future? There are no explicit plans at this point and right now I would describe it as a solid proof of concept - it works well, but only a limited amount of functionality is supported by libpreopen. That said, I would be very happy to see it developed further and become a component of FreeBSD. ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Malicious root user sandboxing
On Monday, 25 May 2020 09:37:19 PDT Ed Maste wrote: > On Sat, 16 May 2020 at 20:02, Ihor Antonov 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. Thanks Ed, I was looking at Capsicumizer and it looks very interesting. The only reason I was hesitant is that this is an external application, not a FreeBSD core. Is it going to be included in FreeBSD in some distant future? -- Ihor Antonov signature.asc Description: This is a digitally signed message part.
Re: Malicious root user sandboxing
21.05.2020 12:16, Ihor Antonov wrote: > Jails have a lot of drawbacks to. [skip] > I tried jails and was left disappointed. Just use sysutils/ezjail from ports that hides all the hassle and does it all for you, so you need to perform installworld for the host system only. >> Also, shared PAM does not mean duplication of system user database, >> take a look at: man -k pam_|fgrep '(8)' > > The idea was to have a lightweight solution with minimum moving parts. > Bringing machinery > like LDAP into this defeats the purpose of the exercise. If you don't like LDAP, use FreeRADIUS and pam_radius. Combined with ezjail, it is most lightweight solution you may currently obtain without writing additional kernel level code. ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Malicious root user sandboxing
On Saturday, 16 May 2020 17:28:46 PDT Eugene Grosbein wrote: > 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. Jails have a lot of drawbacks to. In most basic (by the book) example you effectively end up with a separate machine, which just happens to share same kernel with the host. And you need to manage this machine separately patches, upgrades, etc. (viva tools like ansible / chef) This is not very different from "just put it on a different VM" suggestion. If you try to go off the handbook script and try using nullfs and unionfs to re-use pieces of your FS you quickly find out how limited those tools are. You can't mount a single file into a directory, nullfs and unionfs operate only on directories. Example: try to put a file into jails /etc. Your options are: a) mount the whole directory and duplicate/overwrite (depending on how exactly you do it) a lot of files b) copy the file In either case you are not far off the "separate VM" management scenario You also can't just mount / to /path/to/jail - so you end up mounting /bin /etc /sbin ... into the jail with a separate commands. And this is possible to do, but now you can't use a lot of conveniences that jail.conf has because your custom mounts conflict with jail's mount.* directives (and the order in which they execute is undocumented) I tried jails and was left disappointed. Jails are just VMs, trying to treat them somewhat closer to Linux containers is not justifiable given how much trouble it brings. > Also, shared PAM does not mean duplication of system user database, > take a look at: man -k pam_|fgrep '(8)' The idea was to have a lightweight solution with minimum moving parts. Bringing machinery like LDAP into this defeats the purpose of the exercise. > 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). Not an option as defeats the purpose of the excercise. -- Ihor Antonov signature.asc Description: This is a digitally signed message part.
Re: 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). ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
