[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: A Box API without the Sand
From:       Allan Jude <allanjude () freebsd ! org>
Date:       2021-01-08 14:51:26
Message-ID: 31d89aed-4871-a42a-fbc8-2be617381a95 () freebsd ! org
[Download RAW message or body]

On 2021-01-07 14:42, Mina Galić wrote:
> Hello FreeBSD developers
> 
> I'm trying to find an (existing) API on FreeBSD which allows me to box in a process \
> and all of its descendants. That box should be easy to identify, and allow process \
> management, accounting and resource management. 
> Unfortunately all boxes Iʼm finding come pre-filled with Sand that's impossible to \
> get rid of, or lack some of the other requirements. 
> An analogue for such an API can be found in Solaris Contracts and Linux Cgroups.
> 
> Cgroups are extensively used in many init implementations on Linux to contain, \
> identify and control services. Personally, i used contracts on Solaris for that \
> very purpose, in an in-house deployment software, long before systemd was hip. 
> I would like to do something like that in init/rc on FreeBSD. But i can't seem to \
> find an API that fits the bill. 
> The normal POSIX process management facilities, like process groups and process \
> sessions are too easy to escape. But given their primary use is job control, that's \
> a feature, not a bug. Either way, they can be ruled out. 
> The closest we have are jail(2) and Capsicum(4), as well as the functions \
> supplementing the latter, such as pdfork(2) & co. 
> Jails are really good at containing and identifying process groups, and for \
> managing their resources. However, jailing every single daemon on a system, while \
> desirable by some, would make many daemons useless. sshd and monitoring software \
> are my prime examples, but there are probably many more. 
> Capsicum, again, seems more concerned with the Sand than the box: i cannot seem to \
> find anything that would help identify a process group. Except for pdfork(2)'s \
> procdesc(4). 
> Fortuitously, these can be used independently of Capsicum, so that means we have an \
> identity and control, but i can't find any information on whether all descentants \
> will remain within the same procdesc. 
> That's as far as my research has gotten me, so before i dig myself any deeper, i'd \
> like to ask for your help. 
> And, most importantly, if no such API exists yet, where to start in adding it, or \
> modifying an existing API to suit these requirements? 
> Best regards,
> 
> Mina
> https://alpha.pkgbase.live/
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
> 

A few different ideas in this area have been discussed before. I
remember a conversation with John Baldwin at one of the FreeBSD Storage
Summits, about the idea of a 'null' jail.

Basically a jail with no restrictions, one that uses / instead of a
chroot, inherits the network and shared memory namespaces, etc.

The main advantage to this abstraction is that it builds on a lot of
existing functionality. It gives you a top level identifier (jail id),
and can already have a lot of policies applied to it (cpuset, RCTL
resource limits, etc)

You can mostly already control what devices from /dev are visible.

I think what we would need to do is define what else needs to be
different from a jail. Like do we need the ability to allow processes
inside the container to see the processes from the host?

There may be a few places that will be more problematic. ZFS
automatically enforces its restrictions if your jail ID is not 0.


-- 
Allan Jude
_______________________________________________
freebsd-hackers@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"


[prev in list] [next in list] [prev in thread] [next in thread]