From owner-freebsd-current Tue Jul 7 00:08:58 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA11986 for freebsd-current-outgoing; Tue, 7 Jul 1998 00:08:58 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp04.primenet.com (daemon@smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA11962 for ; Tue, 7 Jul 1998 00:08:51 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id AAA21966; Tue, 7 Jul 1998 00:08:49 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp04.primenet.com, id smtpd021954; Tue Jul 7 00:08:49 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id AAA03942; Tue, 7 Jul 1998 00:08:43 -0700 (MST) From: Terry Lambert Message-Id: <199807070708.AAA03942@usr06.primenet.com> Subject: Re: xf86OpenConsole: KDENABIO failed (Operation not permitted) To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Tue, 7 Jul 1998 07:08:43 +0000 (GMT) Cc: joelh@gnu.org, smoergrd@oslo.geco-prakla.slb.com, tarkhil@asteroid.svib.ru, current@FreeBSD.ORG In-Reply-To: <26015.899757973@time.cdrom.com> from "Jordan K. Hubbard" at Jul 6, 98 01:46:13 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Most things that are disallowed under securelevel 1 are things that > > aren't frequently done except during rc, a system install, or an > > attack. But running X is a normal operation. I'd classify it as a > > bug myself. > > Actually, running X is not a "normal" operation at all - it performs > inb/outb instructions and does various privileged bits of syscons > frobbing that could be potentially quite hazardous in the hands of the > deliberately malicious. Running an X server should be a conscious > compromise of certain types of security. You wouldn't classify this as an architectural design bug in the granularity of FreeBSD's control over the I/O address space? Or in FreeBSD's console driver code leaving the X server no choice to obtain access to the display in bitmap mode? Admittedly, requiring user accessiblity to I/O space to get hardware to do something is wrong, but the requirement is because of FreeBSD not abstracting that access via a user<->kernel interface, not an inherent problem with the hardware. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message