Proposal: automatic jailing of services (rc.d/*) [patch]

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal: automatic jailing of services (rc.d/*) [patch]

freebsd-rc mailing list
Hi,

Thanks to MWL for his upcoming jail book, it inspired me to come up with this.

Note, I'm not subscribed to freebsd-rc, please keep at least jail@ in  
copy (I'm subscribed there).

I propose to extend the rc system to automatically jail services in a  
light sense (off by default, can be enabled on individual service  
level). The "light sense" means to inherit the entire host (subject to  
options). All programs have still access to the entire filesystem  
(subject to user access permissions). By default no network access.  
Optional access to the hosts IPv4, IPv6, raw sockets or full access to  
all network related parts (see below for "service jail options").  
Similar optional access for sysvipc, mlock and vmm.

The benefit of this approach (aside of being able to prevent network  
and other access if needed (without removing the network at all) when  
it is not enabled) is to put a service and all its children into a  
limited process namespace. A service and its children only see  
themselves but no other processes (a rc script which uses some checks  
in start_cmd to see if some other services/processes are started needs  
to be modified to do the checks in start_precmd, only start_cmd (and  
stop_cmd) is jailed in this design (so far), so that a service can  
check a lot more than what is possible in a jail), and you can kill  
all of those in one go (jail -r svcj-<svc>).
Note: this can not be used for services which require access to  
/dev/(k)mem, as this is prohibited in a jail even if the dev-entry is  
there (this means you can not enable this feature for services which  
start X.org to access a graphic card without my patches for X.org in a  
jail). Other hard-coded jail restrictions apply too off course.

As an example for a service which needs network access, it would have  
to have in the rc script
: ${svcname_svcj_options:="net_basic")
to specify that it needs access to IPv4, IPv6 and access to reserved  
ports (see below for more details).
This way the service comes with a default setting and an admin can  
override what the service is allowed to do on his discretion in rc.conf.

There are off course drawbacks, depending on your point of view. If  
you jail sshd, you can only see processes inside the sshd service jail  
via ps/top/..., you can not use commands which require access to  
/dev/(k)mem, you can not start ntpd from such a ssh session, and you  
can not manage (stop/start via rc-means or kill) stuff which is  
running in other service jails, or in short: all hard-coded jail  
restrictions apply. If you stop such a service jail, the current  
implementation removes the entire service jail (after running "service  
stop" inside), so for sshd this would mean that any ssh connection to  
the jailed sshd is killed instead of continuing like in the non  
service jail case. So this is not something which can by enabled by  
default and a careful review of what shall be handled in this way  
needs to be done instead of enabling it blindly.

To enable jailing of a service, an admin has to specify  
svcname_svcj="YES" in rc.conf and optionally options via  
svcname_svcj_options="xxx" if it wants to override the settings/access  
specified in the rc script (or set it if the rc script is not yet  
modified to support service jails).

A rc script shall not enable a service jail by default, it's up to the  
admin to enable that.

This also works in jails, but requires to set children.max to an  
appropriate value for those jails (see jail(8) or MWLs upcoming book  
for more info about hierarchical jails). As we expose  
security.jail.param.children.* in jails, we could add a safetynet  
inside the implementation to not use service jails even if configured,  
when "jailed and cur = max".

RC settings:
<svc>_svcj="YES/NO"
<svc>_svcj_options="see_below"

service jails options translations:
netv4 -> ipv4=inherit allow.reserved_ports
netv6 -> ipv6=inherit allow.reserved_ports
net_basic -> ipv4=inherit ipv6=inherit allow.reserved_ports
net_raw -> allow.raw_sockets
net_all -> allow.socket_af allow.raw_sockets allow.reserved_ports  
ipv4=inherit ipv6=inherit
sysvipc -> sysvmsg=inherit sysvsem=inherit sysvshm=inherit
mlock -> allow.mlock
vmm -> allow.vmm


Attached is a proof of concept (only lightly tested with  
start/stop/status/restart) so that you can play around with it a  
little bit. Please don't focus on the patch. This mail is to seek  
feedback about the feature and the quick design so far. To make it  
explicit, I do not ask (yet) if and which service to handle like this  
by default. This is just the possibility to do something like this.

Bye,
Alexander.

--
http://www.Leidinger.net [hidden email]: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    [hidden email]  : PGP 0x8F31830F9F2772BF

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: automatic jailing of services (rc.d/*) [patch]

Ben Woods
On Mon, 25 Feb 2019 at 10:24, Miroslav Lachman <[hidden email]> wrote:

> Interesting idea but patch was stripped by mailing list. Can you put it
> online and post the link to it?
>


Indeed, interesting idea!

The best options would be to attach the patch either to a bugzilla report (
https://bugs.freebsd.org) or a phabricator review (
https://reviews.freebsd.org).

Regards,
Ben

--
From: Benjamin Woods
[hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: automatic jailing of services (rc.d/*) [patch]

freebsd-rc mailing list
In reply to this post by freebsd-rc mailing list
http://www.leidinger.net/FreeBSD/current-patches/rc_svc_jails.diff

--
Send from a mobile device, please forgive brevity and misspellings.

Am 24. Februar 2019 9:48:19 nachm. schrieb Miroslav Lachman <[hidden email]>:

> Alexander Leidinger via freebsd-jail wrote on 2019/02/24 11:00:
>
> [...]
>
>> Attached is a proof of concept (only lightly tested with
>> start/stop/status/restart) so that you can play around with it a little
>> bit. Please don't focus on the patch. This mail is to seek feedback
>> about the feature and the quick design so far. To make it explicit, I do
>> not ask (yet) if and which service to handle like this by default. This
>> is just the possibility to do something like this.
>
> Interesting idea but patch was stripped by mailing list. Can you put it
> online and post the link to it?
>
> Kind regards
> Miroslav Lachman



_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "[hidden email]"