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;
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
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 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.
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.
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?
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.
The code's already written and there.
The reason you don't want to run it on a normal /dev is because it's *pointless.*
Bill
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.
selinux@lists.fedoraproject.org