R: R: [rsbac] secure module handling

[Alberto Guglielmo]

Eureka!
Amon, your patch resolved the issue. Not I had any doubt....
The last error remaining during the boot, anyways successful, is:
Sep 12 13:31:36 dns1 kernel: rsbac_adf_request(): request READ_OPEN, pid 116,
ppid 115, prog_name depmod, uid 0, target_type FILE, tid Device 03:03 Inode
244947 Path /etc/mtab, attr , value 0, result NOT_GRANTED by RC
This is not a blocking error: if depmod is unable to read /etc/mtab he tries
to read /etc/fstab, so adjusting the rights (RC type) for this file was all
that had to be done.
I flagged (FF module) /etc/ld.so.cache and /etc/fstab as readonly because I'm
paranoid. I want every file readable by insmod/modprobe to be readonly.....
Anyway flagging /etc/ld.so.cache "no_delete_or_rename", as suggested by you,
worked fine.
Again many thanks to you all.

Alberto Guglielmo
a.guglielmo<at>tcpsas.com
Key Fingerprint:7EAF 9E34 2838 7C6B EE47  E8F0 FFC5 3CBC 90AA 5EEE
PGP Keys at:
ldap://europe.keys.pgp.com:11370
http://pgpkeys.mit.edu:11371



-----Messaggio originale-----
Da: rsbac-admin@rsbac.org [mailto:rsbac-admin@rsbac.org]Per conto di Amon Ott
Inviato: martedi 10 settembre 2002 17.29
A: rsbac@rsbac.org
Oggetto: Re: R: [rsbac] secure module handling


On Tuesday, 10. September 2002 16:23, Alberto Guglielmo wrote:
> But something weird remains. Excuse me if the mailer wraps, but I want to
> insert a couple of lines from the log, obtained in "soft mode", when the
> machine loads the ethernet modules:
>
> Sep 10 12:20:58 dns1 kernel: rsbac_adf_request(): request WRITE, pid 74,
ppid
> 73, prog_name modprobe, uid 0, target_type FIFO, tid Device 00:05 Inode 94
> Path pipe:/[94], attr , value 0, result NOT_GRANTED by RC
> Sep 10 12:20:58 dns1 kernel: rsbac_adf_request(): request WRITE, pid 81,
ppid
> 80, prog_name modprobe, uid 0, target_type FIFO, tid Device 00:05 Inode 101
> Path pipe:/[101], attr , value 0, result NOT_GRANTED by RC
>
> If I modprobe or insmod manually (I tried with the parallel port modules) I
> cannot reproduce the behaviour, all goes fine.

This looks like an unnamed pipe, which somehow did not get its device set to
0. After rechecking the code, I found that 2.4 kernels no longer initialize
the device of new pipe inodes to 0, but to the device of the pipefs
superblock. Instead, unnamed pipes get a special PIPEFS_MAGIC.

The attached patch against fs/read_write.c of 2.4.19 should fix your problem.
Please test it and tell me what happened!

Amon.
--
http://www.rsbac.org