[rsbac] RSBAC: Inconsistencies, confusion galore...

Amon Ott rsbac@rsbac.org
Fri Jan 3 13:36:00 2003


On Friday 03 January 2003 08:35, Michael Chang wrote:
> When I use attr_set_fd to tell rsbac to log all EXECUTE 
> requests for /sbin/ifconfig, it appears as though all of the 
> log_program_based bits are cleared.
> 
> [secoff@polaris rsbac]$ attr_set_fd -v GEN FILE log_program_based EXECUTE 
> /sbin/ifconfig
> attr_set_fd: 1 targets
> Processing FILE '/sbin/ifconfig', attribute log_program_based, value 0

Please use attr_set_file_dir with -a parameter to add requests for logging. 
attr_set_fd can only work with decimal values.

These two tools must be integrated some day, but there are problems with 
arguments to be solved.
 
> [secoff@polaris rsbac]$ attr_get_fd -v GEN FILE log_program_based 
> /sbin/ifconfig
> attr_get_fd: 1 targets
> Processing FILE '/sbin/ifconfig', attribute log_program_based
> /sbin/ifconfig: Returned value: 00000000000000000000000000000000000000000000

Well, the decimal value of 'EXECUTE' is 0... :(

> Now, when I run /sbin/ifconfig, nothing gets logged (nothing in the kernel 
> logs, and nothing in /proc/rsbac-info/rmsg).  I know that logging does 
> work, since it get request notifications for other actions.

Yes, nothing has been set. I recommend rsbac_fd_menu for such configurations, 
because the menues make life a lot easier in most cases.
 
> Am I using the wrong utility?  Based upon the behaviour of attr_set_fd, it 
> appears as though it *is* the correct utility.  Which leads me to another 
> question: What is the difference between FILE and FD?  In my 
> understanding, FD (or 'fd') is lingo for 'file descriptor', and file 
> descriptors only apply to "files" which are currently open in a process.
> However, the rsbac utilities imply, in their usage output, that FD is a 
> shortcut which can be applied against both files and directories (but not 
> device files).  There appears to be a discrepancy, then, since there is an 
> attr_set_file_dir utility --- this implies that an FD is *not* the same as 
> a FILE or DIR, otherwise three separate utilities wold not exist.  
> Therefore, the only logical conclusion that I can come up 
> with is that FD can only be used against files which have been opened (by 
> open(), etc.) by a currently running process.  If I'm wrong, please let 
> me know.  I'm confused up to my ears.

The three utilities are there for historical reasons. FD is really a 
shortcut, which means 'automatically detect the correct type out of FILE, 
DIR, FIFO, SYMLINK'. This is done in the system call itself. The tool names 
come from the early time when there were only FILE and DIR filesystem targets.

Device special files as filesystem objects are FILE targets, the device 
pointed to (major:minor:type) is a DEV target.

BTW, RSBAC administration does not care whether files are open or closed. If 
you make changes, the new values will be used at the next request and that is 
it.

> The same logic that I used above is also applicable to the 3 utilities,
> 'attr_set_up', 'attr_set_user', and 'attr_set_process'.  If attr_set_up 
> can be applied to both processes and users, then why do there exist 
> separate utilities for changing the attributes for processes and users?
> Again, I'm confused up to my ears.

Again, the division comes from historical reasons. For the menu scripts I had 
to make tools which were better to use for scripting, while the existing _up 
(like _fd) was mostly for command line use.

> Another question: What is the relationship between AUTH and CAPABILITIES 
> in the context of the RSBAC implementation?

The AUTH model defines setuid capabilities, which allow to CHANGE_OWNER to a 
user ID specified in such a capability. Since this right is given directly to 
the subject, regardless of an object, it has been called capability.

The Linux CAPabilites module allows to set or unset the Linux capabilites, 
which are completely different.

> More questions: What is the difference between the acl_rights and 
> acl_tlist utilities?

acl_rights lists the effective rights of a subject to an object.

acl_tlist lists all ACL entries at an object. ACL entries and masks (see 
acl_mask) at an object and possibly at all parent objects are used 
to determine a subject's rights to this object.

> When setting rights for a target of type PROCESS, 
> are those rights only retained for the lifetime of a process, or do the 

There are no rights to individual processes in ACL model, only the global 
rights defined in the :DEFAULT: ACL. If there were, they would of course be 
deleted when the process issues a TERMINATE request on exit.

The RC model allows to specify such rights based on the process RC 
type.

> rights apply indefinitely for each and every subsequent invocation of an 
> executable which produces the same process image?  When I remove the 
> DELETE attribute for an executable, does it mean that the executable 
> itself can no longer be deleted, or does it mean that the executable 
> cannot call unlink()?  Have I mentioned, yet, that I'm confused up to my 
> ears?  :)

What DELETE attribute? I assume you are talking about access rights here.

If you remove DELETE from the executable's inheritance mask, noone can 
inherit the DELETE right from parent objects (e.g. the :DEFAULT:) any more, 
so it cannot be deleted - unless you explicitely grant a DELETE right to this 
object for some subject in an ACL entry at the object.

In ACL model, rights to processes are not inherited from the executable in 
any form.

> I hope someone has the time to reply with some answers.  I'm unable to 
> find any man pages for the utilities, so some guidance would be 
> appreciated.

The existing papers, the models.htm file and the kernel config help for the 
modules are all that has been written for public use so far.

If you are specially interested in the ACL model, I recommend a closer look 
into a good Novell NetWare documentation...

Amon.
--
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22