On Thursday 21 April 2005 04:50, "Christofer C. Bell"
> > I can't speak for Valdis, but for me the word
"kludge" comes to mind.
> It's not a kludge. The purpose of dontaudit rules is to prevent auditing
> of operations that are not permitted, not interesting, and expected to
> happen. This is exactly the situation.
You say that dontaudit rules are to cover the following circumstances:
1. Not permitted.
2. Not interesting.
3. Expected to happen.
That's not what's going on here and using dontaudit is a kludge. The
OP is stating that *mount points* for /usr, /usr/local, and
/usr/share are generating complaints because they're not properly
labled prior to being mounted. These are the directories themselves
and not directories that are hidden by the mount. This is
"interesting" and "not expected to happen," failing points 2 and 3.
It is not interesting that programs try to access files under mount points
early in the boot process before the file systems are mounted. It happens on
It is expected to happen, it happens on every boot.
Regardless if the fix can be automated or not, telling the system to
"just ignore it" is inappropriate IMO.
The alternatives are as follows:
1) Have the users manually relabel. But this requires that they have the
skill needed to use mount --bind or single user mode.
2) Have more error messages in the logs. This leads to users ignoring the
more important AVC messages which is a security issue.
3) Have more complex code in rc.sysinit for relabeling file systems (which is
therefore more error prone) and also remove the possibility of running
"fixfiles relabel" as administrator and forcing a reboot with /.autorelabel .
All the options have disadvantages that I consider to be more serious than the
reasons that make you dislike the dontaudit rule.
Option 3 is the only remotely viable option. That requires implementing shell
code equivalent for
"mount -a -t nonfs,nfs4,smbfs,ncpfs,cifs,gfs -O no_netdev" to allow running
setfiles between mounts. I don't think that we want to do this.
Feel free to disbelieve me, but if so spend a month writing policy in the
manner you advocate and see where it gets you. If that doesn't convince you
then spend a year or two writing policy and see if your opinion changes.
My NSA Security Enhanced Linux packages
Bonnie++ hard drive benchmark
Postal SMTP/POP benchmark
My home page