Re: Further questions about configuring contexts differently for variant classes

[Stephen Smalley <sds@tycho.nsa.gov>]

On Fri, 2011-03-04 at 10:38 +0000, HarryCiao wrote:
> Hi Stephen and Chris,
> 
> I would like to dig deeper on this topic and I have started thinking
> below questions as a starting point, it definitively would help me to
> get warmed up quickly if you could help pointing me at the background
> story :-)
> 
> [cut]
> > > ... Maybe we can come up with some generalized
> > > solution that will be more flexible going forward for configuring
> how
> > > different parts of the context are assigned for different classes.
> We
> > > have talked previously about using the role field even for files
> rather
> > > than just making them all object_r.
> > 
> 
> 1. Would it work simply to make the newly created objects have the
> role of "scontext->role" than "object_r" in security_compute_sid?

No, that would break existing policies.  We need a way to allow existing
systems to still use object_r while allowing future policies to leverage
new support for using the role field in object security contexts.  I
sketched one possible approach in the earlier thread that Chris
referenced, i.e. inherit from tcontext->role (parent directory) and add
role transition support on object classes.  Then on existing systems
where directories are labeled object_r, everything will still work as
before, but with new policies, we can set up role transitions on the
file classes to use the subject role where that is desired.

> 2. If files' role is not "object_r" anymore, what changes in refpolicy
> and SELinux kernel space would have to be done accordingly?

In the kernel, we check for OBJECT_R_VAL and exempt security contexts
with that role from the validation checks on user-role, role-type, and
user-range.  So using subject roles on objects will enable that checking
and require that the policy explicitly authorize those pairings.

> ! 3. Where can I find our previously talks on such topic?

Looks like Chris did a good job of hunting down the prior discussions.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.