Creating new roles

[Stephen Smalley]

On Thu, 2005-01-13 at 17:47, Steve Brueckner wrote:
> I spent my first couple of days in SELinux tinkering with FC2, and only
> installed FC3 today.  It's possible I may not yet fully appreciate the
> differences in working with the targeted policy.  I see now that even though
> multiple roles are defined, they're all assigned to the unconfined_t domain.
> 
> The targeted policy appeals to me for the obvious reasons: I'd like most of
> the system to run without the complications introduced by SELinux.  I'd
> rather not go back to the strict policy unless I have to.
> 
> My goal, however, is to do some fairly serious policy writing to lock down a
> few applications, but leave most of the system alone.  I think I'll need to
> make new domains, new roles, and new transitions to do this.  
> 
> >From my limited understanding, it looks like even though the default
> targeted policy is role-blind, I should be able to modify it to add my own
> custom roles that aren't of type unconfined_t.  After all, it's still
> SELinux under the hood, isn't it?  Or am I missing something fundamental?
> Will I have no choice but to use the strict policy as my starting point?

The mechanism is the same, only the policy configuration differs.  But
the differences in the policy configurations are substantial and
structural, and it should be easier to take the strict policy as your
starting point and move certain programs into its unconfined_t domain if
you truly want user roles and domains.  But if you merely want to lock
down additional applications, you can do that with the targeted policy,
and you do not need new roles at all, just domains for those programs. 
The process transition permission controls the ability to transition
among domains on a pairwise basis, so the fact that domains foo, bar,
and baz are all associated with role R does not mean that they can jump
among each other.


-- 
Stephen Smalley <sds at epoch.ncsc.mil>
National Security Agency