[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