[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 Sunday 24 April 2005 18:40, Valdis Kletnieks vt edu wrote:
> > 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:

Here you are just proving my point about the operation being overly difficult.
mount --bind / /mnt ; chcon /mnt ...

But there's lots of potential for things to go spectacularly wrong when you do 
a bind mount (think about what would happen if you ran "fixfiles relabel").

> chroot /mnt/sysimage
> mount -t selinux /selinux
> restorecon /dev

We could of course have the rescue disk contain scripts to manage such things, 
but again it's really painful, it would require changing code in several 

> > 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...

dontaudit pam_console_t file_t:dir search;
dontaudit dmesg_t file_t:dir search;
dontaudit hostname_t file_t:dir search;
dontaudit hotplug_t file_t:dir { search getattr };
dontaudit hwclock_t file_t:dir search;
dontaudit kudzu_t file_t:dir search;
dontaudit lvm_t file_t:dir search;
dontaudit insmod_t file_t:dir search;
dontaudit mrtg_t { boot_t device_t file_t lost_found_t }:dir getattr;
dontaudit sulogin_t file_t:dir search;
dontaudit syslogd_t file_t:dir search;
dontaudit udev_t file_t:dir search;

According to a quick grep the above are the domains that have such dontaudit 
rules.  Note that for some it doesn't matter at all, the system is in 
permissive mode for sulogin_t, mrtg does an operation equivalent to
"ls -l /" without any good cause, etc.

> > 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...

We could change the .autorelabel code to be more complex, use bind mounts, 
etc.  But that also means more failure conditions.

Note that there is an opportunity cost to everything we do.  There are lots of 
features that I would like to get in that require more work from the 
maintainers of such packages.  Is it worth delaying work on SE-X, 
crypto-root, and other security features to remove a few dontaudit rules?

> 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.

That also has issues related to fsck removing xattrs on corrupted filesystems, 
administrators converting non-SE systems to SE Linux, administrators booting 
machines with selinux=0 while they repartition disks, and all manner of other 
potential problems.

The /.autorelabel file MUST do everything that we require in terms of fixing 
file labels.  We can't rely on anaconda or anything else to fix things up.

http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

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