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

[Michael Chang]

On Fri, 3 Jan 2003, Amon Ott wrote:

> 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.
Ah.  Thanks.  This wasn't stated in the usage text.


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

Yeah, but I hate menu tools that don't let you see what's actually being
executed.  :)  Similarly, I like driving manual versus automatic.  Call me
nosy.



> > 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.
If I specify a device file, do I have to use the major:minor convention, or
can I use the convenient /dev entry?

When I do an `rsbac_check 1 1`, I see only major:minor references in my
log output.  Would it be trivial to add the necessary code to express the
targets as real paths?


> 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.
I see.  You're not altering file descriptors, per se; instead, you're using the
inodes themselves?


> > 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.
Do you foresee more compact integration of these tools in the future?


> > 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.
So if the subject is a user, then you're basically allowing that user to
call setuid().  Is this correct?


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


> > 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.
Okay.  So it lists the relationship, in terms of rights, between a subject (say,
a group) and an object (say, a file).  Now, these are ACL rights.  How does
an ACL right for an ACL group interact with the rights/privileges/etc. set by
other modules?


> 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.
Okay.  A single ACL entry, if I understand correctly, is synonymous
with a right --- the relationship between a subject and an object as expressed
in terms of privileges (EXECUTE, DELETE, READ, etc.).  Yes?



> > 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.
Understood.  That makes sense.


> The RC model allows to specify such rights based on the process RC 
> type.
So a process inherits role rights from the caller?
(user joe has the role with the label "foo".  Therefore, the user's shell
also has the same role.  Consequently, the role is passed to the process
across an exec().  Now, the process has the role rights of "foo".  Am I
understanding this correctly?)


> > 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.
I suppose so.  I've seen it in various places, but its name has been spread
across so many contexts thus far that I can't yet make a clear mental association
with it.


> If you remove DELETE from the executable's inheritance mask, noone can 
> inherit the DELETE right from parent objects
What parent objects?

> (e.g. the :DEFAULT:) any more,
Okay.  I was under the assumption that once a setting has been changed for
a particular executable, the executable was no longer in the default ACL.

> 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.
Ahhh.  So how does one go about restricting a particular executable from
deleting files?  Can this be done with RSBAC?  Is there a quick and simple
was of saying something like the following: "executable 'foo' has the default
policy (similar to a default firewall policy) that it cannot delete any files
anywhere, except where explicit rules otherwise grant deletion"
Put another way:
rule 1: process 'foo' cannot delete any files whatsoever
rule 2: process 'foo' can only delete /tmp/bar and /tmp/baz





Michael




-- 
/* BEGIN SIG 
*
* "Afraid of change, afraid of staying the same,
*  when temptation calls, we just look away."
*  - Barenaked Ladies
*
* "He started writing in mirror writing, 'Help! I'm
*  trapped behind the world.'"
*  - New York State Journal of Medicine
*
*-----------------------------
* Michael Chang
* miranda@uranus.com
* http://www.syndetic.org/
*/