X & securelevel=3

bofn bofn at irq.org
Tue Jun 1 14:27:19 PDT 2004






 On 01 Jun 2004 12:03:01 -0400
Lowell Gilbert <freebsd-security-local at be-well.ilk.org> wrote
> "bofn" <bofn at irq.org> writes:
> 
> > running (4-Stable)
> > 
> > Hi,
> > 
> > short form question:
> >  how does one run XDM under securelevel>0 ?
> > 
> > long version:
> > i've searched for an answer on how to run Xfree/Xorg at a securelevel
> > the X server likes access to /dev/io and some other resources but is not
> > granted access after security is switched on.
> > one way of doing it seems to be to start it before setting the securelevel,
> but
> > then is doesnt allow a restart of X.
> > the other option seems to be the Aperture patch, ported in 2001 with no
> recent
> > updates and no longer usable against the current software.
> 
> You understand the situation just fine.  The real question is what you
> hope securelevels will do for you if you are allowing a userland
> process to access arbitrary memory, as X does.  
the idea is to limit the options for possible intruders and users who like to
play to much.
but at the same time provide a GUI work place for the users.


> > 2nd part of the question..
> > cd writing needs direct access to /dev/<acd0c> and that is also not allowed
> in
> > secure more.
> > how can one give selective access to only allow (RW) access to one or two
> > devices ?
> 
> You can't.
> 
> > if there is no way of doing these things with configs and such, can anyone
> > point me at the relevant source code that controls these functions so i can
> add
> > this specific functionality. 
> 
> That would probably be the platform-dependent mem.c and sys_machdep.c
> files; I think you may need to worry about the spigot and vnops
> opens as well (and probably ioctls).  I don't think it's worth
> worrying about, though; it would be very hard to make it bulletproof,
> and for fairly little gain.  

> Securelevels are a very narrowly focused tool; they are not intended
> to be a magic bullet for security.

i'm not looking for the 'fix all problems' solution, just a way to lock down
the system a bit more with out losing functionality for the users.

is there a better way to get this done, with out turning it into a sysadmin
nightmare like ACL's tend to  ?


//j


More information about the freebsd-security mailing list