[rsbac] Role for initrd(linuxrc) and oops in logs

Amon Ott ao at rsbac.org
Thu Jul 22 17:19:21 CEST 2004


On Donnerstag, 22. Juli 2004 16:52, Rob See wrote:
> On Jul 22, 2004, at 10:36 AM, Amon Ott wrote:
> >>>
> >> Really once the rsbac_init happens,  linuxrc just needs to be able to
> >> umount a couple of things (/proc is one of them), so that the normal
> >> init scripts can mount it in the right place. I don't believe that I
> >> can call other scripts (I'm using nash, the redhat initrd shell, also 
> >> I
> >> don't want to have to switch to secoff to create the initrd) Before 
> >> the
> >> boot role support was added, what role would this script have run in ?
> >
> > It must have been root's role (usuall 2) or 0. I cannot tell for sure.
> 
> Do you have any other suggestions for a fix for this?

A quick and dirty workaround is to start in softmode and switch it off 
right after the umount stuff.

You can try to set a different rc_type_fd on your final root dir. Then you 
can grant role 0 to umount FD type 0, because type 0 is only available in 
the initrd. Once that has been umounted, all type 0 FD objects are gone 
from normal filesystem, so the right does not harm you.

Just be careful to avoid dirty multimount tricks on a filesystem, which 
break the inheritance, if you have no explicit type set on the root dir of 
that filesystem. If inheritance is broken, the default type value at the 
mount point and below is 0. This might also hit you with some kernel 
special filesystems like socketfs or pipefs, but umount has little meaning 
there.

Argggh, initrd hits again. It might be useful in some cases, but it loves 
to create trouble. :(

I will try to come up with a general solution, which does not open any 
security holes.

Amon.
-- 
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
-------------- nächster Teil --------------
Ein Dateianhang mit Bin?rdaten wurde geschreddert...
Dateiname   : nicht verf?gbar
Dateityp    : application/pgp-signature
Dateigr??e  : 189 bytes
Beschreibung: signature
URL         : http://www.rsbac.org/pipermail/rsbac/attachments/20040722/bf0fe611/attachment.bin


More information about the rsbac mailing list