udev and .dev...

udev and .dev...

[Luke Kenneth Casson Leighton]

dear selinux people,

ah ha!  okay, the reason why my hard drive was inaccessible
is because /.dev/* had all been set to default_t :)

soooo... to fix that [rather than a patch, a sed command]:

	:%s/u?dev/.?u?dev/g

this will allow setfiles to set up the security contexts on
the /.dev which is the _real_ filesystem /dev stuff which will
allow things like, oh, init (!!) to access the hard drive.

argh :)

l.

-- 
-- 
Information I post is with honesty, integrity, and the expectation that
you will take full responsibility if acting on the information contained,
and that, should you find it to be flawed or even mildly useful, you
will act with both honesty and integrity in return - and tell me.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />


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

Re: udev and .dev...

[Joshua Brindle]

Luke Kenneth Casson Leighton wrote:

>dear selinux people,
>
>ah ha!  okay, the reason why my hard drive was inaccessible
>is because /.dev/* had all been set to default_t :)
>
>soooo... to fix that [rather than a patch, a sed command]:
>
>	:%s/u?dev/.?u?dev/g
>
>this will allow setfiles to set up the security contexts on
>the /.dev which is the _real_ filesystem /dev stuff which will
>allow things like, oh, init (!!) to access the hard drive.
>
>argh :)
>
>l.
>
>  
>
Why not have a minimal /dev for init and friends and mount the ramfs for 
udev on top of it? it's much easier to deal with 1 /dev and this is 
pretty standard anyway.

Joshua

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

Re: udev and .dev...

[Luke Kenneth Casson Leighton]

On Thu, Jul 29, 2004 at 08:32:53AM -0400, Joshua Brindle wrote:
> Luke Kenneth Casson Leighton wrote:
> 
> >dear selinux people,
> >
> >ah ha!  okay, the reason why my hard drive was inaccessible
> >is because /.dev/* had all been set to default_t :)
> >
> >soooo... to fix that [rather than a patch, a sed command]:
> >
> >	:%s/u?dev/.?u?dev/g
> >
> >this will allow setfiles to set up the security contexts on
> >the /.dev which is the _real_ filesystem /dev stuff which will
> >allow things like, oh, init (!!) to access the hard drive.
> >
> >argh :)
> >
> >l.
> >
> > 
> >
> Why not have a minimal /dev for init and friends and mount the ramfs for 
> udev on top of it? it's much easier to deal with 1 /dev and this is 
> pretty standard anyway.
 
 i'm getting from here to there in the minimal amount of time: if i
 find something that works, i leave it as it is.

 remember that i'm trying to hack up a standard debian/unstable system
 to do se/linux, where the focus is on making it as easy for users
 as possible.
 
 (hence usb-mount, hence udev, hence patching the kernel)

 i can always fix it later: it works for now, next thing on the list...
 
 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.

Re: udev and .dev...

[Ian Campbell]

On Thu, 2004-07-29 at 13:32, Joshua Brindle wrote:
> Why not have a minimal /dev for init and friends and mount the ramfs for 
> udev on top of it? it's much easier to deal with 1 /dev and this is 
> pretty standard anyway.

I believe what happens is that the on disk dev does live at /dev and the
udev initscript bind mounts it to /.dev before mounting the rams over
the top so that you can still get at the on disk version.

An excerpt from the Debian udev initscript:
  # /.dev is used by /sbin/MAKEDEV to access the real /dev directory.
  # if you don't like it just remove it.
  [ -d /.dev ] && mount --bind /dev /.dev

  echo -n "Mounting a tmpfs over /dev..."
  mount -n -o size=$tmpfs_size,mode=0755 -t tmpfs none /dev
  echo "done."

Ian.


-- 
Ian Campbell
Current Noise: Faith No More - Woodpecker From Mars

I must get out of these wet clothes and into a dry Martini.
		-- Alexander Woolcott


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

Re: udev and .dev...

[Luke Kenneth Casson Leighton]

On Thu, Jul 29, 2004 at 03:14:11PM +0100, Ian Campbell wrote:
> On Thu, 2004-07-29 at 13:32, Joshua Brindle wrote:
> > Why not have a minimal /dev for init and friends and mount the ramfs for 
> > udev on top of it? it's much easier to deal with 1 /dev and this is 
> > pretty standard anyway.
> 
> I believe what happens is that the on disk dev does live at /dev and the
> udev initscript bind mounts it to /.dev before mounting the rams over
> the top so that you can still get at the on disk version.
 
  presumably in order to sort it out (for admin purposes)

 and in this case, thank goodness for that, because otherwise
 it would be necessary to terminate udev in order to set the
 selinux permissions on the "real" /dev.

 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.

Re: udev and .dev...

[Erich Schubert]

> soooo... to fix that [rather than a patch, a sed command]:
> 	:%s/u?dev/.?u?dev/g

Note that . has a special meaning in regular expressions.
You should quote it, but you're approaching quoting hell right now with
your sed expression... ;-)

Also at least for some time udev used /etc/udev/.dev
but i think this has been made deprecated by now.

> this will allow setfiles to set up the security contexts on
> the /.dev which is the _real_ filesystem /dev stuff which will
> allow things like, oh, init (!!) to access the hard drive.

Are you sure? i'd guess that using /dev is hardwired into init.
FYI: i see
/dev on /.dev type none (rw,bind)

but /proc/mounts shows

/dev/root /.dev ext3 rw,noatime 0 0
none /dev tmpfs rw 0 0

So i think that /dev is moved via a bind mount to /.dev (kind of
emergency device nodes) and /dev is then replaced by a ramdisk which is
maintained by udev.

This sounds like relabling hell :-) "make relabel" might even skip /.dev
because it doesn't know the file system.
You can't use "make relabel" to persistently fix labels on /dev.
I don't know enough about automatic labelling by selinux. Maybe you'll
need a udev which reads the file_contexts file. :-(
(or a similar specification file)

Greetings,
Erich
-- 
    erich@(mucl.de|debian.org)      --      GPG Key ID: 4B3A135C    (o_
     Go away or i'll replace you with a very small shell script.    //\
            Es ist besser, geliebt und verloren zu haben,           V_/_
                    als niemals geliebt zu haben.

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

Re: udev and .dev...

[Stephen Smalley]

On Thu, 2004-07-29 at 11:09, Erich Schubert wrote:
> This sounds like relabling hell :-) "make relabel" might even skip /.dev
> because it doesn't know the file system.
> You can't use "make relabel" to persistently fix labels on /dev.
> I don't know enough about automatic labelling by selinux. Maybe you'll
> need a udev which reads the file_contexts file. :-(
> (or a similar specification file)

I think in Fedora, udev is presently set up to invoke restorecon, which
uses the matchpathcon() function to obtain the proper context from the
file_contexts configuration and then relabels the device node to that
context.  There was a patch to udev to directly call matchpathcon() and
use setfscreatecon() to directly create the device node in the proper
context, but that seems to have been dropped.

make relabel omits bind mounts, to avoid obvious aliasing problems.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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

Re: udev and .dev...

[Luke Kenneth Casson Leighton]

On Thu, Jul 29, 2004 at 01:03:02PM -0400, Stephen Smalley wrote:
> On Thu, 2004-07-29 at 11:09, Erich Schubert wrote:
> > This sounds like relabling hell :-) "make relabel" might even skip /.dev
> > because it doesn't know the file system.
> > You can't use "make relabel" to persistently fix labels on /dev.
> > I don't know enough about automatic labelling by selinux. Maybe you'll
> > need a udev which reads the file_contexts file. :-(
> > (or a similar specification file)
> 
> I think in Fedora, udev is presently set up to invoke restorecon, which
> uses the matchpathcon() function to obtain the proper context from the
> file_contexts configuration and then relabels the device node to that
> context.  There was a patch to udev to directly call matchpathcon() and
> use setfscreatecon() to directly create the device node in the proper
> context, but that seems to have been dropped.
 
 the little program - udev_selinux - uses setfilecon not setfscreatecon.

 it's a separate program, similar to restorecon in fact it is
 likely to be the same.

 it's run post-thingy.  post-create.

 also, symlinks aren't covered / managed / created.

 looks like a proper job's needed.

 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.

Re: udev and .dev...

[Luke Kenneth Casson Leighton]

On Thu, Jul 29, 2004 at 05:09:21PM +0200, Erich Schubert wrote:
> > soooo... to fix that [rather than a patch, a sed command]:
> > 	:%s/u?dev/.?u?dev/g
> 
> Note that . has a special meaning in regular expressions.
> You should quote it, but you're approaching quoting hell right now with
> your sed expression... ;-)
 
 *sigh*.

 okay how about %s/u?dev/[.u]dev/g - is that right?

 [\.u] means one character either dot (a real dot) or a u neh?

 *struggling*.

> Also at least for some time udev used /etc/udev/.dev
> but i think this has been made deprecated by now.
> 
> > this will allow setfiles to set up the security contexts on
> > the /.dev which is the _real_ filesystem /dev stuff which will
> > allow things like, oh, init (!!) to access the hard drive.
> 
> Are you sure? 

 yes, because with it, init works, without it, it don't!


> i'd guess that using /dev is hardwired into init.

 don't know... oh, yes, i know: no it isn't [hardwired]: the
 job of the scripts [in debian initrd, written by herbert]
 is to detect it, or to pass the root=/something/something
 option from the kernel boot.


> FYI: i see
> /dev on /.dev type none (rw,bind)
> 
> but /proc/mounts shows
> 
> /dev/root /.dev ext3 rw,noatime 0 0
> none /dev tmpfs rw 0 0
> 
> So i think that /dev is moved via a bind mount to /.dev (kind of
> emergency device nodes) and /dev is then replaced by a ramdisk which is
> maintained by udev.

 yes: quoting this section of /etc/init.d/udev....

	# /.dev is used by /sbin/MAKEDEV to access the real /dev directory.
	# if you don't like it just remove it.
	[ -d /.dev ] && mount --bind /dev /.dev

	echo -n "Mounting a tmpfs over /dev..."
	mount -n -o size=$tmpfs_size,mode=0755 -t tmpfs none /dev
	echo "done."
	}


> This sounds like relabling hell :-) "make relabel" might even skip /.dev
> because it doesn't know the file system.
> You can't use "make relabel" to persistently fix labels on /dev.

 no, but if the /.dev ISN'T there, then you will find that the first
 time you run make relabel, subsequently you cannot boot.


> I don't know enough about automatic labelling by selinux. Maybe you'll
> need a udev which reads the file_contexts file. :-(
> (or a similar specification file)
>
 
 that would be very nice.

 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.