[rsbac] RSBAC: Inconsistencies, confusion galore...
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
> > 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
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.
> > you make changes, the new values will be used at the next request and
> > it.
> I see. You're not altering file descriptors, per se; instead, you're using
> inodes themselves?
Correct. Inode numbers provide the only reliable and persistent way of object
> > > 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
> > to make tools which were better to use for scripting, while the existing
> > (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
> > > in the context of the RSBAC implementation?
> > The AUTH model defines setuid capabilities, which allow to CHANGE_OWNER
> > user ID specified in such a capability. Since this right is given
> > 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
> 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
> 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
> 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
> > 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
> policy (similar to a default firewall policy) that it cannot delete any
> 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
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.
http://www.rsbac.org - GnuPG: 2048g/5DEAAA30 2002-10-22