tmpfs /dev

tmpfs /dev

[Russell Coker]

I have got a working system with tmpfs /dev and with udev in the initrd.  I 
modified /sbin/init to run the following script immediately after loading the 
policy:

#!/bin/sh
. /etc/selinux/config
/sbin/setfiles-mine /etc/selinux/$SELINUXTYPE/contexts/files/file_contexts /dev

Naturally we need to change the location of setfiles to /sbin from /usr/sbin 
if this is the solution we choose as this script will run before any file 
systems are mounted.

Below is the policy I added.  I had already changed the type declarations to 
use the dev_filesystem attribute for everything that may occur under /dev 
(patch sent to the main SE Linux list).  I have setfiles being run as 
kernel_t because I feel that running setfiles as kernel_t is better than 
granting setfiles_t more access than is otherwise required.  This means that 
I have to grant kernel_t access to relabel the device nodes, no big deal IMHO 
as kernel_t generally has ultimate access anyway.

I relabeled /sbin/MAKEDEV as udev_exec_t so that it runs as udev_t when run 
from /sbin/start_udev and can do the things that it wants to do.  This is a 
minor hack.  Maybe it would be better to label /sbin/start_udev as 
udev_exec_t?  That would remove the need to allow initrc_t to create 
sym-links under /dev.

avc:  denied  { getattr } for  pid=1641 exe=/sbin/lvm.static 
path=/sbin/MAKEDEV dev=dm-0 ino=196261 scontext=system_u:system_r:lvm_t 
tcontext=system_u:object_r:udev_exec_t tclass=file

Why does lvm.static want to stat /sbin/MAKEDEV?  Seems strange to me.

Below is the policy I wrote to allow tmpfs /dev and udev in initrd.  I haven't 
split it into all the relevant .te files because it's still an experiment at 
this stage.  After some discussion I'll produce a release version.

# for tmpfs /dev
allow dev_filesystem tmpfs_t:filesystem associate;
allow kernel_t tmpfs_t:chr_file rw_file_perms;
allow kernel_t tmpfs_t:{ dir file lnk_file chr_file blk_file } { getattr 
relabel
from };
allow kernel_t device_t:{ dir lnk_file chr_file blk_file } relabelto;
allow kernel_t device_type:{ chr_file blk_file } relabelto;
allow kernel_t udev_tbl_t:file relabelto;
can_exec(kernel_t, { sbin_t setfiles_exec_t })
# for /dev/pts on tmpfs
allow mount_t tmpfs_t:dir mounton;
# for /sbin/MAKEDEV - why?
allow lvm_t udev_exec_t:file getattr;
# allow /sbin/start_udev to run ln
allow initrc_t device_t:lnk_file create_lnk_perms;

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

--
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: tmpfs /dev

[Daniel J Walsh]

Russell Coker wrote:

>I have got a working system with tmpfs /dev and with udev in the initrd.  I 
>modified /sbin/init to run the following script immediately after loading the 
>policy:
>
>#!/bin/sh
>. /etc/selinux/config
>/sbin/setfiles-mine /etc/selinux/$SELINUXTYPE/contexts/files/file_contexts /dev
>
>Naturally we need to change the location of setfiles to /sbin from /usr/sbin 
>if this is the solution we choose as this script will run before any file 
>systems are mounted.
>
>Below is the policy I added.  I had already changed the type declarations to 
>use the dev_filesystem attribute for everything that may occur under /dev 
>(patch sent to the main SE Linux list).  I have setfiles being run as 
>kernel_t because I feel that running setfiles as kernel_t is better than 
>granting setfiles_t more access than is otherwise required.  This means that 
>I have to grant kernel_t access to relabel the device nodes, no big deal IMHO 
>as kernel_t generally has ultimate access anyway.
>
>I relabeled /sbin/MAKEDEV as udev_exec_t so that it runs as udev_t when run 
>from /sbin/start_udev and can do the things that it wants to do.  This is a 
>minor hack.  Maybe it would be better to label /sbin/start_udev as 
>udev_exec_t?  That would remove the need to allow initrc_t to create 
>sym-links under /dev.
>
>avc:  denied  { getattr } for  pid=1641 exe=/sbin/lvm.static 
>path=/sbin/MAKEDEV dev=dm-0 ino=196261 scontext=system_u:system_r:lvm_t 
>tcontext=system_u:object_r:udev_exec_t tclass=file
>
>Why does lvm.static want to stat /sbin/MAKEDEV?  Seems strange to me.
>
>Below is the policy I wrote to allow tmpfs /dev and udev in initrd.  I haven't 
>split it into all the relevant .te files because it's still an experiment at 
>this stage.  After some discussion I'll produce a release version.
>
># for tmpfs /dev
>allow dev_filesystem tmpfs_t:filesystem associate;
>allow kernel_t tmpfs_t:chr_file rw_file_perms;
>allow kernel_t tmpfs_t:{ dir file lnk_file chr_file blk_file } { getattr 
>relabel
>from };
>allow kernel_t device_t:{ dir lnk_file chr_file blk_file } relabelto;
>allow kernel_t device_type:{ chr_file blk_file } relabelto;
>allow kernel_t udev_tbl_t:file relabelto;
>can_exec(kernel_t, { sbin_t setfiles_exec_t })
># for /dev/pts on tmpfs
>allow mount_t tmpfs_t:dir mounton;
># for /sbin/MAKEDEV - why?
>allow lvm_t udev_exec_t:file getattr;
># allow /sbin/start_udev to run ln
>allow initrc_t device_t:lnk_file create_lnk_perms;
>
>  
>
You will need to talk to Bill Nottingham about modifying /sbin/init to 
do this.  They are not crazy about
putting additional code into /sbin/init since it is very hard to debug.  
They prefer rc.sysinit.  They also do not
want to relabel the /dev file system if it is not a tmpfs,  since with 
8000 or more files it could take a while and
slow down the boot up.  The modification that we are currently using 
only modifies rc.sysinit to do a restorecon
on /dev/* when it is tmpfs and adds a couple of allows for hostname, 
init, mount and consoletype to use tmpfs_t.

Dan

--
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: tmpfs /dev

[Russell Coker]

On Fri, 10 Sep 2004 06:19, Daniel J Walsh <dwalsh@redhat.com> wrote:
> You will need to talk to Bill Nottingham about modifying /sbin/init to
> do this.  They are not crazy about
> putting additional code into /sbin/init since it is very hard to debug.

We've done it once, we can do it again.

> They prefer rc.sysinit.  They also do not

rc.sysinit means changing the policy for init_t, initrc_t, and maybe others.

> want to relabel the /dev file system if it is not a tmpfs,  since with
> 8000 or more files it could take a while and
> slow down the boot up.

On the slowest machine I have access to (a machine that can never run Fedora 
because it doesn't meet the hardware requirements) it takes 12 seconds to run 
setfiles on a fully loaded /dev.  On machines that are a mere four years old 
it takes about 2 seconds, I doubt that you will be able to measure the 
difference that this makes on any hardware that can be purchased now.  But 
writing some code to check for the file system type is not too difficult.

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

--
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: tmpfs /dev

[Luke Kenneth Casson Leighton]

On Fri, Sep 10, 2004 at 03:08:27PM +1000, Russell Coker wrote:
> On Fri, 10 Sep 2004 06:19, Daniel J Walsh <dwalsh@redhat.com> wrote:
> > You will need to talk to Bill Nottingham about modifying /sbin/init to
> > do this.  They are not crazy about
> > putting additional code into /sbin/init since it is very hard to debug.
> 
> We've done it once, we can do it again.
> 
> > They prefer rc.sysinit.  They also do not
> 
> rc.sysinit means changing the policy for init_t, initrc_t, and maybe others.
> 
> > want to relabel the /dev file system if it is not a tmpfs,  since with
> > 8000 or more files it could take a while and
> > slow down the boot up.
> 
> On the slowest machine I have access to (a machine that can never run Fedora 
> because it doesn't meet the hardware requirements) it takes 12 seconds to run 
> setfiles on a fully loaded /dev.  On machines that are a mere four years old 
> it takes about 2 seconds, I doubt that you will be able to measure the 
> difference that this makes on any hardware that can be purchased now.  But 
> writing some code to check for the file system type is not too difficult.
 
 on my 1.6Gz athlon, it takes somewhere between 30 and 50
 seconds to do the setting up of udev entries (ttyS0->ttyS63
 and tty0->tty63) which would make it more of a priority to
 be sorted than the above!

 l.

 
-- 
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love.  If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<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: tmpfs /dev

[Russell Coker]

On Sat, 11 Sep 2004 02:30, Bill Nottingham <notting@redhat.com> wrote:
> Russell Coker (russell@coker.com.au) said:
> > On Fri, 10 Sep 2004 06:19, Daniel J Walsh <dwalsh@redhat.com> wrote:
> > > You will need to talk to Bill Nottingham about modifying /sbin/init to
> > > do this.  They are not crazy about
> > > putting additional code into /sbin/init since it is very hard to debug.
> >
> > We've done it once, we can do it again.
>
> But why is init any better? Especially when it's just spawning a
> shell script - that's a hack.

Spawning a shell script is good for a test.  If we decide to run it from init 
then we can do it differently in the release version of the code.

> > > They prefer rc.sysinit.  They also do not
> >
> > rc.sysinit means changing the policy for init_t, initrc_t, and maybe
> > others.
>
> init runs in init_t, surely?

init runs in init_t AFTER it re-exec's itself.  At the time it is doing the SE 
Linux stuff it's running as kernel_t or running on a system with no policy 
loaded.

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

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