[rsbac] dynamic created devices

[Amon Ott]

On Sonntag 27 März 2005 11:26, murf wrote:
> I have an example of problematic part of configuration in 
rsbac-1.2.4.
> 
> Problematic part is defining RC restriction on dynamic created 
> pseudo-terminals slaves under /dev/pts according Unix98 pty naming.
> (we get descriptors pairs after opening /dev/ptmx).

Agreed, this is a problem.
 
> Some subjects (daemons working with pseudo terminals e.g. sshd) 
would like to 
> READ_WRITE access to theese dynamic created devices (on target DEV 
not FD). 
> But they are created as 0 rc_type of target DEV.

Dynamic devices...
 
> Here it is. We cannot allow READ_WRITE to rc_type 0 of target DEV, 
because its 
> default type for all devices.
> 
> There are theese possibilities come to my mind:
> 
> 1) manage the subject (in following named s_cre), which theese 
devices create to create 
> it with special rc dev type. But Its not possible in rsbac (there is 
only default rc fd type creation). 
> If its possible there is also some other problems, like that s_cre 
is in most probability 
> run under root. So it would have to be default dev created type for 
user root role.
> (e.g. udevd process in userland for 2.6.11 kernels)

We could introduce a def_dev_create_type for roles. The user root does 
not matter, it is the current process role. I would have to look into 
this to see how exactly the new devices get created - the special 
file has no meaning in RSBAC, it is the type-major-minor combo.
 
> 2) change rc type of all devices to another type and next set policy 
to default created type
> more benevolent. But Its not possible, because of dynamic created 
devices 
> (today by udevd in most cases).

No solution.
 
> 3) use another policy module like ACL. So one module allow mentioned 
access (RC) 
> and another dissallow (ACL). Its not elegant. Its only workaround 
and its not usable for users
> who dont want to use another module just for theese states.

I cannot see how this is supposed to work better - ACL uses the same 
identification as RC.
 
> 4) we can define access on directory for target DEV (devices 
inherited this setting
> from the parent dir). Its is the most elegant, but its not 
implemented in RSBAC. 
> Feature request? Please comment this, if its possible.

As said above, device special files have no meaning for RSBAC, it is 
the type-major-minor combo that counts. So there is no parent to use.

However, we could set default attribute values for a complete major 
number. This should help a lot in this case. For RC I also like the 
idea of def_dev_create_type, it also fits well into the model.

The to-do list contains an item "Let process choose RC type of new 
item". We could use this and make the daemon choose, but I do not 
like that idea.

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