[refpolicy] Further questions about configuring contexts differently for variant classes
russell at coker.com.au
Fri Mar 4 04:57:11 CST 2011
On Fri, 4 Mar 2011, HarryCiao <harrytaurus2002 at hotmail.com> wrote:
> > It certainly would be nice to have all objects get the role of their
> > creator so we can bring role-based policy separations back using RBAC
> > features and not rely on 1:1 user:role mapping + UBAC.
> 4. It seems that we used to have RBAC, then why we have to have dropped it?
> 5. Does the "1:1 user:role mapping" mean the mapping from linux user to
> selinux user, and the mapping from selinux user to the roles that he/she
> could assume? 6. Any discussion email thread about how UBAC works and why
> we would want "1:1 user:role mapping + UBAC"?
The RBAC we used to have was based on the role for a process context being
used to determine the set of domains used by processes that it may launch, and
the domains used by those processes determined the types of files.
So user_r process role gets user_t as the main domain which can write to
user_home_t. staff_r process role gets staff_t as the domain and can write to
staff_home_t. There were also domains like user_mozilla_t and staff_mozilla_t
which do what you probably expect. But all files created by all of those
processes had the role object_r.
During the time that I've been working on SE Linux (since mid 2001) there has
never been a role used for real files (as opposed to labels on /proc entries
etc) other than object_r.
The idea of giving objects the role of their creator relies on kernel code
which AFAIK has never been written in the history of SE Linux (unless it
happened to be in the very early versions).
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
More information about the refpolicy