From owner-freebsd-hackers Fri Feb 9 14:50:28 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0294F37B684 for ; Fri, 9 Feb 2001 14:50:10 -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 f19Mnnh52521; Fri, 9 Feb 2001 17:49:49 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 9 Feb 2001 17:49:49 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: 207.100@tj2.demon.co.uk Cc: freebsd-hackers@freebsd.org Subject: Re: /etc/security: add md5 to suid change notification? In-Reply-To: <3A84689F.6625@tj2.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 9 Feb 2001 207.100@tj2.demon.co.uk wrote: > > the use of elevated security levels (which are necessary if > > those flags are to have any force) has side effects that make > > them useless on lots of systems (e.g., inability to run X). > > Inability to run X ? > > I'm running at level=3, and X is quite happy. *Starting* X is not > possible (AFAIK) at level=3. Good thing it's fairly stable :-) If X has open file descriptors for privileged devices for the purposes of direct memory access, the debugging interfaces (and possibly exploits in shared libraries) can be used to control the X server in such a way that securelevels can be disabled or circumvented. This is because the securelevel checks associated with devices are generally performed on the open() event; the same effect that allows X to keep working after the securelevel is raised allows an attacker to circumvent the protections. 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-hackers" in the body of the message