[redhat-lspp] Re: Separation between secadm and sysadm problem????

[LC Bruzenak]

On Wed, 2006-03-15 at 12:03 +1100, Russell Coker wrote:
> On Tue, 2006-03-14 at 18:30 -0600, Klaus Weidner wrote:
> > secadm:
> > 
> > - file relabeling, including MAC overrides (upgrading and downgrading)
> > 
> > - manage MLS properties of existing OS users (essentially anything
> >   involving semanage)
> > 
> > - low-level SELinux operations (policy load, setenforce, anything that
> >   writes in /selinux ?)
> 
> That would mean changing boolean values, but not querying the kernel as
> to policy decisions.  I think that sysadm should be able to query the
> kernel as to what the current policy would do (necessary to debug policy
> related problems, even though sysadm is not authorised to fix policy
> related problems they need to be able to diagnose them).
> 
> > audadm (could be collapsed with secadm as it is now, but I think it would
> > make sense to split this if that's feasible):
> > 
> > - configure audit rules
> > 
> > - control auditd, modify auditd config
> > 
> > - read, rotate, and delete audit logs
> 
> A separate audadm provides more benefit at less cost than the separation
> of secadm IMHO.
> 
> > sysadm:
> > 
> > - everything else traditionally done by "root", including RPM package
> >   management, and managing OS users (/etc/passwd and so on)
> > 
> > Please speak up if you want a separate audadm and what your expectations
> > for roles are, I don't really have strong opinions about this and RBAC is
> > too vague to offer specific guidance.

I realize you guys are looking towards CC evaluation but I believe what
you are doing will work in the tactical word also.

FWIW in my experience there should always be a defined sysadm and secadm
along the lines you propose.

For DCID 6/3 there is (for the systems operation):
ISSM (information system security manager) : this would correlate to the
audadm. The best scenario would be as Klaus described in an earlier
email:
> 
> The best bet would be realtime audit log forwarding to a separate
> loghost (which the sysadm doesn't have access rights for), that way
> you'd get a robust audit trail about the sysadm actions.

ISSO (IS security officer): corresponds to the secadm as described
privileged users: correspond to the sysadm as described
general users: non-privileged user accounts

A word about the ISSM account: even though the DCID doesn't specifically
say it, I was told by different accreditors that they would not be as
worried about the specific authorizations afforded the sysadm/secadm
accounts (still should be well-defined and separate) IF the audit trail
was not editable by either of them, and only the ISSM had delete/edit
access.

For our successor system architecture, it is my goal to provide:
1: audit data not accessible by the sysadm or secadm, and
2: a stand-alone audit machine where the ISSM (who is someone not
intimately familiar with the system machinery) can run an audit analysis
tool appropriate for the site.

I believe a system configured in this manner would be a great hit with
the IC (US Intelligence Community) in terms of accountability.

To me it appears as though what is proposed for the sysadm, secadm and
audadm could meet that goal. There might need to be some specific
configuration done, but it seems workable.

Thanks,
LCB.

-- 
LC Bruzenak
lenny at bruzenak.com