Re: Malicious root user sandboxing

Ihor Antonov <[email protected]> Wed, 20 May 2020 22:16:58 -0700
Newsgroups	gmane.os.freebsd.security.general
Message-ID	<26311043.RtLttYiU3N@amos>
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 (application/pgp-signature, 833 B)