--- Michael C Thompson <[EMAIL PROTECTED]> wrote: > Understandable, I think the role of auditadm is > pretty clear (affecting > audit changes, and that's it).
Consider also the ability to kill arbitrary processes. That way the auditor can take action should unwanted behavior be detected. The auditadm should own the audit files so that they can be manipulated by the auditadm. Little things, but we found they make the role much more real-world useable. > It seems that sysadm > is the overall admin > role, so does the following diagram make sense? > > ------------- sysadm ----------- > -- auditadm -- -- secadm-- > > auditadm and secadm have some unique capabilities, > but share > functionality with sysadm, but from what I can tell, > not with each other. I worked at it for years and never came up with a useful secadm role. There are just not enough things that a secadm can do that don't also require non-security activities. > What are the capabilities of secadm? Changing > security contexts of > files, etc? Anything else? The sysadm needs to do that, for program installation and creation of user accounts. > > I think the most important > > part is that sysadm should be prevented from using > auditctl to modify > > rules, and from stopping/restarting auditd, which > would ensure that the > > sysadm can't change the audit config without > restarting the entire > > system. > > I would agree, I need to know what the approach will > be so I can test > though. The Unix experiance is that an auditadm is good and a secadm is not worth the bother because the secadm role is too tightly bound to the sysadm role. Casey Schaufler [EMAIL PROTECTED] -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
