[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Experiences with selinux enabled targetted on Fedora Core 3

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: pgp00004.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]