[redhat-lspp] [Fwd: Re: Latest diffs in policy]

[Stephen Smalley]

On Tue, 2006-05-16 at 08:49 -0500, Michael C Thompson wrote:
> Stephen Smalley wrote:
> > On Tue, 2006-05-16 at 08:43 -0400, Steve Grubb wrote:
> >> On Tuesday 16 May 2006 08:21, Daniel J Walsh wrote:
> >>> I want to open up discussion of removal of the secadm_t policy and
> >>> roling it into sysadm_t and make auditadm_r match what Michael and Casey
> >>> have defined.
> >> I really think the original intent of the secadm role was to separate audit 
> >> use/control from admin role. I think the role name may have lead to confusion 
> >> and people then wanted an audit admin role because that *was* needed. Then 
> >> the problem became "what is the definition of the security admin?"
> >>
> >> So, I vote for combining secadm with sysadm.
> > 
> > People often ask for a security officer / administrator role in SELinux
> > separate from the system administrator role.  We've often explained that
> > truly separating the two in a way that prevents subversion of one from
> > the other is difficult without greatly impairing the ability of either
> > to work normally, but they seem to just want the basic separation of
> > function between policy administration and normal system administration
> > without necessarily preventing a malicious sysadmin from gaining access
> > to secadm.  So you may want to retain a separate secadm, with a tunable
> > to fold it into sysadm for common use.
> 
> I'm not totally up on creating policy , but wouldn't leaving the secadm 
> tunable keep the problem of expressing exactly what his role is around?

You still have to define what secadm can do (logically, it would be
tasks relating to MAC policy administration).  But by providing the
tunable, you allow people who don't care to collapse them together under
sysadm.  And you don't worry about full separation (i.e. you aren't
trying to prevent a malicious sysadmin from compromising secadm, because
to do so you have to prevent him from doing almost everything, reducing
him from an actual admin to just an operator).

> I'll be happy with what we go with, but it would make testing a lot 
> easier if we had only two admin roles which were clearly defined.

-- 
Stephen Smalley
National Security Agency