On May 26, 2007, at 22:37:02, [EMAIL PROTECTED] wrote:
On Sat, 26 May 2007 22:10:34 EDT, Kyle Moffett said:
On May 26, 2007, at 19:08:56, Toshiharu Harada wrote:
(1) Object labeling has a assumption that labels are always
properly defined and maintained. This can not be easily achieved.
That's a circular argument, and a fairly trivial one at that. If you
can't properly manage your labels, then how do you expect any
security at all?
Unfortunately, it's not at all as simple as all that. Toshiharu is
quite correct that it isn't always easy to actually implement.
Consider how many ad-croc usages of 'restorecon' are needed to get
a Fedora SELinux box through rc.sysinit:
While I don't think restorecon is really necessary to properly boot
SELinux-enabled (I've got a Debian box with some heavily customized
policy which does so just fine), I am of the opinion that adding a
"name" parameter to the file/directory create actions would be
useful. For example, with such support you could actually specify a
type-transition rule conditional on a specific name or substring:
named_type_transition sshd_t tmp_t:sock_file prefix "ssh-" ssh_sock_t;
Useful options for matching would be "prefix", "suffix", "substr
(start,len)". "regex" would be nice but is sorta computationally
intensive and would be likely to cause more problems than it solves.
/sbin/restorecon -R /dev 2>/dev/null
[ -n "$SELINUX_STATE" ] && restorecon /dev/mapper /dev/mapper/
control >/dev/null 2>&1
These can go away if you modify your policy and pass "-o
fscontext=system_u:object_r:dev_t" to the mount command for the /dev
tmpfs, changing both the filesystem and the default directory labels
from the default "system_u:object_r:tmpfs_t". This will work as long
as your policy files contain appropriate transitions from the dev_t
type.
REBOOTFLAG=`restorecon -v /sbin/init`
restorecon /etc/mtab /etc/ld.so.cache /etc/blkid/blkid.tab /etc/
resolv.conf >/dev/null 2>&1
[ -n "$SELINUX_STATE" ] && restorecon /tmp
[ -n "$SELINUX_STATE" ] && restorecon /tmp/.ICE-unix >/dev/null 2>&1
I believe these are to handle rebooting from non-SELinux mode. There
are two solutions to this kind of problem:
(1) Failing the boot if the labels are wrong
(2) Fixing the labels (and rebooting if necessary)
It would appear that FC does the latter, although for certain high-
security systems (such as firewalls handling classified/confidential
data), the first option is the only acceptable one.
[ -n "$SELINUX_STATE" ] && restorecon /dev/pts >/dev/null 2>&1
I think this can be handled with some combination of appropriate
SELinux policy and mount options. At least, I don't need this in the
boot scripts on my heavily customized Debian SELinux box.
[ -n "$SELINUX_STATE" -a -e "$path" ] && restorecon -R "$path"
I don't know what the point of this generic line is; but I certainly
don't have anything of the sort on my test system, and it appears to
work just fine.
And that's just getting the system up to single-user. Things like
sendmail and sshd require more restorecon handholding in their
rc.init files.
Or just look at the creeping horror that is 'restorecond' (in
particular, consider that the default restorcond.conf contains the
strings '~/public_html' and '~/.mozilla/plugins/
libflashplayer.so'. Yee. Frikkin. Hah. ;)
Part of the reason that Fedora has a large quantity of that
restorecon and restorecond crap is that there is a certain amount of
broken binary software needing executable stack/heap (such as
flashplayer), programs without comprehensive or complete policies, or
programs which by definition need extra support for SELinux.
For example, to really complete the SELinux model you need editors
and tools which understand security labels the same way they
understand UNIX permissions. With a bit of vim scripting I can
probably make it run external commands to read file labels before it
reads the file itself and modify /proc/self/attr/fscreate before
writing out the file, similar to the way it would keep track of the
standard DAC permissions on files it modifies.
There's also the fact that corporate products have fixed release
schedules so remaining bugs in each release tend to get papered over
instead of fixed properly (such as the restorecon in FC init-
scripts). I haven't seen many problems with the SELinux model which
aren't associated with working around buggy software or missing
features.
Cheers,
Kyle Moffett
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
