Date: Sun, 16 Mar 2014 20:16:25 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= <uqs@FreeBSD.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: Tom Evans <tevans.uk@googlemail.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, "freebsd-x11@freebsd.org" <freebsd-x11@freebsd.org>, jamie@freebsd.org Subject: Re: [PATCH] Xorg in a jail Message-ID: <20140316191625.GG36583@acme.spoerlein.net> In-Reply-To: <20140309190802.00006452@unknown> References: <CAFHbX1JUzM%2BN9Zx=eCQdejvz1jAWcXNHepB2=5ZRuunu1gAG6g@mail.gmail.com> <20140309190802.00006452@unknown>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2014-03-09 at 19:08:02 +0100, Alexander Leidinger wrote:
> On Sun, 9 Mar 2014 01:26:40 +0000
> Tom Evans <tevans.uk@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.
Alexander,
there's a typo in the devfs rules for xorg:
add path 'dri*' unhide
needs to be
add path 'dri/card*' unhide
to actually make /dev/dri/card0 show up in my xbmc jail.
Xorg still fails to come up with this patch, as opening the dri/drm
stuff eventually fails:
[ 12890.548] (II) Loading /usr/local/lib/xorg/modules/drivers/intel_drv.so
[ 12890.549] (II) Module intel: vendor="X.Org Foundation"
[ 12890.549] compiled for 1.12.4, module version = 2.21.15
[ 12890.549] Module class: X.Org Video Driver
[ 12890.549] ABI class: X.Org Video Driver, version 12.1
[ 12890.549] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets:
i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G,
915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33,
GM45, 4 Series, G45/G43, Q45/Q43, G41, B43, HD Graphics,
HD Graphics 2000, HD Graphics 3000, HD Graphics 2500,
HD Graphics 4000, HD Graphics P4000, HD Graphics 4600,
HD Graphics 5000, HD Graphics P4600/P4700, Iris(TM) Graphics 5100,
HD Graphics 4400, HD Graphics 4200, Iris(TM) Pro Graphics 5200
[ 12890.551] (--) Using syscons driver with X support (version 2.0)
[ 12890.551] (--) using VT number 5
[ 12890.551] drmOpenDevice: node name is /dev/dri/card0
[ 12890.551] drmOpenDevice: open result is 9, (OK)
[ 12890.552] drmOpenByBusid: Searching for BusID pci:0000:00:02.0
[ 12890.552] drmOpenDevice: node name is /dev/dri/card0
[ 12890.552] drmOpenDevice: open result is 9, (OK)
[ 12890.552] drmOpenByBusid: drmOpenMinor returns 9
[ 12890.552] drmOpenByBusid: Interface 1.4 failed, trying 1.1
[ 12890.552] drmOpenByBusid: drmGetBusid reports
(repeat till card15, but they all report no such file or directory,
naturally)
[ 12890.558] (EE) No devices detected.
The host has these lines for a working Xorg boot:
[ 1738.086] drmOpenDevice: node name is /dev/dri/card0
[ 1738.086] drmOpenDevice: open result is 10, (OK)
[ 1738.086] drmOpenByBusid: Searching for BusID pci:0000:00:02.0
[ 1738.086] drmOpenDevice: node name is /dev/dri/card0
[ 1738.086] drmOpenDevice: open result is 10, (OK)
[ 1738.086] drmOpenByBusid: drmOpenMinor returns 10
[ 1738.086] drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
[ 1738.086] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[ 1738.086] drmOpenDevice: node name is /dev/dri/card0
[ 1738.086] drmOpenDevice: open result is 10, (OK)
[ 1738.087] drmOpenByBusid: Searching for BusID pci:0000:00:02.0
[ 1738.087] drmOpenDevice: node name is /dev/dri/card0
[ 1738.087] drmOpenDevice: open result is 10, (OK)
[ 1738.087] drmOpenByBusid: drmOpenMinor returns 10
[ 1738.087] drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
[ 1738.087] (**) intel(0): Depth 24, (--) framebuffer bpp 32
[ 1738.087] (==) intel(0): RGB weight 888
If it is returning an FD 9, why the hell does it fail then? I'm using
WITH_NEW_XORG and want all that KMS stuff to work for the latest Intel
drivers, so I can get accelerated HD video playback.
Any thoughts?
Uli
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140316191625.GG36583>