temporary hack to use udev in selinux

temporary hack to use udev in selinux

[Luke Kenneth Casson Leighton]

i have a requirement (use of usb-mount, see
http://users.actrix.co.nz/michael/usbmount.html) that forces the use
of udev on an selinux system.

fighting with it for a day, and after seeing some clues in the
file contexts (/(u)dev/....) i decided to try editing
/etc/udev/udev.conf to set it to use /udev instead of /dev.

other than a warning about udev not starting up, well, everything
seems to work hunky-dory.

somehow i do _get_ a udevd running, i could not tell you how it got
there.

i notice the following message 

	http://www.redhat.com/archives/fedora-devel-list/2004-March/msg00888.html

in which steven (hi steven :) says that support for udev "fake"
attributes for ramfs and tmpfs, just like for devpts.

is that literally as simple as cut/paste the devpts code...
the xattr stuff?

cos if so, i _like_ cut/paste :)

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: temporary hack to use udev in selinux

[Joshua Brindle]

Luke Kenneth Casson Leighton wrote:

>i have a requirement (use of usb-mount, see
>http://users.actrix.co.nz/michael/usbmount.html) that forces the use
>of udev on an selinux system.
>
>fighting with it for a day, and after seeing some clues in the
>file contexts (/(u)dev/....) i decided to try editing
>/etc/udev/udev.conf to set it to use /udev instead of /dev.
>
>other than a warning about udev not starting up, well, everything
>seems to work hunky-dory.
>
>somehow i do _get_ a udevd running, i could not tell you how it got
>there.
>
>i notice the following message 
>
>	http://www.redhat.com/archives/fedora-devel-list/2004-March/msg00888.html
>
>in which steven (hi steven :) says that support for udev "fake"
>attributes for ramfs and tmpfs, just like for devpts.
>
>is that literally as simple as cut/paste the devpts code...
>the xattr stuff?
>
>cos if so, i _like_ cut/paste :)
>
>l.
>
>  
>
Chris PeBenito made this patch for Gentoo when we were evalutating udev 
on selinux

http://dev.gentoo.org/~method/1330_linux-2.6.5-ramfs-xattr.patch

that should patch cleanly into 2.6.7, but I'd like to note that at this 
point udev is braindead wrt SELinux.
Once upon a time udev had selinux support integrated so that setfscreate 
was called to set the context of the devices being written however it 
was changed at some point to make SELinux an after device creation addon 
script which makes it label the devices after they are created. Because 
of this Hardened Gentoo has decided not to support udev at this time.


Joshua Brindle

--
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: temporary hack to use udev in selinux

[Luke Kenneth Casson Leighton]

hiya joshua,

a recent release of udev (0.26) from like, two weeks ago
(which i only just noticed) appears to have had its
udev "hard-coded" support removed - and incidentally
the equally hard-coded dbus support removed...

... to be replaced with an /etc/dev.d/something/selinux
which runs restorecon $DEVICE.

and, amazingly, it works.

what is getting my goat at the moment is as i said having
to use /udev instead of /dev.

GREAT.  a patch.

it wouldn't have occurred to me to do the inode and special
node stuff.

thanks v. much.

l.

On Wed, Jul 28, 2004 at 08:29:45PM -0400, Joshua Brindle wrote:
> Luke Kenneth Casson Leighton wrote:
> 
> >i have a requirement (use of usb-mount, see
> >http://users.actrix.co.nz/michael/usbmount.html) that forces the use
> >of udev on an selinux system.
> >
> >fighting with it for a day, and after seeing some clues in the
> >file contexts (/(u)dev/....) i decided to try editing
> >/etc/udev/udev.conf to set it to use /udev instead of /dev.
> >
> >other than a warning about udev not starting up, well, everything
> >seems to work hunky-dory.
> >
> >somehow i do _get_ a udevd running, i could not tell you how it got
> >there.
> >
> >i notice the following message 
> >
> >	http://www.redhat.com/archives/fedora-devel-list/2004-March/msg00888.html
> >
> >in which steven (hi steven :) says that support for udev "fake"
> >attributes for ramfs and tmpfs, just like for devpts.
> >
> >is that literally as simple as cut/paste the devpts code...
> >the xattr stuff?
> >
> >cos if so, i _like_ cut/paste :)
> >
> >l.
> >
> > 
> >
> Chris PeBenito made this patch for Gentoo when we were evalutating udev 
> on selinux
> 
> http://dev.gentoo.org/~method/1330_linux-2.6.5-ramfs-xattr.patch
> 
> that should patch cleanly into 2.6.7, but I'd like to note that at this 
> point udev is braindead wrt SELinux.
> Once upon a time udev had selinux support integrated so that setfscreate 
> was called to set the context of the devices being written however it 
> was changed at some point to make SELinux an after device creation addon 
> script which makes it label the devices after they are created. Because 
> of this Hardened Gentoo has decided not to support udev at this time.
> 
> 
> Joshua Brindle

-- 
-- 
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: temporary hack to use udev in selinux

[Luke Kenneth Casson Leighton]

On Wed, Jul 28, 2004 at 08:29:45PM -0400, Joshua Brindle wrote:
> Luke Kenneth Casson Leighton wrote:
> 
> >i have a requirement (use of usb-mount, see
> >http://users.actrix.co.nz/michael/usbmount.html) that forces the use
> >of udev on an selinux system.
> >
> >fighting with it for a day, and after seeing some clues in the
> >file contexts (/(u)dev/....) i decided to try editing
> >/etc/udev/udev.conf to set it to use /udev instead of /dev.
> >
> >other than a warning about udev not starting up, well, everything
> >seems to work hunky-dory.
> >
> >somehow i do _get_ a udevd running, i could not tell you how it got
> >there.
> >
> >i notice the following message 
> >
> >	http://www.redhat.com/archives/fedora-devel-list/2004-March/msg00888.html
> >
> >in which steven (hi steven :) says that support for udev "fake"
> >attributes for ramfs and tmpfs, just like for devpts.
> >
> >is that literally as simple as cut/paste the devpts code...
> >the xattr stuff?
> >
> >cos if so, i _like_ cut/paste :)
> >
> >l.
> >
> > 
> >
> Chris PeBenito made this patch for Gentoo when we were evalutating udev 
> on selinux
> 
> http://dev.gentoo.org/~method/1330_linux-2.6.5-ramfs-xattr.patch
> 
> that should patch cleanly into 2.6.7, but I'd like to note that at this 
> point udev is braindead wrt SELinux.
> Once upon a time udev had selinux support integrated so that setfscreate 
> was called to set the context of the devices being written however it 
> was changed at some point to make SELinux an after device creation addon 
> script which makes it label the devices after they are created. 

 ... *click*... re-read what you said.

 yes, the change was made version 0.24 or so.

> Because 
> of this Hardened Gentoo has decided not to support udev at this time.


 why are project developers removing [selinux] stuff like this?

 i mean, not that i am in a position to care [whereas gentoo is]
 but that's just such an obvious No.

 you don't _create_ race conditions, even when the default permissions
 are going to be (null) on a mandatory access control system like
 selinux.

 removing setting of device contexts from udev _clearly_ sets the
 devices up for being inaccessible for a period of time.

 unless the developer of udev is somehow guaranteeing that no access
 will be made to the /dev item being created.

 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: temporary hack to use udev in selinux

[Luke Kenneth Casson Leighton]

okay, i've added in some stuff for tmpfs, just like chris did,
joshua.

if anyone would like to play with this (aside from kicking the
udev developer) then you can find the code at
http://hands.com/~lkcl/selinux/2.6.6.

it's too late in the morning to go making patches, sorry: help yourself.
i'll sort patches later.

i added, like chris did, some "special" inodes stuff, and some stuff
to do symlinks too.

of course, the default policy files all expect the root filesystem
to be a hard drive not a tmpfs_t so boot poos up.

i started adding in selinux permissions to udev.te.

... i get the impression that i need to do stuff like create a
new initrd that has /selinux in it and things.

but what i _can_ do that's fairly easy is write a message to the
nice udev developer :)

l.

On Thu, Jul 29, 2004 at 02:35:10AM +0100, Luke Kenneth Casson Leighton wrote:
> > >i have a requirement (use of usb-mount, see
> > >http://users.actrix.co.nz/michael/usbmount.html) that forces the use
> > >of udev on an selinux system.

> > Chris PeBenito made this patch for Gentoo when we were evalutating udev 
> > on selinux
> > 
> > http://dev.gentoo.org/~method/1330_linux-2.6.5-ramfs-xattr.patch

--
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: temporary hack to use udev in selinux

[Stephen Smalley]

On Wed, 2004-07-28 at 22:04, Luke Kenneth Casson Leighton wrote:
> okay, i've added in some stuff for tmpfs, just like chris did,
> joshua.
> 
> if anyone would like to play with this (aside from kicking the
> udev developer) then you can find the code at
> http://hands.com/~lkcl/selinux/2.6.6.
> 
> it's too late in the morning to go making patches, sorry: help yourself.
> i'll sort patches later.
> 
> i added, like chris did, some "special" inodes stuff, and some stuff
> to do symlinks too.
> 
> of course, the default policy files all expect the root filesystem
> to be a hard drive not a tmpfs_t so boot poos up.

Please prepare a patch for upstreaming, as this is definitely a desired
feature (tmpfs xattr support for SELinux).  However, tmpfs may be a bit
tricky to handle correctly, because it is also used for the shmem pseudo
filesystem, and the current policy only allows access based on that
usage at the moment.

-- 
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: temporary hack to use udev in selinux

[Luke Kenneth Casson Leighton]

On Thu, Jul 29, 2004 at 08:47:48AM -0400, Stephen Smalley wrote:
> On Wed, 2004-07-28 at 22:04, Luke Kenneth Casson Leighton wrote:
> > okay, i've added in some stuff for tmpfs, just like chris did,
> > joshua.

> Please prepare a patch for upstreaming, as this is definitely a desired
> feature (tmpfs xattr support for SELinux).  

 okay.

> However, tmpfs may be a bit
> tricky to handle correctly, because it is also used for the shmem pseudo
> filesystem, and the current policy only allows access based on that
> usage at the moment.

 i don't follow entirely... ah, do you mean, tmpfs_t covers _both_ shmem
 _and_ tmpfs, so if i add xattr support and people start using it as
 tmpfs, then the policies are, yes, i think i get it.

 ... is there a way of supporting both names shmfs and tmpfs in
 the mount command and also in the kernel, such that they are
 distinguishable that way?

 i.e. it's the same kernel code, but it can be mounted with two
 different names.

 is that reasonable or unreasonable?

 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: temporary hack to use udev in selinux

[Stephen Smalley]

On Thu, 2004-07-29 at 10:20, Luke Kenneth Casson Leighton wrote:
>  i don't follow entirely... ah, do you mean, tmpfs_t covers _both_ shmem
>  _and_ tmpfs, so if i add xattr support and people start using it as
>  tmpfs, then the policies are, yes, i think i get it.
> 
>  ... is there a way of supporting both names shmfs and tmpfs in
>  the mount command and also in the kernel, such that they are
>  distinguishable that way?
> 
>  i.e. it's the same kernel code, but it can be mounted with two
>  different names.
> 
>  is that reasonable or unreasonable?

SELinux determines filesystem labeling behavior (policy/fs_use) based on
filesystem type, and shmem subsystem happens to use an instance of the
tmpfs filesystem type.  James Morris introduced a new mount option
(context=) a while back to allow assigning a single security context to
all inodes in a particular mount; I suppose that this could be
generalized to allow you to specify the labeling behavior itself on a
per-mount basis.
  
-- 
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: temporary hack to use udev in selinux

[James Morris]

On Thu, 29 Jul 2004, Stephen Smalley wrote:

> SELinux determines filesystem labeling behavior (policy/fs_use) based on
> filesystem type, and shmem subsystem happens to use an instance of the
> tmpfs filesystem type.  James Morris introduced a new mount option
> (context=) a while back to allow assigning a single security context to
> all inodes in a particular mount; I suppose that this could be
> generalized to allow you to specify the labeling behavior itself on a
> per-mount basis.

This could be done by simply allowing context= to override any other 
behavior, right?


- James
-- 
James Morris
<jmorris@redhat.com>



--
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: temporary hack to use udev in selinux

[Stephen Smalley]

On Thu, 2004-07-29 at 13:06, James Morris wrote:
> This could be done by simply allowing context= to override any other 
> behavior, right?

context= only lets you map all inodes in the filesystem to a single
security context and prohibits getxattr/setxattr/setfscreatecon.  For
tmpfs, we want to allow individual inode labeling and
getxattr/setxattr/setfscreatecon, so that tmpfs can be used for /tmp or
/dev or shmem in differing ways.

-- 
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: temporary hack to use udev in selinux

[Luke Kenneth Casson Leighton]

On Thu, Jul 29, 2004 at 01:22:56PM -0400, Stephen Smalley wrote:
> On Thu, 2004-07-29 at 13:06, James Morris wrote:
> > This could be done by simply allowing context= to override any other 
> > behavior, right?
> 
> context= only lets you map all inodes in the filesystem to a single
> security context and prohibits getxattr/setxattr/setfscreatecon.  

> For
> tmpfs, we want to allow individual inode labeling and
> getxattr/setxattr/setfscreatecon, 

 patch done that.  for dirs, files, symlinks and "special" inodes, whatever
 _they_ are.
 
 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: temporary hack to use udev in selinux

[Stephen Smalley]

On Thu, 2004-07-29 at 16:05, Luke Kenneth Casson Leighton wrote:
> On Thu, Jul 29, 2004 at 01:22:56PM -0400, Stephen Smalley wrote:
> > For
> > tmpfs, we want to allow individual inode labeling and
> > getxattr/setxattr/setfscreatecon, 
> 
>  patch done that.  for dirs, files, symlinks and "special" inodes, whatever
>  _they_ are.

The patch allows for getxattr/setxattr, but still doesn't address the
issue of SELinux treating different instances of tmpfs in different
ways.  That why we need mount option support.  It may be sufficient to
just extend fscontext= semantics (set superblock security context)
beyond xattr-supporting filesystems, so that we can assign a different
superblock security context to each instance and then set up type
transition rules appropriately, using fs_use_trans in all cases for the
initial labeling.

-- 
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: temporary hack to use udev in selinux

[Russell Coker]

On Fri, 30 Jul 2004 06:09, Stephen Smalley <sds@epoch.ncsc.mil> wrote:
> On Thu, 2004-07-29 at 16:05, Luke Kenneth Casson Leighton wrote:
> > On Thu, Jul 29, 2004 at 01:22:56PM -0400, Stephen Smalley wrote:
> > > For
> > > tmpfs, we want to allow individual inode labeling and
> > > getxattr/setxattr/setfscreatecon,
> >
> >  patch done that.  for dirs, files, symlinks and "special" inodes,
> > whatever _they_ are.
>
> The patch allows for getxattr/setxattr, but still doesn't address the
> issue of SELinux treating different instances of tmpfs in different
> ways.  That why we need mount option support.  It may be sufficient to
> just extend fscontext= semantics (set superblock security context)
> beyond xattr-supporting filesystems, so that we can assign a different
> superblock security context to each instance and then set up type
> transition rules appropriately, using fs_use_trans in all cases for the
> initial labeling.

This shouldn't even need kernel code.  As long as the default type is not 
overly permissive the mount program can relabel the root directory of a tmpfs 
file system after mounting it.

-- 
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: temporary hack to use udev in selinux

[Luke Kenneth Casson Leighton]

On Sat, Jul 31, 2004 at 11:43:19AM +1000, Russell Coker wrote:

> On Fri, 30 Jul 2004 06:09, Stephen Smalley <sds@epoch.ncsc.mil> wrote:

> > The patch allows for getxattr/setxattr, but still doesn't address the
> > issue of SELinux treating different instances of tmpfs in different
> > ways.  That why we need mount option support.  It may be sufficient to
> > just extend fscontext= semantics (set superblock security context)
> > beyond xattr-supporting filesystems, so that we can assign a different
> > superblock security context to each instance and then set up type
> > transition rules appropriately, using fs_use_trans in all cases for the
> > initial labeling.
> 
> This shouldn't even need kernel code.  As long as the default type is not 
> overly permissive the mount program can relabel the root directory of a tmpfs 
> file system after mounting it.

 i feel a disconnect in my understanding coming on.

 just to clarify what i believe stephen is saying:

 stephen i believe is concerned that tmpfs_t, because it is used for
 two different purposes, is used for filesystems both shmfs and tmpfs,
 and, prior to this patch, nobody cared because they never used one
 of those [tmpfs].

 so, one was useless, and so permissions have been restricted on
 tmpfs_t and the use of tmpfs_t.

 now, suddenly, tmpfs_t gets automatically assigned to something which
 is useful, and people might be tempted to increase the permissions
 of tmpfs_t, incidentally adding extra permissions where shmfs is used
 (and rightly restricted).

 what _you_ are saying, russell, is that instead of increasing the
 permissions on the usage of tmpfs_t, is to mount a tmpfs mountpoint,
 then run setfiles on its contents prior to use, such that it will
 never be necessary to increase the permissions of tmpfs_t?

 because tmpfs_t is going to be temporary, you _have_ to do a setfiles
 (or a restorecon on each individual file) _anyway_.

 yes?

 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: temporary hack to use udev in selinux

[Russell Coker]

On Sun, 1 Aug 2004 02:35, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> On Sat, Jul 31, 2004 at 11:43:19AM +1000, Russell Coker wrote:
> > On Fri, 30 Jul 2004 06:09, Stephen Smalley <sds@epoch.ncsc.mil> wrote:
> > > The patch allows for getxattr/setxattr, but still doesn't address the
> > > issue of SELinux treating different instances of tmpfs in different
> > > ways.  That why we need mount option support.  It may be sufficient to
> > > just extend fscontext= semantics (set superblock security context)
> > > beyond xattr-supporting filesystems, so that we can assign a different
> > > superblock security context to each instance and then set up type
> > > transition rules appropriately, using fs_use_trans in all cases for the
> > > initial labeling.
> >
> > This shouldn't even need kernel code.  As long as the default type is not
> > overly permissive the mount program can relabel the root directory of a
> > tmpfs file system after mounting it.
>
>  stephen i believe is concerned that tmpfs_t, because it is used for
>  two different purposes, is used for filesystems both shmfs and tmpfs,
>  and, prior to this patch, nobody cared because they never used one
>  of those [tmpfs].

Yes.  So we need to have different mounts of the shmfs get different types.

>  what _you_ are saying, russell, is that instead of increasing the
>  permissions on the usage of tmpfs_t, is to mount a tmpfs mountpoint,
>  then run setfiles on its contents prior to use, such that it will
>  never be necessary to increase the permissions of tmpfs_t?

Yes.  In fact using tmp_t as the label on the root directory of /dev/shm so 
that file/directory creation gets the same labels as it does under /tmp, 
while we leave tmpfs_t with restrictive access.

>  because tmpfs_t is going to be temporary, you _have_ to do a setfiles
>  (or a restorecon on each individual file) _anyway_.

If /dev/shm is mounted before the system goes to multi-user mode then there 
will be no files under it and no need for labelling other than the root 
directory.

-- 
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: temporary hack to use udev in selinux

[Luke Kenneth Casson Leighton]

On Sun, Aug 01, 2004 at 08:31:37PM +1000, Russell Coker wrote:
> On Sun, 1 Aug 2004 02:35, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> > On Sat, Jul 31, 2004 at 11:43:19AM +1000, Russell Coker wrote:
> > > On Fri, 30 Jul 2004 06:09, Stephen Smalley <sds@epoch.ncsc.mil> wrote:
> > > > The patch allows for getxattr/setxattr, but still doesn't address the
> > > > issue of SELinux treating different instances of tmpfs in different
> > > > ways.  That why we need mount option support.  It may be sufficient to
> > > > just extend fscontext= semantics (set superblock security context)
> > > > beyond xattr-supporting filesystems, so that we can assign a different
> > > > superblock security context to each instance and then set up type
> > > > transition rules appropriately, using fs_use_trans in all cases for the
> > > > initial labeling.
> > >
> > > This shouldn't even need kernel code.  As long as the default type is not
> > > overly permissive the mount program can relabel the root directory of a
> > > tmpfs file system after mounting it.
> >
> >  stephen i believe is concerned that tmpfs_t, because it is used for
> >  two different purposes, is used for filesystems both shmfs and tmpfs,
> >  and, prior to this patch, nobody cared because they never used one
> >  of those [tmpfs].
> 
> Yes.  So we need to have different mounts of the shmfs get different types.
> 
> >  what _you_ are saying, russell, is that instead of increasing the
> >  permissions on the usage of tmpfs_t, is to mount a tmpfs mountpoint,
> >  then run setfiles on its contents prior to use, such that it will
> >  never be necessary to increase the permissions of tmpfs_t?
> 
> Yes.  In fact using tmp_t as the label on the root directory of /dev/shm so 
> that file/directory creation gets the same labels as it does under /tmp, 
> while we leave tmpfs_t with restrictive access.
 
 eek.

 okay... *scared*.

 why, because i need this _today_ :)

 i need usb-mount, therefore i need udev, therefore i need this
 patch, therefore i need to do this now.

 okay.  so i just.. okayokay.

 i can just change, in /etc/selinux/src/fs_use, the line
 that says something like fs_trans shm .... tmpfs_t to
 say tmp_t?

 well, hey, i can always try it.

 i have had to add _stacks_ of permissions to tmpfs_t to get udev,
 initrc_t, hotplug_t and fsadm_t _and_ then some to get this to work
 (on to about the 10th reboot so far!).

 presumably i can just ":%s/tmpfs_t/tmp_t/g" with vi and, well other
 than some duplicates, expect it to... work?

 all very non-scientific and i DON'T CARE! :)

 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: temporary hack to use udev in selinux

[Stephen Smalley]

On Sun, 2004-08-01 at 08:03, Luke Kenneth Casson Leighton wrote:
>  i can just change, in /etc/selinux/src/fs_use, the line
>  that says something like fs_trans shm .... tmpfs_t to
>  say tmp_t?

This merely changes the default labeling for all tmpfs mounts, so it
will affect the kernel internal mount for shmem, any tmpfs mount you
create on /tmp, /dev, etc.  That is only adequate if you are willing to
apply the same policy to all tmpfs mounts, not generally acceptable.

-- 
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: temporary hack to use udev in selinux

[Luke Kenneth Casson Leighton]

On Sun, Aug 01, 2004 at 08:31:37PM +1000, Russell Coker wrote:

> Yes.  So we need to have different mounts of the shmfs get different types.
> 
> >  what _you_ are saying, russell, is that instead of increasing the
> >  permissions on the usage of tmpfs_t, is to mount a tmpfs mountpoint,
> >  then run setfiles on its contents prior to use, such that it will
> >  never be necessary to increase the permissions of tmpfs_t?
> 
> Yes.  In fact using tmp_t as the label on the root directory of /dev/shm so 
> that file/directory creation gets the same labels as it does under /tmp, 
> while we leave tmpfs_t with restrictive access.
> 
> >  because tmpfs_t is going to be temporary, you _have_ to do a setfiles
> >  (or a restorecon on each individual file) _anyway_.
> 
> If /dev/shm is mounted before the system goes to multi-user mode then there 
> will be no files under it and no need for labelling other than the root 
> directory.

 okay, so in fs_use i change
 
	 fs_use_trans tmpfs ....:tmp_t

 NOT the shm one :)

 got that the wrong way round first time i think.


--
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: temporary hack to use udev in selinux

[Stephen Smalley]

On Sat, 2004-07-31 at 12:35, Luke Kenneth Casson Leighton wrote:
>  what _you_ are saying, russell, is that instead of increasing the
>  permissions on the usage of tmpfs_t, is to mount a tmpfs mountpoint,
>  then run setfiles on its contents prior to use, such that it will
>  never be necessary to increase the permissions of tmpfs_t?
> 
>  because tmpfs_t is going to be temporary, you _have_ to do a setfiles
>  (or a restorecon on each individual file) _anyway_.

Each tmpfs instance should start life empty, as it is only a
memory-based filesystem anyway.  So you only have to worry about the
security context on the superblock and the security context on the root
directory.

-- 
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: temporary hack to use udev in selinux

[Stephen Smalley]

On Fri, 2004-07-30 at 21:43, Russell Coker wrote:
> On Fri, 30 Jul 2004 06:09, Stephen Smalley <sds@epoch.ncsc.mil> wrote:
> > The patch allows for getxattr/setxattr, but still doesn't address the
> > issue of SELinux treating different instances of tmpfs in different
> > ways.  That why we need mount option support.  It may be sufficient to
> > just extend fscontext= semantics (set superblock security context)
> > beyond xattr-supporting filesystems, so that we can assign a different
> > superblock security context to each instance and then set up type
> > transition rules appropriately, using fs_use_trans in all cases for the
> > initial labeling.
> 
> This shouldn't even need kernel code.  As long as the default type is not 
> overly permissive the mount program can relabel the root directory of a tmpfs 
> file system after mounting it.

I'd like to be able to assign different security contexts to different
tmpfs superblocks, not just the root directory.  That requires a minor
change to the existing fscontext= mount option to allow applying it to
filesystems that use labeling behaviors other than xattr.

-- 
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: temporary hack to use udev in selinux

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 286 bytes --]

On Thu, 29 Jul 2004 13:06:15 EDT, James Morris said:
 
> This could be done by simply allowing context= to override any other 
> behavior, right?

Well, with proper control over what roles/etc can use that mount option.
(Think "/dev/cdrom auto-mounted as 'user' by a system daemon"...)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: temporary hack to use udev in selinux

[Luke Kenneth Casson Leighton]

usb-mount does this by using sudo.

it's a very clever program, but from a security perspective i ain't
entirely enamoured with the number of additions i've had to make
to fsadm.te, the number of extra permissions to mount_t and user_t
and i'm sure i've got something wrong, here.

however, that aside, usb-mount is at present only set up to
do usb hotplug devices.

perhaps it could be adapted to do scsi and ide drives, and consequently
cdroms too?

does hotplug "do" cdrom drives?

l.

p.s. anyone interested in the rather drastic hacks i've done for
usb-mount, let me know.

p.p.s. neither sg_map nor disktype are catered for in fsadm.te,
so i've had to add stuff for those.

On Thu, Jul 29, 2004 at 04:59:16PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Thu, 29 Jul 2004 13:06:15 EDT, James Morris said:
>  
> > This could be done by simply allowing context= to override any other 
> > behavior, right?
> 
> Well, with proper control over what roles/etc can use that mount option.
> (Think "/dev/cdrom auto-mounted as 'user' by a system daemon"...)



-- 
-- 
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: temporary hack to use udev in selinux

[Luke Kenneth Casson Leighton]

On Thu, Jul 29, 2004 at 08:47:48AM -0400, Stephen Smalley wrote:

> On Wed, 2004-07-28 at 22:04, Luke Kenneth Casson Leighton wrote:
> > okay, i've added in some stuff for tmpfs, just like chris did,
> > joshua.

 ... by the way is anyone at all worried that shmfs doesn't have
 an exit_tmpfs function?


--
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: temporary hack to use udev in selinux

[Luke Kenneth Casson Leighton]

On Thu, Jul 29, 2004 at 08:47:48AM -0400, Stephen Smalley wrote:

> On Wed, 2004-07-28 at 22:04, Luke Kenneth Casson Leighton wrote:
> > okay, i've added in some stuff for tmpfs, just like chris did,
> > joshua.

> Please prepare a patch for upstreaming, as this is definitely a desired
> feature (tmpfs xattr support for SELinux).  

 done, it's at
 http://hands.com/~lkcl/selinux/2.6.6/2.6.6-xattr-shmfs.patch

 i trust that anyone using this will, of course, take full
 responsibility for doing so.

 i had to change my .sig a few months back because someone was
 under the impression that stuff i sent to this list was somehow
 magically production quality, whereas what i _actually_ do is
 bumble along - but very rapidly - bouncing off walls, other
 people and problems, until a workable solution is arrived at.
 
 this tends to scare the stuffing out of people who are used
 to measured well-thought-out and well-planned development :)

 so, beware!

 that having been said, this is pretty straightforward cut/paste
 job from chris's patch, it really couldn't get any simpler.

 l.

 p.s. has anyone considered doing a macro for these "pseudo" xattrs?
      or merging them into one bit of code?

      there are now THREE identical bits of code for the pseudo
	  xattrs, except for the names of the functions.


--
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: temporary hack to use udev in selinux

[James Morris]

On Thu, 29 Jul 2004, Luke Kenneth Casson Leighton wrote:

>  p.s. has anyone considered doing a macro for these "pseudo" xattrs?
>       or merging them into one bit of code?

Yes, I was looking at making a library but it didn't work out.  Macros 
may do the job, but I'm not sure how acceptable these would be upstream.

>       there are now THREE identical bits of code for the pseudo
> 	  xattrs, except for the names of the functions.

Some of this code is also identical in ext2/ext3.


- James
-- 
James Morris
<jmorris@redhat.com>



--
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: temporary hack to use udev in selinux

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

On Thu, 29 Jul 2004 13:04:45 EDT, James Morris said:
> On Thu, 29 Jul 2004, Luke Kenneth Casson Leighton wrote:
> 
> >  p.s. has anyone considered doing a macro for these "pseudo" xattrs?
> >       or merging them into one bit of code?
> 
> Yes, I was looking at making a library but it didn't work out.  Macros 
> may do the job, but I'm not sure how acceptable these would be upstream.

How hard would it be to recast them from macros to functions?

There's plenty of places where macro-sized pieces of code are done
with 'static inline foo()' - look in include/linux/fs.h for
plenty of examples.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: temporary hack to use udev in selinux

[Stephen Smalley]

On Wed, 2004-07-28 at 20:29, Joshua Brindle wrote:
> Chris PeBenito made this patch for Gentoo when we were evalutating udev 
> on selinux
> 
> http://dev.gentoo.org/~method/1330_linux-2.6.5-ramfs-xattr.patch

Why wasn't this submitted upstream?  ramfs xattr support (and likewise
for other pseudo fs's like tmpfs) has been on our todo list for some
time.

> that should patch cleanly into 2.6.7, but I'd like to note that at this 
> point udev is braindead wrt SELinux.
> Once upon a time udev had selinux support integrated so that setfscreate 
> was called to set the context of the devices being written however it 
> was changed at some point to make SELinux an after device creation addon 
> script which makes it label the devices after they are created. Because 
> of this Hardened Gentoo has decided not to support udev at this time.

I haven't tried udev myself, but I think Dan has used it successfully
with SELinux.  I'd agree that having udev directly call matchpathcon()
and then setfscreatecon() prior to node creation would be preferable,
but I'm not sure that it is strictly necessary - as long as the default
creation type is suitably restrictive and nothing tries to access it
prior to the restorecon.

-- 
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: temporary hack to use udev in selinux

[Luke Kenneth Casson Leighton]

On Thu, Jul 29, 2004 at 08:43:28AM -0400, Stephen Smalley wrote:

> > that should patch cleanly into 2.6.7, but I'd like to note that at this 
> > point udev is braindead wrt SELinux.
> > Once upon a time udev had selinux support integrated so that setfscreate 
> > was called to set the context of the devices being written however it 
> > was changed at some point to make SELinux an after device creation addon 
> > script which makes it label the devices after they are created. Because 
> > of this Hardened Gentoo has decided not to support udev at this time.
> 
> I haven't tried udev myself, but I think Dan has used it successfully
> with SELinux.  

 also i've successfully got it to work under Debian (unstable) with
 my lovely 2.6.6-selinux1 kernel.

 i had to modify the file_contexts/types.fc file to that
 /.?u?dev/.... on every line because without that, if you
 run make relabel, it destroys all the permissions in the
 "old" /dev (which are remapped to /.dev when udev has control
 of /dev) and consequently you can't boot the machine [the "old"
 /dev is used on boot, of course, prior to udev being run].


 i don't know what dan has done, nor what fedora does, whether
 they use /udev for what debian uses /.dev for.

 looking at /etc/init.d/udev, it's probably something debian-specific,
 to be honest.

 also, something to watch out for: the /etc/init.d/udev from debian
 (0.030 this is) creates some directories and some symlinks and
 a couple of nodes (listed in /etc/udev/links.conf).

 /dev/pts and /dev/shm are both created.

 now, i don't know what happens, or what's supposed to happen, but
 i don't see a lot of restorecon action going onto those "horrible
 hack" locations.

 but hey, it seems to work.

> I'd agree that having udev directly call matchpathcon()
> and then setfscreatecon() prior to node creation would be preferable,
> but I'm not sure that it is strictly necessary - as long as the default
> creation type is suitably restrictive and nothing tries to access it
> prior to the restorecon.
 
 :)

 well, the design of udev is such that it's totally full of race
 conditions, and access between the creation and the restorecon
 is going to be the _least_ of a user's worries.

 i don't know what the default is.


 so, when that matchpathcon() and setfscreatecon() is called,
 does it:
 
 a ) guarantee that the device node "to be created" will be set with
     the correct se/linux permissions

 b ) update the selinux permissions post-creation.

 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: temporary hack to use udev in selinux

[Stephen Smalley]

On Thu, 2004-07-29 at 09:53, Luke Kenneth Casson Leighton wrote:
>  i don't know what the default is.

Unless there is a file_type_auto_trans() rule, the default is to inherit
the type from the parent directory, i.e. device_t.  Access to
device_t:{chr_file blk_file} should be quite restricted, so this should
be safe.

>  so, when that matchpathcon() and setfscreatecon() is called,
>  does it:
>  
>  a ) guarantee that the device node "to be created" will be set with
>      the correct se/linux permissions

Yes.  setfscreatecon() tells the kernel to create new files in a given
security context, as opposed to having to relabel afterward.

-- 
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: temporary hack to use udev in selinux

[Stephen Smalley]

On Wed, 2004-07-28 at 19:20, Luke Kenneth Casson Leighton wrote:
> fighting with it for a day, and after seeing some clues in the
> file contexts (/(u)dev/....) i decided to try editing
> /etc/udev/udev.conf to set it to use /udev instead of /dev.

I don't know which policy version you are using, but in the current
policy, the regexes are of the form "/u?dev", so it works with either a
/dev or /udev.  Requires using a xattr-supporting filesystem for udev,
naturally.

-- 
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: temporary hack to use udev in selinux

[Luke Kenneth Casson Leighton]

On Thu, Jul 29, 2004 at 08:36:41AM -0400, Stephen Smalley wrote:
> On Wed, 2004-07-28 at 19:20, Luke Kenneth Casson Leighton wrote:
> > fighting with it for a day, and after seeing some clues in the
> > file contexts (/(u)dev/....) i decided to try editing
> > /etc/udev/udev.conf to set it to use /udev instead of /dev.
> 
> I don't know which policy version you are using, but in the current
> policy, the regexes are of the form "/u?dev", so it works with either a
> /dev or /udev.  Requires using a xattr-supporting filesystem for udev,
> naturally.
 
 as i mention in my previous post, /.dev is the location that the
 debian maintainer has chosen to re-mount the "old" /dev which will
 have been hidden by udev.

 consequently, because /.dev is not listed in file_contexts/types.fc,
 all permissions get destroyed to system_u:object_r:default_t.

 on next boot, /sbin/init is denied access to /dev/hda2, my root
 partition!!!

 adding in /.?u?dev into the regex fixes the problem [ItWorksForMe(tm)]

 hey, maybe it should be /\.u?dev/.
 
 i didn't say i was any _good_ at writing regexes.
 
 [25 years of doing computer programming and i still avoid
 them as much as i can.]

 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.