[rsbac] Válasz: R: [rsbac] secure module handling
rsbac@rsbac.org
rsbac@rsbac.org
Tue Sep 10 09:01:02 2002
This is a multipart message in MIME format.
--=_alternative 00263169C1256C30_=
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
See my previous letter in this topic. As Amon wrote you can write a small=20
script which restores /proc's attributes after reboot. By the way I am=20
using a different solution: I assigned different FDs to all sub dirs of=20
root as Home=5FFD, LIB=5FFD, and so on, and Proc=5FFD (You can rename Gener=
al FD=20
to this type) is assigned to /. Due to this /proc is the only dir which=20
inherits that attribute and /proc will always have the necessary=20
attributes even after reboots.
I hope this helps.
Bye,=20
Gabor Horvath
ghorvath@minolta.hu
"Alberto Guglielmo" <a.guglielmo@tcpsas.com>
Felad=F3: rsbac-admin@rsbac.org
2002.09.09 17:10
K=E9rem, v=E1laszoljon ennek a szem=E9lynek: rsbac
=20
C=EDmzett: <rsbac@rsbac.org>
M=E1solat:=20
T=E1rgy: R: [rsbac] secure module handling
I lost myself!
I'm using a RH7.3 Linux distribution with a 2.4.19 kernel + RSBAC=20
1.2.1pre6
I tried to reproduce the configuration, but the behaviour is a little
different: I notice the accesses to /etc/ld.so.cache and don't care of=20
them,
but I notice also accesses to /proc/sys/kernel/tainted from modprobe
(insmod), and I have to allow them to make modprobe work. There are also=20
many
other accesses: target=5Ftype FILE: /etc/modules.conf, /proc/meminfo=20
/etc/mtab
(by depmod); target=5Ftype FIFO .....
The problem is that the properties of /proc "vanish" after a reboot, in=20
spite
of the fact that the inode is always the same (#1 curious...) I think the
cause is: /proc is not a true "filesystem" and you cannot have a
/proc/rsbac.dat directory.
Anyway... I'm unable to figure how to escape from this trap. If the role
module=5Fadmin has read permissions out of /lib/modules you can insmod
anything.
Am I wrong? Any suggestion/clue/laugh?
Alberto Guglielmo
-----Messaggio originale-----
Da: rsbac-admin@rsbac.org [mailto:rsbac-admin@rsbac.org]Per conto di
Andreas Baetz
Inviato: mercoledi 4 settembre 2002 11.14
A: rsbac@rsbac.org
Oggetto: [rsbac] secure module handling
Hi,
to make sure that only trusted kernel modules are loaded,
I did the following (using RC and version 1.1.2):
- assigned /lib/modules to rc=5Ftype=5Ffd modules
- assigned all binaries and libraries to rc=5Ftype=5Ffd sysfiles
- all roles have read=5Fonly to sysfiles and modules
- created role module=5Fadmin
- assigned rc=5Fforce=5Frole of /sbin/insmod to role module=5Fadmin
- removed add=5Fto=5Fkernel and remove=5Ffrom=5Fkernel
from all roles except module=5Fadmin
- removed all permissions to General=5FFD from
role module=5Fadmin
Now insmod can only load modules from /lib/modules and
nobody can write there. The system works, but everytime
modprobe, lsmod, rmmod or insmod are called, they try
to access /etc/ld.co.cache. This is not granted. The modules
get loaded and unloaded, though. Now I granted the role
module=5Fadmin read to this file, but the inode changes every time
ldconfig is run. But I don't want to grant read to /etc fo that role,
because then root could create some module there and load it.
What do you think about my solution ? Any comments ?
Andreas Baetz
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been scanned
for the presence of computer viruses.
**********************************************************************
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
rsbac mailing list
rsbac@rsbac.org
http://www.rsbac.org/mailman/listinfo/rsbac
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
rsbac mailing list
rsbac@rsbac.org
http://www.rsbac.org/mailman/listinfo/rsbac
--=_alternative 00263169C1256C30_=
Content-Type: text/html; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
<br><font size=3D2 face=3D"sans-serif">See my previous letter in this topic=
. As Amon wrote you can write a small script which restores /proc's attribu=
tes after reboot. By the way I am using a different solution: I assigned di=
fferent FDs to all sub dirs of root as Home=5FFD, LIB=5FFD, and so on, and =
Proc=5FFD (You can rename General FD to this type) is assigned to /. Due to=
this /proc is the only dir which inherits that attribute and /proc will al=
ways have the necessary attributes even after reboots.</font>
<br>
<br><font size=3D2 face=3D"sans-serif">I hope this helps.</font>
<br>
<br><font size=3D2 face=3D"sans-serif">Bye, </font>
<br><font size=3D2 face=3D"sans-serif">Gabor Horvath</font>
<br><font size=3D2 face=3D"sans-serif">ghorvath@minolta.hu</font>
<br>
<br>
<br>
<br>
<table width=3D100%>
<tr valign=3Dtop>
<td>
<td><font size=3D1 face=3D"sans-serif"><b>"Alberto Guglielmo" <=
;a.guglielmo@tcpsas.com></b></font>
<br><font size=3D1 face=3D"sans-serif">Felad=F3: rsbac-admin@rsbac.org</fon=
t>
<p><font size=3D1 face=3D"sans-serif">2002.09.09 17:10</font>
<br><font size=3D1 face=3D"sans-serif">K=E9rem, v=E1laszoljon ennek a szem=
=E9lynek: rsbac</font>
<br>
<td><font size=3D1 face=3D"Arial"> </font>
<br><font size=3D1 face=3D"sans-serif"> &=
nbsp; C=EDmzett: <rsbac=
@rsbac.org></font>
<br><font size=3D1 face=3D"sans-serif"> &=
nbsp; M=E1solat: </font>
<br><font size=3D1 face=3D"sans-serif"> &=
nbsp; T=E1rgy:  =
; R: [rsbac] secure module handling</font></table>
<br>
<br>
<br><font size=3D2 face=3D"Courier New">I lost myself!<br>
I'm using a RH7.3 Linux distribution with a 2.4.19 kernel + RSBAC 1.2.1pre6=
<br>
I tried to reproduce the configuration, but the behaviour is a little<br>
different: I notice the accesses to /etc/ld.so.cache and don't care of them=
,<br>
but I notice also accesses to /proc/sys/kernel/tainted from modprobe<br>
(insmod), and I have to allow them to make modprobe work. There are also ma=
ny<br>
other accesses: target=5Ftype FILE: /etc/modules.conf, /proc/meminfo /etc/m=
tab<br>
(by depmod); target=5Ftype FIFO .....<br>
The problem is that the properties of /proc "vanish" after a rebo=
ot, in spite<br>
of the fact that the inode is always the same (#1 curious...) I think the<b=
r>
cause is: /proc is not a true "filesystem" and you cannot have a<=
br>
/proc/rsbac.dat directory.<br>
Anyway... I'm unable to figure how to escape from this trap. If the role<br>
module=5Fadmin has read permissions out of /lib/modules you can insmod<br>
anything.<br>
Am I wrong? Any suggestion/clue/laugh?<br>
<br>
Alberto Guglielmo<br>
<br>
<br>
-----Messaggio originale-----<br>
Da: rsbac-admin@rsbac.org [mailto:rsbac-admin@rsbac.org]Per conto di<br>
Andreas Baetz<br>
Inviato: mercoledi 4 settembre 2002 11.14<br>
A: rsbac@rsbac.org<br>
Oggetto: [rsbac] secure module handling<br>
<br>
<br>
Hi,<br>
<br>
to make sure that only trusted kernel modules are loaded,<br>
I did the following (using RC and version 1.1.2):<br>
- assigned /lib/modules to rc=5Ftype=5Ffd modules<br>
- assigned all binaries and libraries to rc=5Ftype=5Ffd sysfiles<br>
- all roles have read=5Fonly to sysfiles and modules<br>
- created role module=5Fadmin<br>
- assigned rc=5Fforce=5Frole of /sbin/insmod to role module=5Fadmin<br>
- removed add=5Fto=5Fkernel and remove=5Ffrom=5Fkernel<br>
from all roles except module=5Fadmin<br>
- removed all permissions to General=5FFD from<br>
role module=5Fadmin<br>
<br>
Now insmod can only load modules from /lib/modules and<br>
nobody can write there. The system works, but everytime<br>
modprobe, lsmod, rmmod or insmod are called, they try<br>
to access /etc/ld.co.cache. This is not granted. The modules<br>
get loaded and unloaded, though. Now I granted the role<br>
module=5Fadmin read to this file, but the inode changes every time<br>
ldconfig is run. But I don't want to grant read to /etc fo that role,<br>
because then root could create some module there and load it.<br>
<br>
What do you think about my solution ? Any comments ?<br>
<br>
Andreas Baetz<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
**********************************************************************<br>
This email and any files transmitted with it are confidential and<br>
intended solely for the use of the individual or entity to whom they<br>
are addressed. If you have received this email in error please notify<br>
the system manager.<br>
<br>
This footnote also confirms that this email message has been scanned<br>
for the presence of computer viruses.<br>
**********************************************************************<br>
<br>
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F<br>
rsbac mailing list<br>
rsbac@rsbac.org<br>
http://www.rsbac.org/mailman/listinfo/rsbac<br>
<br>
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F<br>
rsbac mailing list<br>
rsbac@rsbac.org<br>
http://www.rsbac.org/mailman/listinfo/rsbac<br>
</font>
<br>
<br>
--=_alternative 00263169C1256C30_=--