Date: Sat, 13 Jan 2001 01:46:42 +0100 From: Thomas Moestl <tmoestl@gmx.net> To: freebsd-security@freebsd.org Subject: Re: Running X in securelevels > 0 ? Message-ID: <20010113014642.A2463@crow.dom2ip.de> In-Reply-To: <20010110012353.A2635@crow.dom2ip.de>; from tmoestl@gmx.net on Wed, Jan 10, 2001 at 01:23:53AM %2B0100 References: <20010109094651.A24037@dogma.freebsd-uk.eu.org> <Pine.NEB.3.96L.1010109085059.63837A-100000@fledge.watson.org> <20010110012353.A2635@crow.dom2ip.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 10, 2001 at 01:23:53AM +0100, Thomas Moestl wrote: > On Tue, Jan 09, 2001 at 08:57:15AM -0500, Robert Watson wrote: > > OpenBSD has an "apperture" driver that presumably works by making a > > specific subset of hardware controls available in higher securelevels, > > carefully selected so that the subset is sufficient for the purposes of > > graphics in X, but not sufficient to violate kernel protections. > > Unfortunately, I've not had the opportunity to look more closely than that > > at this point. I now have a working prototype. I keep a list with memory and io port ranges in the kernel that can be changed via syscontrols (at securelevels <= 0). The administrator can specify the ranges, or there could be a userland tool to walk the PCI device information, tries to find a graphics card and prints the mem and io ranges accordingly so that that info can be used. > > If you're interested in looking at porting it, I think > > there would be interest in integrating it into the base FreeBSD source > > tree: while the OpenBSD project uses it specifically to address concerns > > with securelevels, it would also be useful in other mandatory access > > control environmnents, or environments where the privilege model is not > > the root-trumps-all model. When porting it, it would be useful to do an > > analysis of how effective the driver is at providing only the necessary > > subset, and that it doesn't allow access to video subsystem functions that > > might be manipulable to gain privilege, or violate other system policies. > > Having X functionality without the ability to directly manipulate all > > hardware would be very desirable. I think the current model should be extensible in a reasonable way. However, there is one issue that I would like to hear comments on. X uses /dev/io to enable io access on FreeBSD, while it uses the i386_iopl call on OpenBSD. This has the drawback that it enables all io access at once. Basically, it would be best to change all applications out there to use the i386_set_ioperm calls (and I have intergrated the necessary aperture checks into these calls). However, changing only the X server seems to be very complex, one would probably have to wade through any driver and maintain a very large patch set. A klugy workaround would be to change /dev/io to use io permission bitmaps with the ranges specified before instead of the iopl bit. This would give us the the desired features, but the (grave, I think) drawback is that the unaware application has no way to know that it has exceeded it's privileges, it would just catch a signal and probably die a painful death. On the other hand, one could argument that aware applications use the i386_set_ioperm system call and are happy ;-) Comments please? - thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010113014642.A2463>