Date: Tue, 01 Jun 2004 23:27:10 +0200 From: "bofn" <bofn@irq.org> To: Lowell Gilbert <freebsd-security-local@be-well.ilk.org> Cc: freebsd-security@freebsd.org Subject: Re: X & securelevel=3 Message-ID: <web-3715336@sqnork.irq.org> In-Reply-To: <44u0xvnu4q.fsf@be-well.ilk.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01 Jun 2004 12:03:01 -0400 Lowell Gilbert <freebsd-security-local@be-well.ilk.org> wrote > "bofn" <bofn@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?web-3715336>