Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Oct 1999 01:27:50 -0400
From:      Justin Wells <jread@semiotek.com>
To:        Antoine Beaupre <beaupran@IRO.UMontreal.CA>
Cc:        Mike Nowlin <mike@argos.org>, "Rashid N. Achilov" <shelton@sentry.granch.ru>, freebsd-security@FreeBSD.ORG
Subject:   Re: kern.securelevel and X
Message-ID:  <19991017012750.A812@fever.semiotek.com>
In-Reply-To: <14343.23571.679909.243732@blm30.IRO.UMontreal.CA>
References:  <XFMail.991015111802.shelton@sentry.granch.ru> <Pine.LNX.4.05.9910150036170.5339-100000@jason.argos.org> <14343.23571.679909.243732@blm30.IRO.UMontreal.CA>

next in thread | previous in thread | raw e-mail | index | archive | help


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991017012750.A812>