Re: Auto-jailing of services - 2nd implementation

Quoting FreeBSD User <freebsd@walstatt-de.de> (from Sun, 15 May 2022  
12:49:06 +0200):

> On Sun, 03 Apr 2022 21:48:42 +0200
> Alexander Leidinger <Alexander@leidinger.net> wrote:
>
>> Hi,
>>
>> attached is a new implementation of service jails (auto-jailing of
>> services). This one now supports rc command prefixes (e.g. onestart)
>> and I tested it in nested jails. The benefit of auto-jailing services
>> is, that you can apply some restrictions to services (and what other
>> processes it may see). If your service requires access to network but
>> not sysvipc, and it doesn't run as root, it can be limited to network
>> access with or without raw sockets, filesystem-permitted files, and
>> doesn't see other processes on the system.
>>
>> For a few services I have added the required "svcj-config" in the
>> start scripts (e.g. network access for syslog by setting
>> syslogd_svj_options=net_basic).
>>
>> Possible svcj config options for service jails:
>> +				netv4)
>> +					_svcj_cmd_options="ip4=inherit
>> allow.reserved_ports ${_svcj_cmd_options}"
>> +					;;
>> +				netv6)
>> +					_svcj_cmd_options="ip6=inherit
>> allow.reserved_ports ${_svcj_cmd_options}"
>> +					;;
>> +				net_basic)
>> +					_svcj_cmd_options="ip4=inherit ip6=inherit
>> allow.reserved_ports ${_svcj_cmd_options}"
>> +					;;
>> +				net_raw)
>> +					_svcj_cmd_options="allow.raw_sockets
>> ${_svcj_cmd_options}"
>> +					;;
>> +				net_all)
>> +					_svcj_cmd_options="allow.socket_af
>> allow.raw_sockets allow.reserved_ports ip4=inherit ip6=inherit  
>> ${_svcj_cmd_options}"
>> +					;;
>> +				sysvipc)
>> +					_svcj_cmd_options="sysvmsg=inherit
>> sysvsem=inherit sysvshm=inherit  ${_svcj_cmd_options}"
>> +					;;
>> +				mlock)
>> +					_svcj_cmd_options="allow.mlock
>> ${_svcj_cmd_options}"
>> +					;;
>> +				vmm)
>> +					_svcj_cmd_options="allow.vmm
>> ${_svcj_cmd_options}"
>>
>> By setting syslogd_svcj="YES" in rc.conf your syslogd will be started
>> in a jail which inherits the full filesystem and the ipv4 and ipv6
>> addresses of the parent.
>>
>> It would be nice if interested people could experiment a little bit
>> with this, e.g. adding name_svcj_options="X Y" from above and
>> name_svcj="YES" into rc.conf and see if it works. Note, doing that for
>> sshd doesn't make sense in the generic case, it wouldn't see your
>> jails. It may make sense for services.
>>
>> Any kind of feedback and tested name_svcj_options submissions welcome...
>>
>> Bye,
>> Alexander.
>>
>
> Hello Alexander Leidinger,
>
> is this really interesting feature already part of recent CURRENT rc  
> subsystem or do I

No.

> have to "patch" CURRENT with the rc script provided by some place  
> first to obtain the
> functionality you are talking here about?

The patch was supposed to be attached to the mail you quoted. A more  
recent patch (now with docu in the rc.conf man page) is attached to  
this email (rc.subr + service command + man pages + a few services ->  
"grep diff svcjails.diff" for the list of OS services which can enable  
without research about the svcj_options). At least /etc/rc.subr and  
/usr/sbin/service need to be patched (respectively a  
buildworld+installworld).

> Thanks in advance and kind regards
>
> O. Hartmann
>
> p.s. would it be possible toput as service with a dedicated network  
> interfacing (say,
> jailed vnet/vlan, forinstance an asterisk service running on a small  
> router appliance, as
> we do in our projects?).

This will use the networking of the host. This is really automatic  
stuff, no additional network interface (all what the hosts sees is  
also available in the service-jail), no dedicated directory/filesystem  
area (as if it runs unjailed). All is used from the host. The  
additional security this provides is the limit of what the process is  
allowed to do in the kernel and the namespace isolation. So you could  
prevent sysvipc access. You could restrict it to ipv6 even if ipv4 is  
configured. You wouldn't see processes outside of the service jail  
even if running as root. If you want more advanced things, you need to  
create a jail on your own. Parts of what service jails do, could be  
done with capabilities (sometimes even with more restrictions), but  
this needs support inside the application for capabilities, whereas  
service jails do not need changes to the application itself.

If you want to put asterisk into one of my service jails, you would  
have to set the following in rc.conf:
   asterisk_enable="YES"
   asterisk_svcj_options="<see the rc.conf man page for the options in  
the SERVICE JAILS part>"
   asterisk_svcj="YES"
The asterisk_svcj_options part is supposed to be included in the rc  
script of asterisk (if/once this is committed to FreeBSD), but can be  
specified in rc.conf to override it if needed (or to test things). For  
asterisk I would assume at least asterisk_svcj_options="net_basic".

There's also a svcj_all_enable variable, but as long as not all  
services have a correct setting of their svcj_options, this will not  
do what you mean.

Bye,
Alexander.

-- 
http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild@FreeBSD.org  : PGP 0x8F31830F9F2772BF