Date: Sun, 24 Feb 2019 11:00:15 +0100 From: Alexander Leidinger <Alexander@leidinger.net> To: freebsd-rc@freebsd.org, jail@freebsd.org Subject: Proposal: automatic jailing of services (rc.d/*) [patch] Message-ID: <20190224110015.Horde.A9mrXMmDLkoyCbU47t5UxjM@webmail.leidinger.net>
next in thread | raw e-mail | index | archive | help
This message is in MIME format and has been PGP signed.
--=_fy4n2tsDPmdHd3oieZ_dzqP
Content-Type: multipart/mixed; boundary="=_DFoVyw8E2SrFbHVI-kNCyDP"
This message is in MIME format.
--=_DFoVyw8E2SrFbHVI-kNCyDP
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi,
Thanks to MWL for his upcoming jail book, it inspired me to come up with th=
is.
Note, I'm not subscribed to freebsd-rc, please keep at least jail@ in=20=20
copy=20(I'm subscribed there).
I propose to extend the rc system to automatically jail services in a=20=20
light=20sense (off by default, can be enabled on individual service=20=20
level).=20The "light sense" means to inherit the entire host (subject to=20=
=20
options).=20All programs have still access to the entire filesystem=20=20
(subject=20to user access permissions). By default no network access.=20=20
Optional=20access to the hosts IPv4, IPv6, raw sockets or full access to=20=
=20
all=20network related parts (see below for "service jail options").=20=20
Similar=20optional access for sysvipc, mlock and vmm.
The benefit of this approach (aside of being able to prevent network=20=20
and=20other access if needed (without removing the network at all) when=20=
=20
it=20is not enabled) is to put a service and all its children into a=20=20
limited=20process namespace. A service and its children only see=20=20
themselves=20but no other processes (a rc script which uses some checks=20=
=20
in=20start_cmd to see if some other services/processes are started needs=20=
=20
to=20be modified to do the checks in start_precmd, only start_cmd (and=20=
=20
stop_cmd)=20is jailed in this design (so far), so that a service can=20=20
check=20a lot more than what is possible in a jail), and you can kill=20=20
all=20of those in one go (jail -r svcj-<svc>).
Note: this can not be used for services which require access to=20=20
/dev/(k)mem,=20as this is prohibited in a jail even if the dev-entry is=20=
=20
there=20(this means you can not enable this feature for services which=20=
=20
start=20X.org to access a graphic card without my patches for X.org in a=20=
=20
jail).=20Other hard-coded jail restrictions apply too off course.
As an example for a service which needs network access, it would have=20=20
to=20have in the rc script
: ${svcname_svcj_options:=3D"net_basic")
to specify that it needs access to IPv4, IPv6 and access to reserved=20=20
ports=20(see below for more details).
This way the service comes with a default setting and an admin can=20=20
override=20what the service is allowed to do on his discretion in rc.conf.
There are off course drawbacks, depending on your point of view. If=20=20
you=20jail sshd, you can only see processes inside the sshd service jail=20=
=20
via=20ps/top/..., you can not use commands which require access to=20=20
/dev/(k)mem,=20you can not start ntpd from such a ssh session, and you=20=
=20
can=20not manage (stop/start via rc-means or kill) stuff which is=20=20
running=20in other service jails, or in short: all hard-coded jail=20=20
restrictions=20apply. If you stop such a service jail, the current=20=20
implementation=20removes the entire service jail (after running "service=20=
=20
stop"=20inside), so for sshd this would mean that any ssh connection to=20=
=20
the=20jailed sshd is killed instead of continuing like in the non=20=20
service=20jail case. So this is not something which can by enabled by=20=20
default=20and a careful review of what shall be handled in this way=20=20
needs=20to be done instead of enabling it blindly.
To enable jailing of a service, an admin has to specify=20=20
svcname_svcj=3D"YES" in rc.conf and optionally options via=20=20
svcname_svcj_options=3D"xxx" if it wants to override the settings/access=20=
=20
specified=20in the rc script (or set it if the rc script is not yet=20=20
modified=20to support service jails).
A rc script shall not enable a service jail by default, it's up to the=20=
=20
admin=20to enable that.
This also works in jails, but requires to set children.max to an=20=20
appropriate=20value for those jails (see jail(8) or MWLs upcoming book=20=
=20
for=20more info about hierarchical jails). As we expose=20=20
security.jail.param.children.*=20in jails, we could add a safetynet=20=20
inside=20the implementation to not use service jails even if configured,=20=
=20
when=20"jailed and cur =3D max".
RC settings:
<svc>_svcj=3D"YES/NO"
<svc>_svcj_options=3D"see_below"
service jails options translations:
netv4 -> ipv4=3Dinherit allow.reserved_ports
netv6 -> ipv6=3Dinherit allow.reserved_ports
net_basic -> ipv4=3Dinherit ipv6=3Dinherit allow.reserved_ports
net_raw -> allow.raw_sockets
net_all -> allow.socket_af allow.raw_sockets allow.reserved_ports=20=20
ipv4=3Dinherit ipv6=3Dinherit
sysvipc -> sysvmsg=3Dinherit sysvsem=3Dinherit sysvshm=3Dinherit
mlock -> allow.mlock
vmm -> allow.vmm
Attached is a proof of concept (only lightly tested with=20=20
start/stop/status/restart)=20so that you can play around with it a=20=20
little=20bit. Please don't focus on the patch. This mail is to seek=20=20
feedback=20about the feature and the quick design so far. To make it=20=20
explicit,=20I do not ask (yet) if and which service to handle like this=20=
=20
by=20default. This is just the possibility to do something like this.
Bye,
Alexander.
--=20
http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF
--=_DFoVyw8E2SrFbHVI-kNCyDP--
--=_fy4n2tsDPmdHd3oieZ_dzqP
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJccmsvAAoJEBINsJsD+NiGXxQP/AkzLOI+MkW0EoQ/R+y9W/4U
CCBvuFntPLYfN3agONbLwwu/DEt8xqPRCA1UDBK2pe9UQQQj9WcXbVvb8bsr64fM
ZH+P0Wev/nkhRk0NyqQLvO0j2VRQnve9bnI8v1kdi5hjH9m796Ig81lHRBViCYTL
qyE1qz+rO5ocY8yWi98vOZy6HD32eehcl1g8KlnfD+SQ7R9uQ5lQHA1fLiFrs17L
HjVadlFX3QX6xsWKjrrQ53GTw7n+3mmtDYc+Jac+YEz5OT7TyK6tzobw6MkzNPnM
juEL4gznT17E5e1gtWIuqq+ZWGdOqNWpuTTyc6X9IO2H58kMpjWp6USk3mqjNR0x
bhaLadpsCh3yDo5c806JQ7mSYz5ryPPH7f/fYwcB99MIGcY3d+8KTgct65+pXyO8
2OxrDS3x9A+0BChFjdmNpLqoIiGBmj/3d1KaJJLbhKd0i/G+WpNdGuRiQk2N/7UD
eXpylUa8Yb+vTNvsRn3Qt6tWGctcBxidFtzSGAWycSNieWGcmwK+zH/PhiFHKSK5
O3TOBMDbsdhGjG6Re4CxI0aTHlO1Jyu9Q87eW2DUMnPS1f6dlzwS/mHv3SWGrPWm
jDwIgMBhlTFtMjowAkRmJcxn2HuvdsLz0jU4jqqcidTeCHvz9YoDiJb3rkoSxHiW
xgXoToaNcFdeU1tUXY9P
=Rx7/
-----END PGP SIGNATURE-----
--=_fy4n2tsDPmdHd3oieZ_dzqP--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190224110015.Horde.A9mrXMmDLkoyCbU47t5UxjM>