R: [rsbac] secure module handling

Tue Sep 10 16:31:01 2002

I feel embarassed.....
Your hint of many different FDs shed new light. All file/dir issues have =
been
resolved. And I learned a good lesson.
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 9=
4
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 1=
01
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.
Again, have you, or other list readers, observed this? Have you a solutio=
n?
At the moment I have no more....
Thanks

Alberto Guglielmo

-----Messaggio originale-----
Da: rsbac-admin@rsbac.org [mailto:rsbac-admin@rsbac.org] Per conto di
ghorvath@minolta.hu
Inviato: martedi 10 settembre 2002 8.57
A: rsbac@rsbac.org
Oggetto: [rsbac] V=E1lasz: R: [rsbac] secure module handling

See my previous letter in this topic. As Amon wrote you can write a small
script which restores /proc's attributes after reboot. By the way I am us=
ing
a different solution: I assigned different FDs to all sub dirs of root as
Home_FD, LIB_FD, and so on, and Proc_FD (You can rename General FD to thi=
s
type) is assigned to /. Due to this /proc is the only dir which inherits =
that
attribute and /proc will always have the necessary attributes even after
reboots.

I hope this helps.

Bye,
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

                  C=EDmzett:         <rsbac@rsbac.org>
                  M=E1solat:
                     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 1.2.1pr=
e6
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 th=
em,
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 =
many
other accesses: target_type FILE: /etc/modules.conf, /proc/meminfo /etc/m=
tab
(by depmod); target_type FIFO .....
The problem is that the properties of /proc "vanish" after a reboot, in s=
pite
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_admin 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_type_fd modules
- assigned all binaries and libraries to rc_type_fd sysfiles
- all roles have read_only to sysfiles and modules
- created role module_admin
- assigned rc_force_role of /sbin/insmod to role module_admin
- removed add_to_kernel and remove_from_kernel
 from all roles except module_admin
- removed all permissions to General_FD from
 role module_admin

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_admin 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.
**********************************************************************

_______________________________________________
rsbac mailing list
rsbac@rsbac.org
http://www.rsbac.org/mailman/listinfo/rsbac

_______________________________________________
rsbac mailing list
rsbac@rsbac.org
http://www.rsbac.org/mailman/listinfo/rsbac