On Thu, 21 Apr 2005 14:13:29 +1000, Russell Coker said: > On Thursday 21 April 2005 04:50, "Christofer C. Bell" > 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 > every boot. > > It is expected to happen, it happens on every boot. Right - my objection is that we're putting in dontaudit rules to shut stuff up during boot - but if the same thing happens *later*, we won't hear about it (I know that *I* would certainly want to know if an access was denied because /usr wasn't a usr_t once we got up in multiuser, if only because at that point, a *lot* of stuff would break with absolutely no indication of why. Certainly a violation of the "expected to happen" rule once we're out of rc.sysinit... Similarly, if anything managed to trigger that dontaudit rule *after* we booted, by virtue of some access *elsewhere* in the file system, I'd want to know about that as well. > > Regardless if the fix can be automated or not, telling the system to > > "just ignore it" is inappropriate IMO. Unfortunately, there's no "just ignore it while we get our act together" for the weirdness that happens during system boot. And we're talking about something that if it ever actually happens after we've gotten out of rc.sysinit, we *do* want to know about it... > 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. Relabelling the /dev mountpoint is quite non-trivial, because booting to single-user in Fedora still gets udev started and a tmpfs mounted over /dev. I ended up having to boot from the rescue disk and having to do something like: chroot /mnt/sysimage mount -t selinux /selinux restorecon /dev > 2) Have more error messages in the logs. This leads to users ignoring the > more important AVC messages which is a security issue. Quite right - my concern was that we're trying to silence a few msgs at boot and thus *forcing* the user to ignore the same message during normal operations, when it *would* be a "more important" message... > 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 . Unfortunately, the /.autorelabel trick happens too late - it's done right *after* we've mounted all the filesystems and enabled disk quotas. The checking would need to be *really* early in rc.sysinit - like before start_udev gets called. Remember - what got me started on this was the 'mount -t tmpfs /dev' issuing a message because it was trying to mount onto a mislabeled /dev... > 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. Actually, there's another option: 4) Add code to 'anaconda' (or whatever your distro uses) to do the appropriate 'restorecon' for the mount points for file systems created during system install. It knows (or can be taught) what directories in / (/dev, /proc, /sys, and /selinux) will have pseudo file systems mounted on them, and what directories will have file systems mounted over them (/var, /tmp, /usr/local, / usr/share, /home, /opt, and so on). After the install, if /usr was a single filesystem, and the admin decides that they want /usr/local and /usr/share to be 2 new file systems, that's OK, because the first 'fixfiles relabel' will have set the right settings on the 'local' and 'share' directories that will now be mount points... That still has issues with an admin creating a /foo filesystem, mounting it, and later on we decide to add a special context for /foo - but as long as /foo doesn't become required to get to multiuser mode, the admin can just 'umount /foo; restorecon /foo; mount /foo; restorecon -R foo' and be done.
Attachment:
pgpKnfCHer26Q.pgp
Description: PGP signature
-- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-selinux-list
