[rsbac] Problems with UM/RC

Rafal Bisingier ravbc at man.poznan.pl
Mon Jul 4 12:17:21 CEST 2005


On Fri, Jul 01, 2005 at 05:21:43PM +0200, Amon Ott wrote:
> On Freitag 01 Juli 2005 17:07, Rafal Bisingier wrote:
> > I feel a little oddly, but I think I found one more bug in UM code 
> > of RSBAC. Here's the problem:
> > I've got a RC role with def_user_create_type set to 3 (I've added 
> > this type to default RSBAC config), but sometimes when a process
> > with this role try to create user it create a user with rc_type 0!
> > That's not the end of the problem - when I change rc_type of this 
> > user to anything else (eg. 1 - Security User), then I delete this
> > user (from the secoff account), and once again I create user with
> > the same UID by the original process (with def_user_create_type
> > = 3), then the newly created user will get rc_type set to this UID
> > before deletion.
> > But that's still not the worst of it. This recreated user will get 
> > also the same RC role (!) as user with this UID before it was
> > deleted.
> 
> You are correct - default_user_create_type does not yet work. The 
> notification call is missing from the UM syscalls, so the attribute 
> is kept at the value used before.

I think that for Linux UM the attributes can be kept at the value used
before, but for RSBAC exclusive UM this had to be enforced.

> I am not sure how to handle this anyway, because the user type might 
> have been already set for a Linux UM user. If you create a user via 
> RSBAC UM, it sounds logical to use this flag. Maybe it should default 
> to 'do-not-touch', or we make it optional in RC options. Or optional 
> in useradd/userdel.

I'm not sure if I understand you correctly, but as I said if it's
problematic to enforce def_user_create_type for Linux UM, then it can
be left out (so do-not-touch should be a good default), or simply reset
to default (eg. General User). However for RSBAC exlusive UM this
should work (there's no other possibility to create user than by RSBAC
syscalls, so it should be quite simple).

An option in rsbac_useradd to explicitly declare RC type/def_role of
new user would be also very nice. Another feature of this kind would
be rc_def_role for specified user rc_type, but this can be harder to
do.

-- 
Rafal Bisingier
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rsbac.dyndns.org/pipermail/rsbac/attachments/20050704/ba897208/attachment.bin


More information about the rsbac mailing list