From owner-freebsd-x11@FreeBSD.ORG Sun Mar 16 19:16:28 2014 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD0439A1; Sun, 16 Mar 2014 19:16:28 +0000 (UTC) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5CFE2A62; Sun, 16 Mar 2014 19:16:28 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.7/8.14.7) with ESMTP id s2GJGPjU072189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Mar 2014 20:16:26 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Sun, 16 Mar 2014 20:16:25 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Alexander Leidinger Subject: Re: [PATCH] Xorg in a jail Message-ID: <20140316191625.GG36583@acme.spoerlein.net> Mail-Followup-To: Alexander Leidinger , Tom Evans , "freebsd-x11@freebsd.org" , "freebsd-hackers@freebsd.org" , jamie@freebsd.org References: <20140309190802.00006452@unknown> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140309190802.00006452@unknown> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Tom Evans , "freebsd-hackers@freebsd.org" , "freebsd-x11@freebsd.org" , jamie@freebsd.org X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 19:16:29 -0000 On Sun, 2014-03-09 at 19:08:02 +0100, Alexander Leidinger wrote: > On Sun, 9 Mar 2014 01:26:40 +0000 > Tom Evans 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/ 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