On Tue, 2006-08-08 at 14:47 -0500, Klaus Weidner wrote:
> On Tue, Aug 08, 2006 at 04:22:54PM -0300, Thiago Jung Bauermann wrote:
> > We did one test with the auditallow rule for write and another with the
> > auditallow rule for setfscreate. The records found in the audit log for
> > both tests are attached. The difference is that the auditallow rule for
> > the write operation adds PATH and AVC_PATH audit records, while the
> > setfscreate rule just generates AVC and SYSCALl records.
>
> Thanks for testing! The record is fine, the path information isn't needed
> since the AVC record contains both the PID and the operation type
> (setfscreate). It's more informative than the write record.
>
> Can a loadable policy module add "auditallow" entries like these, or does
> this need to go into the base policy?
They can go in a module if you want.
# cat foo.te
policy_module(foo, 1.0)
require {
attribute domain;
}
auditallow domain self:file write;
auditallow domain self:process setfscreate;
# make -f /usr/share/selinux/devel/Makefile
# semodule -i foo.pp
> > Both mention the pid and security context of the subject changing the
> > fscreate file both in the AVC message and in the SYSCALL message, but
> > none of them displays the new contents of the fscreate file.
> >
> > Klaus: do you think the info there is sufficient for LSPP?
>
> It would be nice to have the new fscreate context in the log, but it's
> not required by LSPP. (The "additional event details" column doesn't list
> it, and it's not one of the standard required audit record fields.)
You should be able to capture the actual context by auditing the file
create permission check that would occur upon the actual file creation.
--
Stephen Smalley
National Security Agency
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
