Date: Wed, 10 Jan 2001 01:23:53 +0100 From: Thomas Moestl <tmoestl@gmx.net> To: freebsd-security@freebsd.org Subject: Re: Running X in securelevels > 0 ? Message-ID: <20010110012353.A2635@crow.dom2ip.de> In-Reply-To: <Pine.NEB.3.96L.1010109085059.63837A-100000@fledge.watson.org>; from rwatson@freebsd.org on Tue, Jan 09, 2001 at 08:57:15AM -0500 References: <20010109094651.A24037@dogma.freebsd-uk.eu.org> <Pine.NEB.3.96L.1010109085059.63837A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 09, 2001 at 08:57:15AM -0500, Robert Watson wrote: > > On Tue, 9 Jan 2001, Rasputin wrote: > > > But I was talking to an OpenBSD user over the weekend who said that 2.7 > > somehow manages to reserve access to certsain devices by running some > > kind of wrapper before the securelevel is used (although that may be > > bull). > > 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. From what I can tell after a quick look, it allows access to the physical memory between adresseses 0xa0000 and 0xffffff, or optional access to the whole first MB of memory to one process at a time (modulo shared descriptors). Additionally, it allows access to all io ports via the OpenBSD i386_iopl sys call (to the super user). The whole aperture behaviour is tunable via a sysctl knob and defaults to off. However, this seems to be a little too permissive if aperture is enabled; sure somebody can mess badly with the system with aperture enabled. Still, it seems much more difficult than with lowered secure level to e.g. alternate the kernel image, but it should be more than enough to make the machine crash with loss of data or even worse damages. > 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 will take a deeper look into the OpenBSD implementation and will try to port it. We could attempt to be less permissive (particularly regarding io port access), but I think we will end up with a permitted set that is bigger than we might like it to support all hardware that's out there. One thing that might be worthwile is to get the resources of pci vga adaptors to build the set from that. - 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?20010110012353.A2635>