Just an idea, but why not have udev set the context on its root path?
I have a simplistic patch for this if its a good idea.
Regards Nigel Kukard
On Mon, Aug 30, 2004 at 07:37:44PM +0200, Nigel Kukard wrote:
Just an idea, but why not have udev set the context on its root path?
you mean on /dev, i presume?
well i had to patch selinux/hooks.c to allow this [on a tmpfs] by relaxing the criteria of the "fscontext=" option for mount.
otherwise it's not _possible_ t set the context on /dev as it is mounted [on a tmpfs].
[if /dev was a persistent filesystem everything would be hunky-dory and this wouldn't be an issue].
with that in mind, it's more that because you're putting device inodes into a non-persistent filesystem, you end up getting the "default" rules and so you must "restore" the contexts, or you must patch udev to "understand" the contents of /etc/selinux/src/file_contexts/file_contexts (using matchpathcon() and setfscreatecon() from libselinux) such that it will create inodes with the right file context.
like i said, if /dev was a persistent filesystem, and if device inodes never disappeared, this wouldn't be a problem: you could run setfiles /etc/selinux/src/file_contexts/file_contexts /dev and be done with it...
... but that's not how udev works: it deletes and creates inodes on demand; nothing exists at boot-time, it's all created on-demand.
so, not only must udev be patched to restore contexts but also the policies and various hacks added to "cope" with /dev being incredibly basic at startup - prior to udev running.
_including_ dealing with getting the contexts correct on entries in /.dev [the old /dev remounted with mount --rbind]
l.
you mean on /dev, i presume?
yep, or /udev (configured in the udev config file)
well i had to patch selinux/hooks.c to allow this [on a tmpfs] by relaxing the criteria of the "fscontext=" option for mount.
if its tmpfs, this would void the requirement of passing a mount option fscontext, udev would set the correct context when started up (a check could also be added to do this only if the mount point is /dev and its tmpfs... *shrug*)
otherwise it's not _possible_ t set the context on /dev as it is mounted [on a tmpfs].
[if /dev was a persistent filesystem everything would be hunky-dory and this wouldn't be an issue].
*nod*
with that in mind, it's more that because you're putting device inodes into a non-persistent filesystem, you end up getting the "default" rules and so you must "restore" the contexts, or you must patch udev to "understand" the contents of /etc/selinux/src/file_contexts/file_contexts (using matchpathcon() and setfscreatecon() from libselinux) such that it will create inodes with the right file context.
I applied the patch to tmpfs to make it store xattr attributes which i found on the mailing list, seems your patch forgets xattr.h?
I also applied the patch which adds "matchpathcon()" & "setfscreatecon()" support, and modified udev to set the correct context of its root_path on startup.
... but that's not how udev works: it deletes and creates inodes on demand; nothing exists at boot-time, it's all created on-demand.
at boot time i have about 5 devices in /dev with correct contexts set, udev them mounts tmpfs over this, WorksForMe(tm)
so in actual fact we do need matchpathcon() & setfscreatecon(), if its a persistent or non-persistent filesystem
so, not only must udev be patched to restore contexts but also the policies and various hacks added to "cope" with /dev being incredibly basic at startup - prior to udev running.
i have a simple persistent /dev which is used before udev runs, udev is then initialized, mounts a tmpfs over /dev (and restores its context) just after sysctl -p is run in my initscripts so its basically one of the first things to run. Seeing as my initial /dev is on a persistent filesystem i don't have a problem with pre-udev stuff running.
_including_ dealing with getting the contexts correct on entries in /.dev [the old /dev remounted with mount --rbind]
l.
On Tue, Aug 31, 2004 at 07:02:52AM +0200, Nigel Kukard wrote:
you mean on /dev, i presume?
yep, or /udev (configured in the udev config file)
oh.
yes.
redhat :)
well i had to patch selinux/hooks.c to allow this [on a tmpfs] by relaxing the criteria of the "fscontext=" option for mount.
if its tmpfs, this would void the requirement of passing a mount option fscontext, udev would set the correct context when started up (a check could also be added to do this only if the mount point is /dev and its tmpfs... *shrug*)
otherwise it's not _possible_ t set the context on /dev as it is mounted [on a tmpfs].
[if /dev was a persistent filesystem everything would be hunky-dory and this wouldn't be an issue].
*nod*
with that in mind, it's more that because you're putting device inodes into a non-persistent filesystem, you end up getting the "default" rules and so you must "restore" the contexts, or you must patch udev to "understand" the contents of /etc/selinux/src/file_contexts/file_contexts (using matchpathcon() and setfscreatecon() from libselinux) such that it will create inodes with the right file context.
I applied the patch to tmpfs to make it store xattr attributes which i found on the mailing list, seems your patch forgets xattr.h?
?? oops.
okay, i had put it at http://www.hands.com/~lkcl/selinux/2.6.6/ and when i posted copies to the list i must have missed it out.
if you _do_ know how to properly create patches that other people can apply simply, that'd be great.
I also applied the patch which adds "matchpathcon()" & "setfscreatecon()" support,
dan is working on a new version of that, for udev-0.030-10.
and modified udev to set the correct context of its root_path on startup.
mount -o fscontext=system_u:object_r:device_t yes?
did you patch selinux/hooks.c to relax the constraints on the fscontext= parameter to allow the correct context to be correctly applied? :)
... but that's not how udev works: it deletes and creates inodes on demand; nothing exists at boot-time, it's all created on-demand.
at boot time i have about 5 devices in /dev with correct contexts set, udev them mounts tmpfs over this, WorksForMe(tm)
so in actual fact we do need matchpathcon() & setfscreatecon(), if its a persistent or non-persistent filesystem
yep.
so, not only must udev be patched to restore contexts but also the policies and various hacks added to "cope" with /dev being incredibly basic at startup - prior to udev running.
i have a simple persistent /dev which is used before udev runs, udev is then initialized, mounts a tmpfs over /dev (and restores its context)
oh. ah.... you _restore_ its context (i.e. run restorecon /dev), you don't mount it with the modified mount -o fscontext= parameter?
just after sysctl -p is run in my initscripts so its basically one of the first things to run.
yep.
Seeing as my initial /dev is on a persistent filesystem i don't have a problem with pre-udev stuff running.
well.... you shouldn't... until you reinitialise or somehow delete, upgrade or otherwise modify the "old" /dev [which you will find is remounted --rbind to /.dev].
try it: do setfiles /etc/selinux/src/file_contexts/file_contexts /.dev and then reboot [in permissive mode!!!]
due to the present files/types.fc, you will find that the entire /.dev gets relabelled to something completely useless: root_t or default_t. i think it's default_t.
consequently your next reboot in enforcing mode will fail because /sbin/init tries to access /dev/null and /dev/initctl etc. as default_t ... and it can't.
should you choose to deal with this, replace /u?dev with /[.u]dev or some suitable regexp that i haven't a clue how to write so i just did /.?u?dev and that did the trick.
the only _other_ thing you might find is that things like dialup don't or won't have been loaded.
so i had to add in a _second_ version of /etc/init.d/modutils which does exactly the same as /etc/init.d/modutils ... but with a different list of modules, and AFTER udev has been run, not before.
the list i have so far in /etc/modules.postudev contains (for my purposes):
ppp_generic nvidia sg
ppp_generic is there because "pon provider" bitches about /dev/ppp not existing
sg is there because of usb-mount using sg_mod: if the module is pre-loaded, then /dev/sg0 gets created by udev.
i don't believe that these modules should be loaded prior to udev being run: maybe they can, maybe they can't, maybe the nodes being loaded prior will result in a pending hotplug event such that when udev is run, the node gets created.
... but certainly, _some_ modules haven't been modified to conform to the new /sys thing.
the "trick" of a node in /dev existing, and its first access automatically triggering a modprobe... well that only works if the node is there, and of course with udev, it isn't.
perhaps there should be a "hook" into tmpfs to be able to pass filenames accessed in /dev on to udev, such that udev can go "oo, they tried to access /dev/ppp, let's kick off that module, then".
l.
On Tue, Aug 31, 2004 at 10:49:08AM +0100, Luke Kenneth Casson Leighton wrote:
yep, or /udev (configured in the udev config file)
oh.
yes.
redhat :)
no... it just depends how you want it configured ;-)
I applied the patch to tmpfs to make it store xattr attributes which i found on the mailing list, seems your patch forgets xattr.h?
?? oops.
okay, i had put it at http://www.hands.com/~lkcl/selinux/2.6.6/ and when i posted copies to the list i must have missed it out.
if you _do_ know how to properly create patches that other people can apply simply, that'd be great.
*nod*, i'm pondering creating the patches... let me see what i can do
I also applied the patch which adds "matchpathcon()" & "setfscreatecon()" support,
dan is working on a new version of that, for udev-0.030-10.
cool, that will at least remove 1 patch out my build tree
and modified udev to set the correct context of its root_path on startup.
mount -o fscontext=system_u:object_r:device_t yes?
nope.... mount -t ramfs none /dev
then run udevstart (udevstart does the C call to restorecon on root_path, so it ends up being labeled with whatever is configured)
did you patch selinux/hooks.c to relax the constraints on the fscontext= parameter to allow the correct context to be correctly applied? :)
correct, not sure if this is the 100% right way to do it though, I think it would be better for the capabilities of the fs to be set properly instead of commenting out code, this will have better chance being included mainstream.
so, not only must udev be patched to restore contexts but also the policies and various hacks added to "cope" with /dev being incredibly basic at startup - prior to udev running.
i have a simple persistent /dev which is used before udev runs, udev is then initialized, mounts a tmpfs over /dev (and restores its context)
oh. ah.... you _restore_ its context (i.e. run restorecon /dev), you don't mount it with the modified mount -o fscontext= parameter?
correct!, it does the restore in udevstart
Seeing as my initial /dev is on a persistent filesystem i don't have a problem with pre-udev stuff running.
well.... you shouldn't... until you reinitialise or somehow delete, upgrade or otherwise modify the "old" /dev [which you will find is remounted --rbind to /.dev].
got no reason to add other entries to the pre-udev /dev, so as I said ItWorksForMe(tm).
try it: do setfiles /etc/selinux/src/file_contexts/file_contexts /.dev and then reboot [in permissive mode!!!]
due to the present files/types.fc, you will find that the entire /.dev gets relabelled to something completely useless: root_t or default_t. i think it's default_t.
yep, i'm 100% aware of this... i don't need /.dev, nor do I have it, nor do I want it ... heh, on installation of our distribution the pre-udev /dev is created and labeled correctly.
consequently your next reboot in enforcing mode will fail because /sbin/init tries to access /dev/null and /dev/initctl etc. as default_t ... and it can't.
yep, but as I said... i don't label pre-udev /dev when udev is running, before I added it to our distro installer I mounted /dev/hda1 (root) as /mnt/hda1, chroot'd onto it and re-labeled the files there (basically the same thing our installer does)
should you choose to deal with this, replace /u?dev with /[.u]dev or some suitable regexp that i haven't a clue how to write so i just did /.?u?dev and that did the trick.
thats a good idea ;-), although in "my" case didn't need it.
the only _other_ thing you might find is that things like dialup don't or won't have been loaded.
i don't have any problems with this ;-)
so i had to add in a _second_ version of /etc/init.d/modutils which does exactly the same as /etc/init.d/modutils ... but with a different list of modules, and AFTER udev has been run, not before.
the list i have so far in /etc/modules.postudev contains (for my purposes):
ppp_generic nvidia sg
no probs with any of these either (and yes we do use them), the pc i'm on runs dual-head nvidia ;-)
every distro is different, so i would expect some to gulp bubbles and some not to... *shrug*
i don't believe that these modules should be loaded prior to udev being run: maybe they can, maybe they can't, maybe the nodes being loaded prior will result in a pending hotplug event such that when udev is run, the node gets created.
we load them after udev, and everything ends up labeled correctly...
for instance...
ot@localhost.localdomain policy]# ls -Z /dev/ppp ls: /dev/ppp: No such file or directory [root@localhost.localdomain policy]# modprobe ppp_generic [root@localhost.localdomain policy]# ls -Z /dev/ppp crw------- root root system_u:object_r:ppp_device_t /dev/ppp [root@localhost.localdomain policy]#
perhaps there should be a "hook" into tmpfs to be able to pass filenames accessed in /dev on to udev, such that udev can go "oo, they tried to access /dev/ppp, let's kick off that module, then".
if you need any of my initscripts or anything, give me a shout, i've nearly got a 100% functional selinux enabled server! ;-)
just writing a few security policies
On Tue, Aug 31, 2004 at 12:27:15PM +0200, Nigel Kukard wrote:
and modified udev to set the correct context of its root_path on startup.
mount -o fscontext=system_u:object_r:device_t yes?
nope.... mount -t ramfs none /dev
then run udevstart (udevstart does the C call to restorecon on root_path, so it ends up being labeled with whatever is configured)
oh, does it?
oh!
did you patch selinux/hooks.c to relax the constraints on the fscontext= parameter to allow the correct context to be correctly applied? :)
correct, not sure if this is the 100% right way to do it though, I think it would be better for the capabilities of the fs to be set properly instead of commenting out code, this will have better chance being included mainstream.
well if someone wants to write a new patch to hooks.c and invent a new mount -o option oh i dunno overridecontext=.... then sure.
it's all the same to me.
so, not only must udev be patched to restore contexts but also the policies and various hacks added to "cope" with /dev being incredibly basic at startup - prior to udev running.
i have a simple persistent /dev which is used before udev runs, udev is then initialized, mounts a tmpfs over /dev (and restores its context)
oh. ah.... you _restore_ its context (i.e. run restorecon /dev), you don't mount it with the modified mount -o fscontext= parameter?
correct!, it does the restore in udevstart
ok.
my question is: is this desirable behaviour?
Seeing as my initial /dev is on a persistent filesystem i don't have a problem with pre-udev stuff running.
well.... you shouldn't... until you reinitialise or somehow delete, upgrade or otherwise modify the "old" /dev [which you will find is remounted --rbind to /.dev].
got no reason to add other entries to the pre-udev /dev, so as I said ItWorksForMe(tm).
try it: do setfiles /etc/selinux/src/file_contexts/file_contexts /.dev and then reboot [in permissive mode!!!]
due to the present files/types.fc, you will find that the entire /.dev gets relabelled to something completely useless: root_t or default_t. i think it's default_t.
yep, i'm 100% aware of this... i don't need /.dev, nor do I have it, nor do I want it ... heh, on installation of our distribution the pre-udev /dev is created and labeled correctly.
... how?
and can you guarantee that it will _stay_ labelled correctly?
consequently your next reboot in enforcing mode will fail because /sbin/init tries to access /dev/null and /dev/initctl etc. as default_t ... and it can't.
yep, but as I said... i don't label pre-udev /dev when udev is running, before I added it to our distro installer I mounted /dev/hda1 (root) as /mnt/hda1, chroot'd onto it and re-labeled the files there (basically the same thing our installer does)
that's cheating :)
the list i have so far in /etc/modules.postudev contains (for my purposes):
ppp_generic nvidia sg
no probs with any of these either (and yes we do use them), the pc i'm on runs dual-head nvidia ;-)
bizarre.
how do you deal with that?
perhaps an answer would be best off-selinux list because it's not entirely relevant to selinux, more the use of it.
every distro is different, so i would expect some to gulp bubbles and some not to... *shrug*
i don't believe that these modules should be loaded prior to udev being run: maybe they can, maybe they can't, maybe the nodes being loaded prior will result in a pending hotplug event such that when udev is run, the node gets created.
we load them after udev, and everything ends up labeled correctly...
for instance...
ot@localhost.localdomain policy]# ls -Z /dev/ppp ls: /dev/ppp: No such file or directory [root@localhost.localdomain policy]# modprobe ppp_generic
^^^^^^^^^^^^^^^^^^^^ this is the bit that my /etc/init.d/modutils.postudev initscript does for me: i'd be interested to know if you do something similar.
i can't be telling users to do _that_ they're unlikely even know what a ppp is, that a modprobe is something to do with police investigations in the 70s into the sex pistols, and if you mentioned xterm they'd call rentakill.
[root@localhost.localdomain policy]# ls -Z /dev/ppp crw------- root root system_u:object_r:ppp_device_t /dev/ppp [root@localhost.localdomain policy]#
yes, this i'd expect to happen... _if_ the modprobe ppp_generic command is ever issued [and users shouldn't be expected to do it!]
perhaps there should be a "hook" into tmpfs to be able to pass filenames accessed in /dev on to udev, such that udev can go "oo, they tried to access /dev/ppp, let's kick off that module, then".
if you need any of my initscripts or anything, give me a shout, i've nearly got a 100% functional selinux enabled server! ;-)
if you could place them on a convenient http-accessible server somewhere near you, that'd be great.
l.
On Tue, Aug 31, 2004 at 10:49:08AM +0100, Luke Kenneth Casson Leighton wrote:
Seeing as my initial /dev is on a persistent filesystem i don't have a problem with pre-udev stuff running.
well.... you shouldn't... until you reinitialise or somehow delete, upgrade or otherwise modify the "old" /dev [which you will find is remounted --rbind to /.dev].
try it: do setfiles /etc/selinux/src/file_contexts/file_contexts /.dev and then reboot [in permissive mode!!!]
due to the present files/types.fc, you will find that the entire /.dev gets relabelled to something completely useless: root_t or default_t. i think it's default_t.
consequently your next reboot in enforcing mode will fail because /sbin/init tries to access /dev/null and /dev/initctl etc. as default_t ... and it can't.
should you choose to deal with this, replace /u?dev with /[.u]dev or some suitable regexp that i haven't a clue how to write so i just did /.?u?dev and that did the trick.
it's insufficient to add /.?u?dev to just file_contexts/types.fc you also have to search in file_contexts/program/* for /dev and set the right context there, too.
there is i believe a bug at present in e.g. file_contexts/program/init.fc because it only covers /dev/initctl not /udev/initctl and not /.dev/initctl.
i think this one is the only one that's really really critical [except on redhat of course where they all should be /u?dev] because if /.dev/initctl gets set to default_t, you're stuffed at next boot.
l.
On Mon, Aug 30, 2004 at 07:37:44PM +0200, Nigel Kukard wrote:
Just an idea, but why not have udev set the context on its root path?
I have a simplistic patch for this if its a good idea.
ah ha. very funny.
now i have re-read what you've said, now that i have enough background based on your further explanations in this thread, _now_ i have enough context to understand your question.
okay.
let me reiterate what i believe you have said.
you have patched the program udev (0.030-10?)
[and yes, i would highly recommend sending it to the list(s) to make it clear what you mean].
this patch will run, when it starts up, a call to setfilecon() on /dev (or /udev, or whatever the mount point of the devfs is).
and _just_ on "/dev".
yes?
and it's done BEFORE any inodes are EVER created in the new /dev, yes?
assuming yes, then it kinda-solves the need for doing that hacked-up relaxed-constraints-patch-to-hooks.c fscontext= option.
why? because you can mount -t tmpfs /dev blah blah and you don't care what the context is because udev will set the correct one when it runs.
that is - of course - assuming that file_contexts/file_contexts _contains_ the correct file context for /dev.
it might make (i dunno) for a simpler policy.
what i mean is, have you had to add in the modifications to the selinux policy that i sent to the lists last week?
e.g. these:
allow udev_tbl_t device_t:filesystem { associate }; allow initctl_t device_t:filesystem { associate };
and these:
+# needed for udev-mounted (/dev) tmpfs +allow $1_tty_device_t device_t:filesystem { associate }; + +# to allow users to run df on udev-mounted (/dev) tmpfs +allow $1_t device_t:filesystem { getattr }; + #EXE=/bin/df NAME=/ : getattr +
these are all there for reasons i cannot entirely fathom but it starts, in types/file.te, with this:
allow { device_type } device_t:filesystem associate;
which is all because of this:
mount tmpfs -o fscontext=system_u:object_r:device_t /dev
anyway what i am saying is that if you HAVE NOT got all these patches in your selinux policy files, then your approach has distinct advantages: less mods to the policy files and less differences between a persistent and non-persistent udev filesystem.
other than that, my intuition is saying "i don't like it" and what that means is that in about two or three weeks i will be able to articulate clearly and precisely why i don't think it's a good idea.
it'll likely be something to do with your solution being a two-step operation whereas the hacked-up-relaxed-fscontext-hooks.c things is a one-step (atomic?) operation.
l.
you have patched the program udev (0.030-10?)
[and yes, i would highly recommend sending it to the list(s) to make it clear what you mean].
this patch will run, when it starts up, a call to setfilecon() on /dev (or /udev, or whatever the mount point of the devfs is).
and _just_ on "/dev".
yes?
correct
and it's done BEFORE any inodes are EVER created in the new /dev, yes?
correct
assuming yes, then it kinda-solves the need for doing that hacked-up relaxed-constraints-patch-to-hooks.c fscontext= option.
aha, u correct!!!!
why? because you can mount -t tmpfs /dev blah blah and you don't care what the context is because udev will set the correct one when it runs.
perfect!!!!, so that solves the need for the hooks patch, which is in actual fact wrong.
that is - of course - assuming that file_contexts/file_contexts _contains_ the correct file context for /dev.
*nod*
it might make (i dunno) for a simpler policy.
yep
what i mean is, have you had to add in the modifications to the selinux policy that i sent to the lists last week?
e.g. these:
allow udev_tbl_t device_t:filesystem { associate }; allow initctl_t device_t:filesystem { associate };
and these:
+# needed for udev-mounted (/dev) tmpfs +allow $1_tty_device_t device_t:filesystem { associate }; + +# to allow users to run df on udev-mounted (/dev) tmpfs +allow $1_t device_t:filesystem { getattr }; + #EXE=/bin/df NAME=/ : getattr +
had to add quite a couple more, but i'm still working on that to make it "correct"
these are all there for reasons i cannot entirely fathom but it starts, in types/file.te, with this:
allow { device_type } device_t:filesystem associate;
i need this aswell.... which is very interesting, so my "way of doing it" doesn't solve this problem. i'll keep looking for the solution
which is all because of this:
mount tmpfs -o fscontext=system_u:object_r:device_t /dev
this doesn't cause the problem, its something else
anyway what i am saying is that if you HAVE NOT got all these patches in your selinux policy files, then your approach has distinct advantages: less mods to the policy files and less differences between a persistent and non-persistent udev filesystem.
correct, i'm still working on it though and it HAS TO BE COMPLETED SOON!!!!
other than that, my intuition is saying "i don't like it" and what that means is that in about two or three weeks i will be able to articulate clearly and precisely why i don't think it's a good idea.
*shrug*, just a different outlook, patching userspace instead of kernel space
it'll likely be something to do with your solution being a two-step operation whereas the hacked-up-relaxed-fscontext-hooks.c things is a one-step (atomic?) operation.
kernel developers will very much not like to get patches unless for a very good reason... *shrug*... guess i have the totally oposite outlook than you, i've had quite a number of my patches go mainstream though
l.
-Nigel
On Tue, Aug 31, 2004 at 06:46:35PM +0200, Nigel Kukard wrote:
assuming yes, then it kinda-solves the need for doing that hacked-up relaxed-constraints-patch-to-hooks.c fscontext= option.
aha, u correct!!!!
why? because you can mount -t tmpfs /dev blah blah and you don't care what the context is because udev will set the correct one when it runs.
perfect!!!!, so that solves the need for the hooks patch, which is in actual fact wrong.
oh, is it? uhm, why?
that is - of course - assuming that file_contexts/file_contexts _contains_ the correct file context for /dev.
*nod*
it might make (i dunno) for a simpler policy.
yep
i _say_ might ... but then you mention that you've done exactly the same policy mods that i had to...
what i mean is, have you had to add in the modifications to the selinux policy that i sent to the lists last week?
e.g. these:
allow udev_tbl_t device_t:filesystem { associate }; allow initctl_t device_t:filesystem { associate };
and these:
+# needed for udev-mounted (/dev) tmpfs +allow $1_tty_device_t device_t:filesystem { associate }; + +# to allow users to run df on udev-mounted (/dev) tmpfs +allow $1_t device_t:filesystem { getattr }; + #EXE=/bin/df NAME=/ : getattr +
had to add quite a couple more, but i'm still working on that to make it "correct"
i think we need the input of more experienced people than us to say why these associate things are needed.
these are all there for reasons i cannot entirely fathom but it starts, in types/file.te, with this:
allow { device_type } device_t:filesystem associate;
i need this aswell.... which is very interesting, so my "way of doing it" doesn't solve this problem. i'll keep looking for the solution
which is all because of this:
mount tmpfs -o fscontext=system_u:object_r:device_t /dev
this doesn't cause the problem, its something else
anyway what i am saying is that if you HAVE NOT got all these patches in your selinux policy files, then your approach has distinct advantages: less mods to the policy files and less differences between a persistent and non-persistent udev filesystem.
correct, i'm still working on it though and it HAS TO BE COMPLETED SOON!!!!
ah, the joys of the "ItWorksForMe(tm)" approach...
other than that, my intuition is saying "i don't like it" and what that means is that in about two or three weeks i will be able to articulate clearly and precisely why i don't think it's a good idea.
*shrug*, just a different outlook, patching userspace instead of kernel space
it'll likely be something to do with your solution being a two-step operation whereas the hacked-up-relaxed-fscontext-hooks.c things is a one-step (atomic?) operation.
kernel developers will very much not like to get patches unless for a very good reason...
a correct implementation of the hacked-together-relaxed-fscontext-hooks.c-patch results in an atomic operation (mount with a new context which would otherwise need to be achieved with two commands: mount followed by restorecon)
in my books, that's a good reason!
*shrug*... guess i have the totally oposite outlook than you, i've had quite a number of my patches go mainstream though
dude, the entire selinux thing is disliked by stacks of debian maintainers because of the knock-on implications it has.
imagine what chaos would ensue if up until now, linux only had a FAT filesystem and someone said "hey, there's this _great_ concept it's called file ownership and file permissions, i've invented something called an ext2 filesystem".
l.
On Tue, 2004-08-31 at 15:18, Luke Kenneth Casson Leighton wrote:
i think we need the input of more experienced people than us to say why these associate things are needed.
It provides control over the set of files that can live in a given filesystem, based on their security types (equivalence classes). As you are now creating device types in a different filesystem type, further allow rules are needed to allow that association.
a correct implementation of the hacked-together-relaxed-fscontext-hooks.c-patch results in an atomic operation (mount with a new context which would otherwise need to be achieved with two commands: mount followed by restorecon)
The more important issue is that fscontext= lets you set the superblock security context, not just the root directory context. restorecon can't do that.
On Tue, Aug 31, 2004 at 03:26:43PM -0400, Stephen Smalley wrote:
On Tue, 2004-08-31 at 15:18, Luke Kenneth Casson Leighton wrote:
i think we need the input of more experienced people than us to say why these associate things are needed.
It provides control over the set of files that can live in a given filesystem, based on their security types (equivalence classes). As you are now creating device types in a different filesystem type, further allow rules are needed to allow that association.
a correct implementation of the hacked-together-relaxed-fscontext-hooks.c-patch results in an atomic operation (mount with a new context which would otherwise need to be achieved with two commands: mount followed by restorecon)
The more important issue is that fscontext= lets you set the superblock security context, not just the root directory context. restorecon can't do that.
ah.
thanks for clarifying, steven.
l.
This should be of great assistance with two home projects currently and 1 work project due to the filesystem types. I am still working through size issues and further locking down the images.
Project 1 = SE Linux image for Netgear MR314 Wireless Lan Router Project 2 = SE Linux image for Cisco 2501 Router Project 3 = Debian Sarge Server build on SGI Octane with reiserfs ( Work for Network Management Server )
Thanks, Jim McCullough
On Tue, 31 Aug 2004 21:02:10 +0100, Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
On Tue, Aug 31, 2004 at 03:26:43PM -0400, Stephen Smalley wrote:
On Tue, 2004-08-31 at 15:18, Luke Kenneth Casson Leighton wrote:
i think we need the input of more experienced people than us to say why these associate things are needed.
It provides control over the set of files that can live in a given filesystem, based on their security types (equivalence classes). As you are now creating device types in a different filesystem type, further allow rules are needed to allow that association.
a correct implementation of the hacked-together-relaxed-fscontext-hooks.c-patch results in an atomic operation (mount with a new context which would otherwise need to be achieved with two commands: mount followed by restorecon)
The more important issue is that fscontext= lets you set the superblock security context, not just the root directory context. restorecon can't do that.
ah.
thanks for clarifying, steven.
l.
-- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.
well, the patch is at um.. oh no it's not... um, hang on... yep, it's _now_ at http://hands.com/~lkcl/selinux/selinux-hooks.patch
On Tue, Aug 31, 2004 at 05:18:05PM -0400, Jim McCullough wrote:
This should be of great assistance with two home projects currently and 1 work project due to the filesystem types. I am still working through size issues and further locking down the images.
Project 1 = SE Linux image for Netgear MR314 Wireless Lan Router Project 2 = SE Linux image for Cisco 2501 Router Project 3 = Debian Sarge Server build on SGI Octane with reiserfs ( Work for Network Management Server )
The more important issue is that fscontext= lets you set the superblock security context, not just the root directory context. restorecon can't do that.
On Tue, Aug 31, 2004 at 08:18:10PM +0100, Luke Kenneth Casson Leighton was heard to remark:
dude, the entire selinux thing is disliked by stacks of debian maintainers because of the knock-on implications it has.
Totally off-topic remark, unrelated to anything, but I'm waiting for somethig to compile :)
Every now and then, I look at SELinux, and I get scared away by its complexity. This complexity makes it very hard to audit, and assure oneself that its actually providing any real security, as opposed to the illusion of security. During this email thread, there are references to mysterious rules that neither party in the conversation fully understands; this scares me.
Compare this to less complex security provided by e.g. the Linux VServer project. VServer is intended to allow an ISP to pretend they have a rack of 100 cpu's all running linux, when in fact they have just one. The fact that it provides security is a side-effect; but its far simpler, far easier to audit, and allows me to sleep at night.
Another example: Way back in the kernel-2.2 timeframe, I hacked on something neat: 'LOMAC': if you came in from a network connection, you lost permission to do almost anything, other than to e.g. webserve. The system was simple, worked well, the kernel patches were easy to audit, you could go home without worrying about priveledge escalation.
Compare that to this thread, where we are talking about atomic vs. non-atomic restoration of context for udev-mounted temp file systems. Shudder. This seems to be begging for an exploit to be discovered. Are we sure that SELinux is really on the right track here?
--linas
On Tue, 31 Aug 2004, Linas Vepstas wrote:
Every now and then, I look at SELinux, and I get scared away by its complexity. This complexity makes it very hard to audit, and assure oneself that its actually providing any real security, as opposed to the illusion of security. ...
Tough questions. Good questions! Still, I do believe MAC has value in contrast to DAC. But the opposing "flying buttress" to this is that it all boils down to binary ... somewhere. And is THAT part isolated?
Compare this to less complex security provided by e.g. the Linux VServer project. VServer is intended to allow an ISP to pretend they have a rack of 100 cpu's all running linux, when in fact they have just one. The fact that it provides security is a side-effect; but its far simpler, far easier to audit, and allows me to sleep at night.
Ahhh... virtual machines. (And I don't mean Java.) I'm thinking VMware and (esp) z/VM (IBM style mainframe). Been using both or years, VMware since 1.0 beta and mainframe since ... well ... I was pretty young at the time. But not for security per-se, they have other interesting features. Linas' mention of VServer and its side-effect security reminds me of something I read in the anals of VM hisory:
http://vm.marist.edu/~vmshare/browse?fn=VMHIST07&ft=NOTE
(Stephen, Howard, and the rest and friends at the NSA please take no offense. I found this terribly entertaining.) Even from its earliest days, VM (CP) isolated each user, so:
"On another occasion we almost had an in-house protest. Among the early users of CP-67/CMS were both the National Security Agency and the CIA; the fact that the DAT hardware isolated each user in his own address space was viewed as a powerful system security feature. One time in 1970, I think, the CIA sent two of their people to Cambridge to talk about something that Ed Hendricks had developed or was working on. In the atmosphere of the time, none of the technical people at CSC, especially Ed, wanted to talk to them at all! Ed stormed around the halls muttering "damned spooks!" for half an hour or more before Craig Johnson and Norm Rasmussen were able to coerce him into the meeting. Even more amazing is that they were spooks; there was a man and a woman, both of slightly below-average height, average build, average everything! You could stand and talk directly to them or study them for five minutes or more, but if you turned around there was nothing to remember and nothing to describe; they were effectively invisible."
Thanks to Lynn Wheeler for helping me dig this up.
-- R;
[ The CC list here is rather nuts, someone needs to trim it...]
On Tue, 2004-08-31 at 17:44 -0500, Linas Vepstas wrote:
Every now and then, I look at SELinux, and I get scared away by its complexity.
It is actually not that complicated, but if you're unfamiliar with mandatory access control (as I was when I first started learning about SELinux), it does require understanding some theory before you dive in.
This complexity makes it very hard to audit, and assure oneself that its actually providing any real security, as opposed to the illusion of security. During this email thread, there are references to mysterious rules that neither party in the conversation fully understands; this scares me.
Because two people in a thread don't understand SELinux, that means that it's too complex? I can certainly find plenty of examples of people not understanding Linux on linux-kernel; does that imply Linux is too complex?
Compare this to less complex security provided by e.g. the Linux VServer project. VServer is intended to allow an ISP to pretend they have a rack of 100 cpu's all running linux, when in fact they have just one.
VServer isn't solving the same problem as SELinux. VServer is really a virtualization solution. For example, it would make sense to run *both* a virtualization solution like VServer (or Xen, which looks more promising), and SELinux at the same time. That way, if e.g. the bind daemon running in one of the virtualized servers gets cracked, it doesn't mean a compromise of the whole virtual server.
Now, you can use a virtualization technology as a primitive form of separation by running e.g. your MTA in one virtual server, your name server in another, etc. But that's rather painful, and is only an approximation to least privilege.
Another example: Way back in the kernel-2.2 timeframe, I hacked on something neat: 'LOMAC': if you came in from a network connection, you lost permission to do almost anything, other than to e.g. webserve. The system was simple, worked well, the kernel patches were easy to audit, you could go home without worrying about priveledge escalation.
That's also a rather blunt tool; SELinux is much more flexible.
Compare that to this thread, where we are talking about atomic vs. non-atomic restoration of context for udev-mounted temp file systems. Shudder. This seems to be begging for an exploit to be discovered.
I doubt it. Files created in /dev should have a default type like device_t which most domains will not have access to.
Are we sure that SELinux is really on the right track here?
Given the amount of research behind SELinux, and the amount of work being done on it, I think so, yes.
On Wed, Sep 01, 2004 at 10:29:34AM -0400, Colin Walters was heard to remark:
[ The CC list here is rather nuts, someone needs to trim it...]
On Tue, 2004-08-31 at 17:44 -0500, Linas Vepstas wrote:
Every now and then, I look at SELinux, and I get scared away by its complexity.
It is actually not that complicated, but if you're unfamiliar with mandatory access control (as I was when I first started learning about SELinux), it does require understanding some theory before you dive in.
Hmm, I thought I understood MAC; I was refering to the large numbers of rules in SELinux. Its not obvious (to me) that there isn't a path through those rules that allows privledge escalation.
For example: and correct me if I'm wrong, but its quite possible to write a complex rule set that intentionally leaves 'holes' allowing for priveledge escalation. Thus, by extrapolation, its quite possible to write a set of rules that accidentally do the same. When one is presented with a set of rules, how does one know that they don't have a hole? Answer: one audits the rules. Unfortunately, there are a lot of rules: last time I looked at one of the config files, it was thousands of lines long. Thus, a short, simple audit performed by one person seems out of the question.
Now, as to auditing...
it's too complex? I can certainly find plenty of examples of people not understanding Linux on linux-kernel; does that imply Linux is too complex?
We've had a fair number of "eyeballs" read the linux kernel, and thus base our trust in its security on that. However, the SELinux rules are unlike the kernel in an important way: they are config files. This allows allows some anonymous fedora/debian/gentoo maintainer to do something dumb like "gee, my USB camera doesn't work with udev, but then when I change this selinux rule, it does", and poof, you've lost the security. I'm presuming that this kind of mucking around is far more common than altering lines of source in the kernel that weaken security. But I base my presumption on real life: go to any LUG, hang out with any sysadmin long enough, and you will see them make changes to config files that are dangerous if not outright incorrect. Sysadmins are, as a species, people who work with incomplete knowledge of the systems they administer.
Compare this to less complex security provided by e.g. the Linux VServer project.
VServer isn't solving the same problem as SELinux.
Yes, that's right. I did try to point that out ...
That way, if e.g. the bind daemon running in one of the virtualized servers gets cracked, it doesn't mean a compromise of the whole virtual server.
No... If the bind deamon gets cracked, it doesn't compromise the 'whole'; it only compromises root and anything else running in that context. It does not (in theory) compromise root in the other contexts. In other words, one of the servers could be 0wned by someone truly hostile, while the 'whole' remains (theoretically) safe.
Now, you can use a virtualization technology as a primitive form of separation by running e.g. your MTA in one virtual server, your name server in another, etc. But that's rather painful, and is only an approximation to least privilege.
Yes, this is exactly what I'm thinking of. But its not painful, it solves 90% or 100% of the needs of a 'typical' ISP/ASP/web server admin. Yes, this is indeed a blunt tool... see below:
Another example: Way back in the kernel-2.2 timeframe, I hacked on something neat: 'LOMAC': if you came in from a network connection, you lost permission to do almost anything, other than to e.g. webserve. The system was simple, worked well, the kernel patches were easy to audit, you could go home without worrying about priveledge escalation.
That's also a rather blunt tool; SELinux is much more flexible.
What I'm proposing here is that bluntness can be traded for increased assurances and increased ability to audit the code for "correctness". Yes, SELinux is far more flexible; but this is exactly what scares me.
I once thought about re-implementing LoMAC as a ruleset atop of SELinux. I'm pretty sure that this is possible, but I started thinking that the complexity of the ruleset may introduce holes that voids the effort. And that thought disturbed me.
Along with Lomac's 'bluntness' comes 'zero configurability': its something that could be installed on the proverbial 'Grandma's Linux desktop', and provide additional security without causing pain.
With selinux, its not only not zero-conf, but its also not clear (to me) if the rulesets that install with debian/fedora/etc. actually provide any additonal security at all against network breakins. If the rulesets do indeed provide this protection, then there is a perception/marketing problem: people like me "don't get it" from just skimming the selinux web pages. I'd prefer to get all the benefits of SELinux without having to RTFM.
--linas
Linas Vepstas linas-at-austin.ibm.com |fedora| wrote:
Its not obvious (to me) that there isn't a path through those rules that allows privledge escalation.
Unfortunately, there are a lot of rules: last time I looked at one of the config files, it was thousands of lines long. Thus, a short, simple audit performed by one person seems out of the question.
Has anyone been working on a graphical representation to the rules and current labeling for visualizing a rulebase/system/runtime configuration? It seems to me that for Fedora/SELinux to go mainstream some form of a visual auditing tool would be required. Being able to take some entity such as a file system or running process and visually displaying the access permissions in the context of privileges granted to a user or process would go a long way towards SE's mainstream adoption. If such a tool were to also help the admin rewrite the rules based on changes to entities while walking down the directory tree it would put SELinux in a much better position for the average admin. Of course such a tool would require careful though in the design due to the desired separation of duties (e.g. auditing vs. administration privs) and the rule definition v.s. Application thereof v.s. the runtime contexts for a given user/process.
I have to admit that I have been merely lurking here for a while and have not yet installed SELinux on anything as of yet. My “lurking” rather than “doing” is due mostly to my time limitations, and the thought of making my system unusable for my real work because I would have no way to understand all the rules in such short order. If I could see the effects of making a given change (e.g. color coding, symbolic representation) to the system before actually applying that change (relabeling) then I would be much less hesitant to convert everything over to FC2/3 with SELinux as my primary reason for migrating. From what I can see so far SELinux is great stuff, and I praise everyone working on it for such dedicated work! Thanks to all.
On Wed, 2004-09-01 at 13:25, Linas Vepstas wrote:
Hmm, I thought I understood MAC; I was refering to the large numbers of rules in SELinux. Its not obvious (to me) that there isn't a path through those rules that allows privledge escalation.
For example: and correct me if I'm wrong, but its quite possible to write a complex rule set that intentionally leaves 'holes' allowing for priveledge escalation. Thus, by extrapolation, its quite possible to write a set of rules that accidentally do the same. When one is presented with a set of rules, how does one know that they don't have a hole? Answer: one audits the rules. Unfortunately, there are a lot of rules: last time I looked at one of the config files, it was thousands of lines long. Thus, a short, simple audit performed by one person seems out of the question.
The complexity of the rules reflect the complexity of the existing Linux system and its interactions; SELinux didn't introduce that complexity - SELinux just enables you to control what happens in that complex system. No criticism intended of Linux; the same would apply to any mainstream operating system, and the complexity just reflects real world requirements. And you do have the option of reducing the visible complexity based on your security goals; if you don't care about the interactions among a set of processes/resources, you fold the domain and type space accordingly. The targeted policy is an example of doing that to an extreme.
Analysis of that complexity _does_ require automated tools, and such tools exist. apol (yum install setools setools-gui) provides support for analysis, including domain transitions and information flow. slat (available from the NSA SELinux site or MITRE) does security goal checking using a model checker. Gokyo from IBM Watson (which AFAIK is unfortunately not released publically yet, perhaps you could encourage that to happen) analyzes against Biba integrity constraints and identifies exceptions for further examination.
However, the SELinux rules are unlike the kernel in an important way: they are config files. This allows allows some anonymous fedora/debian/gentoo maintainer to do something dumb like "gee, my USB camera doesn't work with udev, but then when I change this selinux rule, it does", and poof, you've lost the security.
The policy maintainers for the various distros are not anonymous and appear to take their work quite seriously; rejecting policy changes despite a reduction in functionality is not uncommon. You seem to be assuming that policy for each package is maintained by the individual package maintainers; that isn't the case, and likely never will be. Ditto for sysadmins; most of them should never touch policy at all.
What I'm proposing here is that bluntness can be traded for increased assurances and increased ability to audit the code for "correctness". Yes, SELinux is far more flexible; but this is exactly what scares me.
Reality is complex. Deal with it. Being confident in the correctness of an inadequate security model doesn't help much.
I once thought about re-implementing LoMAC as a ruleset atop of SELinux. I'm pretty sure that this is possible, but I started thinking that the complexity of the ruleset may introduce holes that voids the effort. And that thought disturbed me.
It isn't actually possible to implement LOMAC via SELinux, but that's another topic.
Along with Lomac's 'bluntness' comes 'zero configurability': its something that could be installed on the proverbial 'Grandma's Linux desktop', and provide additional security without causing pain.
Until Grandma wants to do useful work. Simple security models are nice to look at, but they don't capture the behavior of real systems, and it doesn't matter that the model is "secure"; you just break one of the trusted subjects authorized to override the security model in order to get the real work done. SELinux policy may look weaker to you, but it actually represents what is being allowed in the system; no exceptions.
-----Original Message----- From: fedora-selinux-list-bounces@redhat.com [mailto:fedora-selinux-list-bounces@redhat.com] On Behalf Of Stephen Smalley Sent: Thursday, September 02, 2004 11:11 AM To: Fedora SELinux support list for users & developers. Cc: linux-hotplug-devel@lists.sourceforge.net; SELinux; Bill Nottingham; Colin Walters; Nigel Kukard; harald@redhat.com Subject: Re: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]
On Wed, 2004-09-01 at 13:25, Linas Vepstas wrote:
Hmm, I thought I understood MAC; I was refering to the large numbers of rules in SELinux. Its not obvious (to me) that there isn't a path through those rules that allows privledge escalation.
For example: and correct me if I'm wrong, but its quite possible to write a complex rule set that intentionally leaves 'holes' allowing for priveledge escalation. Thus, by extrapolation, its quite possible to write a set of rules that accidentally do the same. When one is presented with a set of rules, how does one know that they don't have a hole? Answer: one audits the rules. Unfortunately, there are a lot of rules: last time I looked at one of the config files, it was thousands of lines long. Thus, a short, simple audit performed by one person seems out of the question.
The complexity of the rules reflect the complexity of the existing Linux system and its interactions; SELinux didn't introduce that complexity - SELinux just enables you to control what happens in that complex system. No criticism intended of Linux; the same would apply to any mainstream operating system, and the complexity just reflects real world requirements. And you do have the option of reducing the visible complexity based on your security goals; if you don't care about the interactions among a set of processes/resources, you fold the domain and type space accordingly. The targeted policy is an example of doing that to an extreme.
Analysis of that complexity _does_ require automated tools, and such tools exist. apol (yum install setools setools-gui) provides support for analysis, including domain transitions and information flow. slat (available from the NSA SELinux site or MITRE) does security goal checking using a model checker. Gokyo from IBM Watson (which AFAIK is unfortunately not released publically yet, perhaps you could encourage that to happen) analyzes against Biba integrity constraints and identifies exceptions for further examination.
However, the SELinux rules are unlike the kernel in an important way: they are config files. This allows allows some anonymous fedora/debian/gentoo maintainer to do something dumb like "gee, my USB camera doesn't work with udev, but then when I change this selinux rule, it does", and poof, you've lost the security.
The policy maintainers for the various distros are not anonymous and appear to take their work quite seriously; rejecting policy changes despite a reduction in functionality is not uncommon. You seem to be assuming that policy for each package is maintained by the individual package maintainers; that isn't the case, and likely never will be. Ditto for sysadmins; most of them should never touch policy at all.
What I'm proposing here is that bluntness can be traded for increased assurances and increased ability to audit the code for "correctness". Yes, SELinux is far more flexible; but this is exactly what scares me.
Reality is complex. Deal with it. Being confident in the correctness of an inadequate security model doesn't help much.
I once thought about re-implementing LoMAC as a ruleset atop of SELinux. I'm pretty sure that this is possible, but I started thinking that the complexity of the ruleset may introduce holes that voids the effort. And that thought disturbed me.
It isn't actually possible to implement LOMAC via SELinux, but that's another topic.
Along with Lomac's 'bluntness' comes 'zero configurability': its something that could be installed on the proverbial 'Grandma's Linux desktop', and provide additional security without causing pain.
Until Grandma wants to do useful work. Simple security models are nice to look at, but they don't capture the behavior of real systems, and it doesn't matter that the model is "secure"; you just break one of the trusted subjects authorized to override the security model in order to get the real work done. SELinux policy may look weaker to you, but it actually represents what is being allowed in the system; no exceptions.
Hi Stephen,
Excellent answer... its been too long since I've played with selinux. I'll try again.
I once thought about re-implementing LoMAC as a ruleset atop of SELinux. I'm pretty sure that this is possible, but I started thinking that the complexity of the ruleset may introduce holes that voids the effort. And that thought disturbed me.
It isn't actually possible to implement LOMAC via SELinux, but that's another topic.
Hmm, why not?
Along with Lomac's 'bluntness' comes 'zero configurability': its something that could be installed on the proverbial 'Grandma's Linux desktop', and provide additional security without causing pain.
Until Grandma wants to do useful work. Simple security models are nice to look at, but they don't capture the behavior of real systems, and it doesn't matter that the model is "secure"; you just break one of the trusted subjects authorized to override the security model in order to get the real work done. SELinux policy may look weaker to you, but it actually represents what is being allowed in the system; no exceptions.
I don't quite understand this. I'm currently running Lomac on one of my servers, and I can get work done. It seems to be usable, even if it makes some operations, like software install, harder.
I'm not sure what you mean by 'break a trusted subject'. If you mean 'ssh is trusted, so if ssh is broken, all hope is lost', then yes. But surely selinux has trusted subjects that may not be trustworthy?
If you mean 'lomac provides explicit tools that allow a sysadmin to manually move a file from lower to higher trust domains', then, well, I'm also confused. Surely selinux also has a way to start with something untrusted, and then raise its level ... e.g. to install software downloaded from the net.
Is the 'broken-ness' the fact that grandma failed to run an anti-virus scanner and verify checksums, yada yada, before elevating the priveldge on the downloaded software?
--linas
On Thu, Sep 02, 2004 at 12:29:07PM -0500, Linas Vepstas wrote:
Is the 'broken-ness' the fact that grandma failed to run an anti-virus scanner and verify checksums, yada yada, before elevating the priveldge on the downloaded software?
[this is all with the strict policy 1.14 mostly sortof btw]
i've installed clamav, spamassassin, razor and pyzor.
oh, and freshclam.
i then found a little script called clamassassin [google], i then searched [google] for some advice on how to set up kmail filters.
kmail, the clamassassin script and spamc all run under the user context.
the user context is given the right to bind to servers.
spamd and clamd both run as servers: they have their own policies that restrict their operation to what is known that they presently do, but they are allowed to listen to incoming requests [from spamc and the clamassassin script respectively.]
selinux doesn't in the _slightest_ bit get in the way.
the only thing that i did find is that razor is a complete pain.
it endeavours to write log files into /root/razor.log, /tmp/razor.log, /razor.log, it's a pain, and selinux is _exactly_ the sort of thing that can detect - and stop! - this behaviour.
pyzor appears to be a lot less haphazard.
also nobody else appears to have tried to run freshclam [automatic update script] before now, so i had to hack the clamav.te policy a bit to get it to run.
l.
On Wed, 1 Sep 2004 08:44, Linas Vepstas linas@austin.ibm.com wrote:
Every now and then, I look at SELinux, and I get scared away by its complexity. This complexity makes it very hard to audit, and assure
What auditing are you referring to? Kernel code, application code, or policy?
The application code is not overly complex. The kernel code is as good as such code can be. Tresys http://www.tresys.com/ are developing tools for auditing SE Linux policy.
oneself that its actually providing any real security, as opposed to the illusion of security. During this email thread, there are references to mysterious rules that neither party in the conversation fully understands; this scares me.
Which mysterious rules are you referring to?
Compare that to this thread, where we are talking about atomic vs. non-atomic restoration of context for udev-mounted temp file systems. Shudder. This seems to be begging for an exploit to be discovered. Are we sure that SELinux is really on the right track here?
The original udev implementation had the device nodes relabelled after creation. As of recent times (since 2002) the default SE Linux policy has denied almost all domains (only two system domains) access to device nodes labelled as device_t. This means that there is no window of opportunity for an attacker to access a device before it is correctly labelled.
The worst race condition attack would be a DOS attack, cause an access at the wrong time and have it be denied when otherwise it would be permitted. This is the least serious of all possible problems related to device labelling.
On Thu, Sep 02, 2004 at 10:15:20PM +1000, Russell Coker was heard to remark:
On Wed, 1 Sep 2004 08:44, Linas Vepstas linas@austin.ibm.com wrote:
Every now and then, I look at SELinux, and I get scared away by its complexity. This complexity makes it very hard to audit, and assure
What auditing are you referring to? Kernel code, application code, or policy?
policy.
oneself that its actually providing any real security, as opposed to the illusion of security. During this email thread, there are references to mysterious rules that neither party in the conversation fully understands; this scares me.
Which mysterious rules are you referring to?
I wasn't refering to them, the posters to the thread were. Unfortunately, I've already deleted those emails.
labelled as device_t. This means that there is no window of opportunity for an attacker to access a device before it is correctly labelled.
OK.
Well, here's another idle question, again off-topic: Does SELinux provide any sort of assurances that storage media weren't tampered with between reboots?
For example, with BIOS/firmware getting more sophisticated over time, there's potential for an attacker to break in, remotely, into bios/firmware, shortly before booting into the OS, and then alter disk contents. Yes, I know this is far-fetched, but was just curious.
What got me going on that thread was thinking about udev/hotplug again: with devices coming and going, disappearing and re-appearing, it isn't obvious that there wasn't tampering while the device was gone.
Again, excuse me if this sounds naive, un-informed or far-fetched, or terribly off-topic, but: In ye olden days, viruses spread through diskettes. These days, we're plugging-n-playing usb keychains, cameras, ipods, bluetooth this-n-that; although I haven't heard of attacks carried out through these media, its not obivious that these couldn't be carriers for an attack.
--linas
On Fri, 3 Sep 2004 03:07, Linas Vepstas linas@austin.ibm.com wrote:
Well, here's another idle question, again off-topic: Does SELinux provide any sort of assurances that storage media weren't tampered with between reboots?
No, that is outside the scope of the SE Linux project.
I am one of the many people in Red Hat who are involved in working on crypto block device support. One of my own systems has a root file system that is AES encrypted with the kernel and initrd (which includes the decryption key) on removable media. Eventually I want to see this become a standard feature of Fedora, maybe in FC4. I think it will address most of what you want in this regard.
Note that the NSA guys do not talk to me about any security stuff, so I don't expect them to have any involvement in such things.
For example, with BIOS/firmware getting more sophisticated over time, there's potential for an attacker to break in, remotely, into bios/firmware, shortly before booting into the OS, and then alter disk contents. Yes, I know this is far-fetched, but was just curious.
When booting from removable media that contains the decryption key the attack scenario would be to replace the BIOS with one that sends everything it reads from disk (IE everything that the boot loader reads) over an Ethernet interface.
A trojan BIOS that modifies the kernel during the boot load process to introduce a security hole would be doable if you have adequate resources.
Russell Coker wrote:
When booting from removable media that contains the decryption key the attack scenario would be to replace the BIOS with one that sends everything it reads from disk (IE everything that the boot loader reads) over an Ethernet interface.
A trojan BIOS that modifies the kernel during the boot load process to introduce a security hole would be doable if you have adequate resources.
there is a second option (also bios and startup related):
you can put an additional pci-extension-bios to any pci-card which have a own pci-extension-bios for setting up its hardware, the chips are usaly 64k but not fully used (graficcard, networkcard, ...) and the point is, the standard allows you to put several pci-extension-bios-images into one of such eeproms which just point to each other and get called through the main-bios
so its not really necessary to exchange the system bios, get your hands on a pci-card with a extension-bios may be enough... so keep your eyes open if you change hardware ;)
and this is working practical, i have written a pci-extension-bios which actuly was sitting at (in this case) the network card for reading/setting bios-settings (nvram) during boot-up process at the serial port some years ago (was for some semiautomatic setting up process of 'black-box' hardware with no keyboard monitors attached to it) ok - second problem here, would be getting the code surviving in ram the boot-up sequence of the operating system, but i'm sure this won't be any problem for some ppl with the necessary skills
i'm not sure about the pci-x-standard, but i think this could be working similar
greetings dalini
Russell Coker wrote:
When booting from removable media that contains the decryption key the attack scenario would be to replace the BIOS with one that sends everything it reads from disk (IE everything that the boot loader reads) over an Ethernet interface.
A trojan BIOS that modifies the kernel during the boot load process to introduce a security hole would be doable if you have adequate resources.
there is a second option (also bios and startup related):
you can put an additional pci-extension-bios to any pci-card which have a own pci-extension-bios for setting up its hardware, the chips are usaly 64k but not fully used (graficcard, networkcard, ...) and the point is, the standard allows you to put several pci-extension-bios-images into one of such eeproms which just point to each other and get called through the main-bios
so its not really necessary to exchange the system bios, get your hands on a pci-card with a extension-bios may be enough... so keep your eyes open if you change hardware ;)
and this is working practical, i have written a pci-extension-bios which actuly was sitting at (in this case) the network card for reading/setting bios-settings (nvram) during boot-up process at the serial port some years ago (was for some semiautomatic setting up process of 'black-box' hardware with no keyboard monitors attached to it) ok - second problem here, would be getting the code surviving in ram the boot-up sequence of the operating system, but i'm sure this won't be any problem for some ppl with the necessary skills
i'm not sure about the pci-x-standard, but i think this could be working similar
greetings dalini
On Sat, 4 Sep 2004 20:54, Ives Steglich fedora-se-linux@dalini.de wrote:
there is a second option (also bios and startup related):
you can put an additional pci-extension-bios to any pci-card which have a own pci-extension-bios for setting up its hardware, the chips are usaly 64k but not fully used (graficcard, networkcard, ...) and the
Good point. However one limitation of this is that it won't work so well for laptops.
The idea of replacing a BIOS was first suggested to me after a discussion of an advertised security product which had some very suspect claims about it's performance. The claim that it could survive a re-install of Windows seemed difficult to believe and a modified BIOS was the only suggestion of a possible way of doing it.
second problem here, would be getting the code surviving in ram the boot-up sequence of the operating system, but i'm sure this won't be any problem for some ppl with the necessary skills
That is solvable too. It would have to decompress the kernel image, modify the kernel code in some subtle way (EG making some security check function in the kernel be a noop), re-compress the kernel image and then present it to the boot loader upon read requests. It's difficult, but not impossible.
On Thu, Sep 02, 2004 at 10:15:20PM +1000, Russell Coker wrote:
Compare that to this thread, where we are talking about atomic vs. non-atomic restoration of context for udev-mounted temp file systems. Shudder. This seems to be begging for an exploit to be discovered. Are we sure that SELinux is really on the right track here?
The original udev implementation had the device nodes relabelled after creation. As of recent times (since 2002) the default SE Linux policy has denied almost all domains (only two system domains) access to device nodes labelled as device_t. This means that there is no window of opportunity for an attacker to access a device before it is correctly labelled.
The worst race condition attack would be a DOS attack, cause an access at the wrong time and have it be denied when otherwise it would be permitted. This is the least serious of all possible problems related to device labelling.
... and with the use of matchpathcon() followed by setfscreatecon(), it isn't even that: inode, symlink and directory creation-plus-filecontext-setting are done as an atomic operation.
problem goes away.
the _old_ selinux udev support (0.024), on the other hand, suffered from the big-deal-DOS-attack that russell describes above.
l.
selinux@lists.fedoraproject.org