From owner-freebsd-security Sat Oct 16 22:28:25 1999 Delivered-To: freebsd-security@freebsd.org Received: from fever.semiotek.com (H253.C225.tor.velocet.net [216.126.82.253]) by hub.freebsd.org (Postfix) with ESMTP id B37141506F for ; Sat, 16 Oct 1999 22:28:15 -0700 (PDT) (envelope-from jread@fever.semiotek.com) Received: (from jread@localhost) by fever.semiotek.com (8.9.3/8.9.3) id BAA00864; Sun, 17 Oct 1999 01:27:50 -0400 (EDT) (envelope-from jread) Date: Sun, 17 Oct 1999 01:27:50 -0400 From: Justin Wells To: Antoine Beaupre Cc: Mike Nowlin , "Rashid N. Achilov" , freebsd-security@FreeBSD.ORG Subject: Re: kern.securelevel and X Message-ID: <19991017012750.A812@fever.semiotek.com> References: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Oct 15, 1999 at 12:53:39PM -0400, Antoine Beaupre wrote: > I guess there is no way to run X in secure level > 0, right? I'm now running X on my workstation at securelevel 3. I uncommented this in my /etc/ttys (I used to run startx manually): ttyv0 "/usr/X11R6/bin/xdm -nodaemon" xterm on secure and added this as the last thing in my rc.local: #secure operation if [ -f /etc/secure-level ]; then ( sleep 10 && sysctl -w kern.securelevel=`cat /etc/secure-level` ) & fi The purpose of the 10 second sleep is to give xdm time to initialize the display and get itself running. It works. You can exit your X session and log in as someone else and xdm is happy--it already has the access it needs I guess. However there's a downside: I have a bunch of chrooted daemons that get initialized before this. I feel they should be initialized AFTER the securelevel is set, since I view them as untrusted. However, then I would have to run xdm well before the system gets to multi user mode.... sigh. Ideally I should set my firewall rules right after the disks get mounted, and then impose the securelevel at that point--letting all of the userland initialization, daemons, etc., happen under the securelevel restriction--leaving open the smallest possible window for an attacker. The problem with securelevel, in my mind, is that an attacker who got root would simply write stuff into the /etc/rc scripts and then force the machine to reboot. It would be very difficult to set the schg flag on every possible file that gets run as root during bootup. Does anyone have any clever solutions? Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message