From owner-freebsd-security Tue Jan 9 6: 0:20 2001 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 5875B37B400 for ; Tue, 9 Jan 2001 06:00:03 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f09DvF763918; Tue, 9 Jan 2001 08:57:15 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Tue, 9 Jan 2001 08:57:15 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Rasputin Cc: freebsd-security@freebsd.org Subject: Re: Running X in securelevels > 0 ? In-Reply-To: <20010109094651.A24037@dogma.freebsd-uk.eu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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. 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. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message