On Mon, 2006-05-01 at 17:13 -0500, Klaus Weidner wrote: > On Fri, Apr 28, 2006 at 05:45:05PM -0400, Daniel J Walsh wrote: > > Michael C Thompson wrote: > > >I just checked, and with policy selinux-policy-mls-2.2.35-2, sysadm_r > > >and secadm_r can modify /etc/auditd.conf, /etc/audit.rules, > > >/etc/init.d/auditd can read and write these files. > > > > > secadm should not be able to edit auditd.conf or audit.rules. That is a > > bug. I do not know about sysadm > > We can't expect a totally robust split between sysadm and audadm, and > LSPP/RBAC still assume a trustworthy admin. 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. > > Making /etc/audit.rules unwritable would be reasonable, but I think it > would be ok to keep /etc/init.d/auditd and the auditd binary and > libraries writable for sysadm. A malicious sysadm can fairly easily > subvert audit (for example via custom rpm packages, kernel changes, > library changes, debugfs, ...), and we need to draw the line somewhere. > I think we need to accept that the system may be in an undefined state > after a reboot if sysadm is malicious. > > Can the RPM pre/postinstall scripts currently do absolutely anything? > That would be an unpleasant loophole, but I don't know an easy way to fix > that without potentially breaking RPM. > > -Klaus
Klaus, FWIW everything above sounds very reasonable to me. If you have the division as you have indicated then can one rely on file watches on the audit config files, the current kernel, etc. to flag a change? The security-relevant file watch set would include all those files you listed. That would at least put the change into the audit logs. Our own audit scan code should flag those during audit verification by the audadm. Also any audit time lapse, unaccounted-for downtime, etc. When we leave a site configured we also remove any patching capabilities, locking up a tape with the patch tools in the audadm's safe. So at least for us currently any patches added are (theoretically) under a controlled mechanism. In the same manner we would probably remove the rpm tools if possible. It would be nice to still have the listing capability without the install/update capability but we can work with whatever we have. LCB. -- LC Bruzenak [EMAIL PROTECTED] -- redhat-lspp mailing list [EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-lspp
