Re: Malicious root user sandboxing

Ihor Antonov <[email protected]> Mon, 25 May 2020 11:00:22 -0700
Newsgroups	gmane.os.freebsd.security.general
Message-ID	<9242947.RX05g1dFuk@amos>
On Monday, 25 May 2020 09:37:19 PDT Ed Maste wrote:
> On Sat, 16 May 2020 at 20:02, Ihor Antonov <[email protected]> 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 (application/pgp-signature, 833 B)