[rsbac] RC, ACL models questions
Amon Ott
ao at rsbac.org
Wed Apr 28 11:46:37 CEST 2004
On Mittwoch, 28. April 2004 12:03, sftf at yandex.ru wrote:
> Could you answer on several questions?
> 1. How to do with ACL, so that it is impossible to delete DIR, but
> FILEs and DIRs under it possible to delete ?
Remove DELETE from dir's mask and add a sufficient entry for group 0 to all
files and dirs below.
Simple solution: Set FF flag no_rename_or_delete on this dir.
> 2. How to do with RC, so that it is impossible to delete DIR, but
> FILEs and DIRs under it possible to delete, if this files/dirs MUST
inherit parent FD type ?
> (so parent DIR and all subDIRs and subFILEs all of one fd-type)
If they have the same type, there is no way to have different rights.
Same simple solution: Set FF flag no_rename_or_delete on this dir.
> 3. With RC model Default FD Create Type may set in ONE TYPE:
> - Inherit_from_process
> - Inherit_from_parent
> - No_create_allowed
> So can ONE USER with ONE ROLE within ONE process create two files
> with different fd-types in the SAME directory ?
>
> Of course without implicit setting type AFTER file creation.
> So files in process of creation MUST have different types.
No, not yet. A special rc_create system call with a new RC special right
SELECT is on my to-do list.
> For example: useradd, userdel from shadow suit.
> When you add or delete user useradd/userdel programm
> CREATE NEW /etc/passwd, /etc/shadow, so this files inherit their
fd-types from
> parent dir or process. But I want that /etc had their own type
(sys_etc),
> /etc/passwd - their own type (auth_userdb) and
> /etc/shadow - their own type(auth_shadowdb) ALWAYS.
I know this problem, and the whole passwd/shadow scheme sucks raw eggs. The
way it works is a bad design mistake, if you want to make it a bit more
secure. A stronger authentication system for RSBAC is on its way, but not
yet done.
Until then, the OWL project has created something better, I am not sure
about the tool name. Might be tcb.
Amon.
--
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22
More information about the rsbac
mailing list