[PATCH] Xorg in a jail

Sun Mar 9 18:14:25 UTC 2014

On Sun, 9 Mar 2014 01:26:40 +0000
Tom Evans <tevans.uk at googlemail.com> wrote:

> I've been reinstalling my home server with 10-STABLE and wanted to
> compartmentalise all the disparate tasks it does - file storage, DNS,
> web servers and mplayer/xorg/media stuff in general - in to a separate
> jail for each task.
> 
> For the most part, this was quite straightforward, apart from with
> xorg I found that it wasn't quite supported. I found Alexander's
> patch, and the work Jamie did in part integrating it, allowing kmem
> read, and reworked it for 10-STABLE.

Seems you have an old one. Attached is what I was sending to jamie not
long ago (but this is not in the FreeBSD tree due to the conclusion that
such a huge impact on the security part should not be a simple allow.xxx
switch).

> From Jamie's emails it looked like he was working on a way of properly
> integrating these permissions in a more unified way, but I had a
> pressing need :)
> 
> I've tested this on 10-STABLE r262457M, intel graphics (ivy bridge,
> WITH_NEW_XORG), and everything seems to work just fine. I'm going to
> try out radeonkms and nvidia tomorrow also.

I use it with NVidia hardware (FreeBSD 11-current shortly after the
switch to 11-current), I also have an old machine with a radeon card
where the patch works too (with a very old 10-current).

> Also please note that whilst I want things jailed for separation and
> neatness concerns rather than security, it must be pointed out that
> letting one jail read and write kernel memory of the whole machine is
> not at all secure! Anyone with root in this xorg jail would be able to
> break free of the jail.

This is correct.

> I'm not sure I did the jail allow parameters right, but it works for
> me - I would appreciate someone more competent taking a look! Also,
> dev_io_access should probably be renamed or using it to control access
> to /dev/mem split out from it? Also, is the style right? vim: noet
> sw=8 ts=8 is what I was using.

The attached patch uses "allow.kmem_access" for both.

> Cheers
> 
> Tom
> 
> PS: I haven't tested any input devices yet with this, let me know!
> 
> Instructions:
> 
> Apply patch, rebuild world and kernel, install and update
> jails/basejails
> 
> Create /etc/devfs.rules to unhide the pertinent devices and restart
> devfs This is what I am using, it might be overkill...

Some parts are not needed, you don't need the console, and with nvidia
hardware you need the nvidia devices. It's also enough to have the tty
you want to use Xorg on (by default ttyv8, my rules also have ttyv0,
but I haven't tested if it is really needed... it's still "naturally
grown" for ttyv0).

>   [devfsrules_unhide_xorg=8]
>   add include $devfsrules_hide_all
>   add include $devfsrules_unhide_basic
>   add include $devfsrules_unhide_login
>   add path agpgart unhide
>   add path console unhide
>   add path consolectl unhide
>   add path dri unhide
>   add path 'dri/*' unhide
>   add path io unhide
>   add path mem unhide
>   add path pci unhide
>   add path tty unhide
>   add path ttyv0 unhide
>   add path ttyv1 unhide
>   add path ttyv8 unhide

See the attached rules. I have two desktop entries (the second one is
for jails with zfs datasets) in there. Normally you want to have audio
devices, a mouse and a keyboard for a desktop. There are some more
permissions, I also give access to optical drives and USB memory
sticks and a TV tuner, you may not want to give that broad permissions
(remove the cuse/cam/usb part).

> Set sysctls on jail host to allow jails to have permission granted to
> them to access (in particular) /dev/mem, /dev/io and /dev/dri/*
> 
>   security.jail.dev_io_access=1
>   security.jail.dev_dri_access=1

Do NOT use the sysctls in this patch, they allow all jails to access the
devices, if the devfs rules are appropriate. The attached patch doesn't
have them anymore.

I had them in in the first implementation, then jamie introduced the
allow.XXX and I transitioned to this but forgot to remove the sysctls
after migrating my jail. I removed them recently before sending the
patch to jamie after his kmem change.

> Configure your chosen jail to use these devfs rules and allow them to
> use the devices. I use ezjail, so for me this meant changing
> /usr/local/etc/ezjail/<name_of_jail> and setting these lines:
> 
>   export jail_xorg_foo_com_devfs_ruleset="8"
>   export jail_xorg_foo_com_parameters="allow.dev_io_access=1
> allow.dev_dri_access=1"

With the attached patch this is ="allow.dev_kmem_access" (you don't
need the "=1" part).

> Load any required kernel modules in the jail host - xorg in the jail
> will not be able to load them for you. Therefore, make sure to load
> i915kms, radeonkms or nvidia before hand.

Correct.

> Install and use xorg in the jail as you would normally.

Bye,
Alexander.

-- 
http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jail.diff
Type: application/octet-stream
Size: 2595 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20140309/9b2b53ec/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: devfs.rules
Type: application/octet-stream
Size: 2926 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20140309/9b2b53ec/attachment-0001.obj>