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

Amon Ott rsbac@rsbac.org
Mon Jan 6 09:57:01 2003


On Saturday 04 January 2003 10:09, Michael Chang wrote:
> On Fri, 3 Jan 2003, Amon Ott wrote:
> > 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.

Just set RSBACLOGFILE to a file name, export it, call a menue and you will 
get everything logged to this file.

> If I specify a device file, do I have to use the major:minor convention, or
> can I use the convenient /dev entry?

Please use the /dev entry with the DEV target type. major:minor is not 
sufficient, you would also need the device type char or block. This latter 
way has never been implemented into the tools, although it is supported in 
the system calls.
 
> 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?

No, this reverse lookup is almost impossible with reasonable costs - RSBAC 
internally only uses inode numbers.

Please do not take the device special files in /dev for the real devices - 
there may be many of them pointing to the same device. This is why the device 
specials themselves are treated as files.

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

Correct. Inode numbers provide the only reliable and persistent way of object 
reidentification.

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

Sure, it just has to be done by someone. My schedule is pretty packed.

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

A subject in RSBAC is a process, working on behalf of a user and executing a 
file with a set of mapped libraries.

In AUTH, the setuid caps are assigned to the executable file and directly to 
processes. On execution of a new file, the cap set of a process is cleared 
and replaced by that of the file.

After that, the set can only be changed by another process with the 
auth_may_set_cap flag. This scheme can be used to enforce authentication by a 
central authentication daemon with special rights and strong protection.

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

Not at all. Each module can add further restrictions, but it cannot override 
those placed by another module.

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

I call an ACL entry at an object a set of direct rights to this object. The 
effective privileges are based on direct rights through user, group and role 
ACLs and on inherited rights, which have been given to a parent dir object, 
but get filtered through the inheritance mask.

> > 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?)

This is the basic and default mechanism.

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

Filesystem parent dirs or the :DEFAULT: ACL for the target type.

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

The ACL has no idea of executables as subjects, but the RC model has. You can 
assign an RC role to the executable and grant ACL rights to the role.

Usually, program based rights are given with the RC model. Here is an example 
for the power of a multi-policy framework: You can use individual ACLs on 
user home directories, encapsulate all daemons with the RC or the JAIL model, 
set some global FF file/dir flags for static disk content and control user 
IDs with AUTH.

Or, with different words: In a multi-policy framework, you can choose the 
appropiate and best fitting security model for each part of the protected 
system.

In my server setups, I always use RC as the main model - roles and types are 
more powerful and easier to maintain than ACLs, and RC also provides a better 
separation of duty for administration.

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