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.