[idea] udev + selinux

[idea] udev + selinux

[Nigel Kukard]

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

Just an idea, but why not have udev set the context on its root path?

I have a simplistic patch for this if its a good idea.


Regards
Nigel Kukard

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

[idea] udev + selinux

[Nigel Kukard]

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

Just an idea, but why not have udev set the context on its root path?

I have a simplistic patch for this if its a good idea.


Regards
Nigel Kukard

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

Re: [idea] udev + selinux

[Luke Kenneth Casson Leighton]

On Mon, Aug 30, 2004 at 07:37:44PM +0200, Nigel Kukard wrote:
> Just an idea, but why not have udev set the context on its root path?
 
 you mean on /dev, i presume?

 well i had to patch selinux/hooks.c to allow this [on a tmpfs]
 by relaxing the criteria of the "fscontext=" option for mount.

 otherwise it's not _possible_ t set the context on /dev as it is
 mounted [on a tmpfs].

 [if /dev was a persistent filesystem everything would be hunky-dory
  and this wouldn't be an issue].


 with that in mind, it's more that because you're putting device
 inodes into a non-persistent filesystem, you end up getting the
 "default" rules and so you must "restore" the contexts, or
 you must patch udev to "understand" the contents of
 /etc/selinux/src/file_contexts/file_contexts (using matchpathcon()
 and setfscreatecon() from libselinux) such that it will create
 inodes with the right file context.

 like i said, if /dev was a persistent filesystem, and if device
 inodes never disappeared, this wouldn't be a problem: you could run
 setfiles /etc/selinux/src/file_contexts/file_contexts /dev and
 be done with it...

 ... but that's not how udev works: it deletes and creates inodes
 on demand; nothing exists at boot-time, it's all created on-demand.

 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.

 _including_ dealing with getting the contexts correct on entries
 in /.dev [the old /dev remounted with mount --rbind]

 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 SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [idea] udev + selinux

[Luke Kenneth Casson Leighton]

On Mon, Aug 30, 2004 at 07:37:44PM +0200, Nigel Kukard wrote:
> Just an idea, but why not have udev set the context on its root path?
 
 you mean on /dev, i presume?

 well i had to patch selinux/hooks.c to allow this [on a tmpfs]
 by relaxing the criteria of the "fscontext=" option for mount.

 otherwise it's not _possible_ t set the context on /dev as it is
 mounted [on a tmpfs].

 [if /dev was a persistent filesystem everything would be hunky-dory
  and this wouldn't be an issue].


 with that in mind, it's more that because you're putting device
 inodes into a non-persistent filesystem, you end up getting the
 "default" rules and so you must "restore" the contexts, or
 you must patch udev to "understand" the contents of
 /etc/selinux/src/file_contexts/file_contexts (using matchpathcon()
 and setfscreatecon() from libselinux) such that it will create
 inodes with the right file context.

 like i said, if /dev was a persistent filesystem, and if device
 inodes never disappeared, this wouldn't be a problem: you could run
 setfiles /etc/selinux/src/file_contexts/file_contexts /dev and
 be done with it...

 ... but that's not how udev works: it deletes and creates inodes
 on demand; nothing exists at boot-time, it's all created on-demand.

 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.

 _including_ dealing with getting the contexts correct on entries
 in /.dev [the old /dev remounted with mount --rbind]

 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: [idea] udev + selinux

[Nigel Kukard]

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

>  you mean on /dev, i presume?

yep, or /udev (configured in the udev config file)

> 
>  well i had to patch selinux/hooks.c to allow this [on a tmpfs]
>  by relaxing the criteria of the "fscontext=" option for mount.
> 

if its tmpfs, this would void the requirement of passing a mount option
fscontext, udev would set the correct context when started up (a check
could also be added to do this only if the mount point is /dev and its
tmpfs... *shrug*)

>  otherwise it's not _possible_ t set the context on /dev as it is
>  mounted [on a tmpfs].
> 
>  [if /dev was a persistent filesystem everything would be hunky-dory
>   and this wouldn't be an issue].
>

*nod*

> 
>  with that in mind, it's more that because you're putting device
>  inodes into a non-persistent filesystem, you end up getting the
>  "default" rules and so you must "restore" the contexts, or
>  you must patch udev to "understand" the contents of
>  /etc/selinux/src/file_contexts/file_contexts (using matchpathcon()
>  and setfscreatecon() from libselinux) such that it will create
>  inodes with the right file context.
>

I applied the patch to tmpfs to make it store xattr attributes which i
found on the mailing list, seems your patch forgets xattr.h?

I also applied the patch which adds  "matchpathcon()" & 
"setfscreatecon()" support, and modified udev to set the correct 
context of its root_path on startup.
 
>  ... but that's not how udev works: it deletes and creates inodes
>  on demand; nothing exists at boot-time, it's all created on-demand.

at boot time i have about 5 devices in /dev with correct contexts set,
udev them mounts tmpfs over this, WorksForMe(tm)

so in actual fact we do need matchpathcon() & setfscreatecon(), if its a
persistent or non-persistent filesystem

> 
>  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) just 
after sysctl -p is run in my initscripts so its basically one of the 
first things to run. Seeing as my initial /dev is on a persistent 
filesystem i don't have a problem with pre-udev stuff running.

> 
>  _including_ dealing with getting the contexts correct on entries
>  in /.dev [the old /dev remounted with mount --rbind]
> 
>  l.
> 
> 

-- 
Nigel Kukard, PhD CompSc
(Chief Executive Officer)
Linux Based Systems Design (Non-Profit)
Web: www.lbsd.net          Email: nkukard@lbsd.net
Tel: (+27) 023 349 8000     Cell: (+27) 082 333 3723
Fax: (+27) 023 349 1395  Support: 086 747 7600
Address: LIGT House, 2 Klipdrift Rd, Rawsonville
Linux Systems Design & Technology Solutions


   The best language to use is the language that was designed for
                  what you want to use it for.


=====================================================================

Disclaimer
----------
The contents of this message and any attachments are intended 
solely for the addressee's use and may be legally privileged and/or 
confidential information. This message may not be retained, 
distributed, copied or used if you are not he addressee of this 
message. If this message was sent to you in error, please notify 
the sender immediately by reply e-mail and then destroy the message 
and any copies thereof.

Opinions, conclusions and other information in this message may be 
personal to the sender and is not that of Linux Based Systems Design,
LinuxRulz or any of it's subsideries, associated companies or 
principals and is therefore not endorsed by Linux Based Systems 
Design or LinuxRulz. Due to e-maill communication being insecure, 
Linux Based Systems Design and LinuxRulz do not guarantee 
confidentiality, security, accuracy or performance of the e-mail. 
Any liability for viruses is excluded to the fullest extent.

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

Re: [idea] udev + selinux

[Nigel Kukard]

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

>  you mean on /dev, i presume?

yep, or /udev (configured in the udev config file)

> 
>  well i had to patch selinux/hooks.c to allow this [on a tmpfs]
>  by relaxing the criteria of the "fscontext=" option for mount.
> 

if its tmpfs, this would void the requirement of passing a mount option
fscontext, udev would set the correct context when started up (a check
could also be added to do this only if the mount point is /dev and its
tmpfs... *shrug*)

>  otherwise it's not _possible_ t set the context on /dev as it is
>  mounted [on a tmpfs].
> 
>  [if /dev was a persistent filesystem everything would be hunky-dory
>   and this wouldn't be an issue].
>

*nod*

> 
>  with that in mind, it's more that because you're putting device
>  inodes into a non-persistent filesystem, you end up getting the
>  "default" rules and so you must "restore" the contexts, or
>  you must patch udev to "understand" the contents of
>  /etc/selinux/src/file_contexts/file_contexts (using matchpathcon()
>  and setfscreatecon() from libselinux) such that it will create
>  inodes with the right file context.
>

I applied the patch to tmpfs to make it store xattr attributes which i
found on the mailing list, seems your patch forgets xattr.h?

I also applied the patch which adds  "matchpathcon()" & 
"setfscreatecon()" support, and modified udev to set the correct 
context of its root_path on startup.
 
>  ... but that's not how udev works: it deletes and creates inodes
>  on demand; nothing exists at boot-time, it's all created on-demand.

at boot time i have about 5 devices in /dev with correct contexts set,
udev them mounts tmpfs over this, WorksForMe(tm)

so in actual fact we do need matchpathcon() & setfscreatecon(), if its a
persistent or non-persistent filesystem

> 
>  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) just 
after sysctl -p is run in my initscripts so its basically one of the 
first things to run. Seeing as my initial /dev is on a persistent 
filesystem i don't have a problem with pre-udev stuff running.

> 
>  _including_ dealing with getting the contexts correct on entries
>  in /.dev [the old /dev remounted with mount --rbind]
> 
>  l.
> 
> 

-- 
Nigel Kukard, PhD CompSc
(Chief Executive Officer)
Linux Based Systems Design (Non-Profit)
Web: www.lbsd.net          Email: nkukard@lbsd.net
Tel: (+27) 023 349 8000     Cell: (+27) 082 333 3723
Fax: (+27) 023 349 1395  Support: 086 747 7600
Address: LIGT House, 2 Klipdrift Rd, Rawsonville
Linux Systems Design & Technology Solutions


   The best language to use is the language that was designed for
                  what you want to use it for.


=====================================================================

Disclaimer
----------
The contents of this message and any attachments are intended 
solely for the addressee's use and may be legally privileged and/or 
confidential information. This message may not be retained, 
distributed, copied or used if you are not he addressee of this 
message. If this message was sent to you in error, please notify 
the sender immediately by reply e-mail and then destroy the message 
and any copies thereof.

Opinions, conclusions and other information in this message may be 
personal to the sender and is not that of Linux Based Systems Design,
LinuxRulz or any of it's subsideries, associated companies or 
principals and is therefore not endorsed by Linux Based Systems 
Design or LinuxRulz. Due to e-maill communication being insecure, 
Linux Based Systems Design and LinuxRulz do not guarantee 
confidentiality, security, accuracy or performance of the e-mail. 
Any liability for viruses is excluded to the fullest extent.

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

Re: [idea] udev + selinux

[Luke Kenneth Casson Leighton]

On Tue, Aug 31, 2004 at 07:02:52AM +0200, Nigel Kukard wrote:
> >  you mean on /dev, i presume?
> 
> yep, or /udev (configured in the udev config file)
 
 oh.

 yes.

 redhat :)

> > 
> >  well i had to patch selinux/hooks.c to allow this [on a tmpfs]
> >  by relaxing the criteria of the "fscontext=" option for mount.
> > 
> 
> if its tmpfs, this would void the requirement of passing a mount option
> fscontext, udev would set the correct context when started up (a check
> could also be added to do this only if the mount point is /dev and its
> tmpfs... *shrug*)
> 
> >  otherwise it's not _possible_ t set the context on /dev as it is
> >  mounted [on a tmpfs].
> > 
> >  [if /dev was a persistent filesystem everything would be hunky-dory
> >   and this wouldn't be an issue].
> >
> 
> *nod*
> 
> > 
> >  with that in mind, it's more that because you're putting device
> >  inodes into a non-persistent filesystem, you end up getting the
> >  "default" rules and so you must "restore" the contexts, or
> >  you must patch udev to "understand" the contents of
> >  /etc/selinux/src/file_contexts/file_contexts (using matchpathcon()
> >  and setfscreatecon() from libselinux) such that it will create
> >  inodes with the right file context.
> >
> 
> I applied the patch to tmpfs to make it store xattr attributes which i
> found on the mailing list, seems your patch forgets xattr.h?

 ??  oops.

 okay, i had put it at http://www.hands.com/~lkcl/selinux/2.6.6/
 and when i posted copies to the list i must have missed it out.

 if you _do_ know how to properly create patches that other people
 can apply simply, that'd be great.

> I also applied the patch which adds  "matchpathcon()" & 
> "setfscreatecon()" support, 

 dan is working on a new version of that, for udev-0.030-10.


> and modified udev to set the correct 
> context of its root_path on startup.

 mount -o fscontext=system_u:object_r:device_t yes?

 did you patch selinux/hooks.c to relax the constraints on
 the fscontext= parameter to allow the correct context to be
 correctly applied?  :)


> >  ... but that's not how udev works: it deletes and creates inodes
> >  on demand; nothing exists at boot-time, it's all created on-demand.
> 
> at boot time i have about 5 devices in /dev with correct contexts set,
> udev them mounts tmpfs over this, WorksForMe(tm)
> 
> so in actual fact we do need matchpathcon() & setfscreatecon(), if its a
> persistent or non-persistent filesystem

 yep.

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

> just 
> after sysctl -p is run in my initscripts so its basically one of the 
> first things to run. 

 yep.

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

 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.

 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.

 should you choose to deal with this, replace /u?dev with /[\.u]dev or
 some suitable regexp that i haven't a clue how to write so i just
 did /.?u?dev and that did the trick.


 the only _other_ thing you might find is that things like dialup
 don't or won't have been loaded.

 so i had to add in a _second_ version of /etc/init.d/modutils which
 does exactly the same as /etc/init.d/modutils ... but with a different
 list of modules, and AFTER udev has been run, not before.

 the list i have so far in /etc/modules.postudev contains (for my purposes):

 ppp_generic
 nvidia
 sg

 ppp_generic is there because "pon provider" bitches about /dev/ppp
 not existing

 sg is there because of usb-mount using sg_mod: if the module is
 pre-loaded, then /dev/sg0 gets created by udev.

 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.

 ... but certainly, _some_ modules haven't been modified to conform
 to the new /sys thing.


 the "trick" of a node in /dev existing, and its first access
 automatically triggering a modprobe... well that only works if
 the node is there, and of course with udev, it isn't.

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

 l.




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [idea] udev + selinux

[Luke Kenneth Casson Leighton]

On Tue, Aug 31, 2004 at 07:02:52AM +0200, Nigel Kukard wrote:
> >  you mean on /dev, i presume?
> 
> yep, or /udev (configured in the udev config file)
 
 oh.

 yes.

 redhat :)

> > 
> >  well i had to patch selinux/hooks.c to allow this [on a tmpfs]
> >  by relaxing the criteria of the "fscontext=" option for mount.
> > 
> 
> if its tmpfs, this would void the requirement of passing a mount option
> fscontext, udev would set the correct context when started up (a check
> could also be added to do this only if the mount point is /dev and its
> tmpfs... *shrug*)
> 
> >  otherwise it's not _possible_ t set the context on /dev as it is
> >  mounted [on a tmpfs].
> > 
> >  [if /dev was a persistent filesystem everything would be hunky-dory
> >   and this wouldn't be an issue].
> >
> 
> *nod*
> 
> > 
> >  with that in mind, it's more that because you're putting device
> >  inodes into a non-persistent filesystem, you end up getting the
> >  "default" rules and so you must "restore" the contexts, or
> >  you must patch udev to "understand" the contents of
> >  /etc/selinux/src/file_contexts/file_contexts (using matchpathcon()
> >  and setfscreatecon() from libselinux) such that it will create
> >  inodes with the right file context.
> >
> 
> I applied the patch to tmpfs to make it store xattr attributes which i
> found on the mailing list, seems your patch forgets xattr.h?

 ??  oops.

 okay, i had put it at http://www.hands.com/~lkcl/selinux/2.6.6/
 and when i posted copies to the list i must have missed it out.

 if you _do_ know how to properly create patches that other people
 can apply simply, that'd be great.

> I also applied the patch which adds  "matchpathcon()" & 
> "setfscreatecon()" support, 

 dan is working on a new version of that, for udev-0.030-10.


> and modified udev to set the correct 
> context of its root_path on startup.

 mount -o fscontext=system_u:object_r:device_t yes?

 did you patch selinux/hooks.c to relax the constraints on
 the fscontext= parameter to allow the correct context to be
 correctly applied?  :)


> >  ... but that's not how udev works: it deletes and creates inodes
> >  on demand; nothing exists at boot-time, it's all created on-demand.
> 
> at boot time i have about 5 devices in /dev with correct contexts set,
> udev them mounts tmpfs over this, WorksForMe(tm)
> 
> so in actual fact we do need matchpathcon() & setfscreatecon(), if its a
> persistent or non-persistent filesystem

 yep.

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

> just 
> after sysctl -p is run in my initscripts so its basically one of the 
> first things to run. 

 yep.

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

 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.

 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.

 should you choose to deal with this, replace /u?dev with /[\.u]dev or
 some suitable regexp that i haven't a clue how to write so i just
 did /.?u?dev and that did the trick.


 the only _other_ thing you might find is that things like dialup
 don't or won't have been loaded.

 so i had to add in a _second_ version of /etc/init.d/modutils which
 does exactly the same as /etc/init.d/modutils ... but with a different
 list of modules, and AFTER udev has been run, not before.

 the list i have so far in /etc/modules.postudev contains (for my purposes):

 ppp_generic
 nvidia
 sg

 ppp_generic is there because "pon provider" bitches about /dev/ppp
 not existing

 sg is there because of usb-mount using sg_mod: if the module is
 pre-loaded, then /dev/sg0 gets created by udev.

 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.

 ... but certainly, _some_ modules haven't been modified to conform
 to the new /sys thing.


 the "trick" of a node in /dev existing, and its first access
 automatically triggering a modprobe... well that only works if
 the node is there, and of course with udev, it isn't.

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

 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: [idea] udev + selinux

[Nigel Kukard]

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

On Tue, Aug 31, 2004 at 10:49:08AM +0100, Luke Kenneth Casson Leighton wrote:
> > yep, or /udev (configured in the udev config file)
>  
>  oh.
> 
>  yes.
> 
>  redhat :)

no... it just depends how you want it configured ;-)


> > I applied the patch to tmpfs to make it store xattr attributes which i
> > found on the mailing list, seems your patch forgets xattr.h?
> 
>  ??  oops.
> 
>  okay, i had put it at http://www.hands.com/~lkcl/selinux/2.6.6/
>  and when i posted copies to the list i must have missed it out.
> 
>  if you _do_ know how to properly create patches that other people
>  can apply simply, that'd be great.
> 

*nod*, i'm pondering creating the patches... let me see what i can do


> > I also applied the patch which adds  "matchpathcon()" & 
> > "setfscreatecon()" support, 
> 
>  dan is working on a new version of that, for udev-0.030-10.
> 

cool, that will at least remove 1 patch out my build tree


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

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

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

>  should you choose to deal with this, replace /u?dev with /[\.u]dev or
>  some suitable regexp that i haven't a clue how to write so i just
>  did /.?u?dev and that did the trick.
> 

thats a good idea  ;-), although in "my" case didn't need it.

> 
>  the only _other_ thing you might find is that things like dialup
>  don't or won't have been loaded.
>

i don't have any problems with this  ;-)
 
>  so i had to add in a _second_ version of /etc/init.d/modutils which
>  does exactly the same as /etc/init.d/modutils ... but with a different
>  list of modules, and AFTER udev has been run, not before.
> 
>  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 ;-)

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
[root@localhost.localdomain policy]# ls -Z /dev/ppp
crw-------  root     root     system_u:object_r:ppp_device_t   /dev/ppp
[root@localhost.localdomain policy]#

>  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!  ;-)

just writing a few security policies

-- 
Nigel Kukard, PhD CompSc
(Chief Executive Officer)
Linux Based Systems Design (Non-Profit)
Web: www.lbsd.net          Email: nkukard@lbsd.net
Tel: (+27) 023 349 8000     Cell: (+27) 082 333 3723
Fax: (+27) 023 349 1395  Support: 086 747 7600
Address: LIGT House, 2 Klipdrift Rd, Rawsonville
Linux Systems Design & Technology Solutions


   The best language to use is the language that was designed for
                  what you want to use it for.


=====================================================================

Disclaimer
----------
The contents of this message and any attachments are intended 
solely for the addressee's use and may be legally privileged and/or 
confidential information. This message may not be retained, 
distributed, copied or used if you are not he addressee of this 
message. If this message was sent to you in error, please notify 
the sender immediately by reply e-mail and then destroy the message 
and any copies thereof.

Opinions, conclusions and other information in this message may be 
personal to the sender and is not that of Linux Based Systems Design,
LinuxRulz or any of it's subsideries, associated companies or 
principals and is therefore not endorsed by Linux Based Systems 
Design or LinuxRulz. Due to e-maill communication being insecure, 
Linux Based Systems Design and LinuxRulz do not guarantee 
confidentiality, security, accuracy or performance of the e-mail. 
Any liability for viruses is excluded to the fullest extent.

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

Re: [idea] udev + selinux

[Nigel Kukard]

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

On Tue, Aug 31, 2004 at 10:49:08AM +0100, Luke Kenneth Casson Leighton wrote:
> > yep, or /udev (configured in the udev config file)
>  
>  oh.
> 
>  yes.
> 
>  redhat :)

no... it just depends how you want it configured ;-)


> > I applied the patch to tmpfs to make it store xattr attributes which i
> > found on the mailing list, seems your patch forgets xattr.h?
> 
>  ??  oops.
> 
>  okay, i had put it at http://www.hands.com/~lkcl/selinux/2.6.6/
>  and when i posted copies to the list i must have missed it out.
> 
>  if you _do_ know how to properly create patches that other people
>  can apply simply, that'd be great.
> 

*nod*, i'm pondering creating the patches... let me see what i can do


> > I also applied the patch which adds  "matchpathcon()" & 
> > "setfscreatecon()" support, 
> 
>  dan is working on a new version of that, for udev-0.030-10.
> 

cool, that will at least remove 1 patch out my build tree


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

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

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

>  should you choose to deal with this, replace /u?dev with /[\.u]dev or
>  some suitable regexp that i haven't a clue how to write so i just
>  did /.?u?dev and that did the trick.
> 

thats a good idea  ;-), although in "my" case didn't need it.

> 
>  the only _other_ thing you might find is that things like dialup
>  don't or won't have been loaded.
>

i don't have any problems with this  ;-)
 
>  so i had to add in a _second_ version of /etc/init.d/modutils which
>  does exactly the same as /etc/init.d/modutils ... but with a different
>  list of modules, and AFTER udev has been run, not before.
> 
>  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 ;-)

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
[root@localhost.localdomain policy]# ls -Z /dev/ppp
crw-------  root     root     system_u:object_r:ppp_device_t   /dev/ppp
[root@localhost.localdomain policy]#

>  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!  ;-)

just writing a few security policies

-- 
Nigel Kukard, PhD CompSc
(Chief Executive Officer)
Linux Based Systems Design (Non-Profit)
Web: www.lbsd.net          Email: nkukard@lbsd.net
Tel: (+27) 023 349 8000     Cell: (+27) 082 333 3723
Fax: (+27) 023 349 1395  Support: 086 747 7600
Address: LIGT House, 2 Klipdrift Rd, Rawsonville
Linux Systems Design & Technology Solutions


   The best language to use is the language that was designed for
                  what you want to use it for.


=====================================================================

Disclaimer
----------
The contents of this message and any attachments are intended 
solely for the addressee's use and may be legally privileged and/or 
confidential information. This message may not be retained, 
distributed, copied or used if you are not he addressee of this 
message. If this message was sent to you in error, please notify 
the sender immediately by reply e-mail and then destroy the message 
and any copies thereof.

Opinions, conclusions and other information in this message may be 
personal to the sender and is not that of Linux Based Systems Design,
LinuxRulz or any of it's subsideries, associated companies or 
principals and is therefore not endorsed by Linux Based Systems 
Design or LinuxRulz. Due to e-maill communication being insecure, 
Linux Based Systems Design and LinuxRulz do not guarantee 
confidentiality, security, accuracy or performance of the e-mail. 
Any liability for viruses is excluded to the fullest extent.

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

Re: [idea] udev + selinux

[Luke Kenneth Casson Leighton]

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.



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [idea] udev + selinux

[Luke Kenneth Casson Leighton]

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.


--
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: [idea] udev + selinux

[Luke Kenneth Casson Leighton]

On Tue, Aug 31, 2004 at 10:49:08AM +0100, Luke Kenneth Casson Leighton wrote:

> > 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].
> 
>  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.
> 
>  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.
> 
>  should you choose to deal with this, replace /u?dev with /[\.u]dev or
>  some suitable regexp that i haven't a clue how to write so i just
>  did /.?u?dev and that did the trick.
 
 it's insufficient to add /.?u?dev to just file_contexts/types.fc
 you also have to search in file_contexts/program/* for /dev
 and set the right context there, too.

 there is i believe a bug at present in
 e.g. file_contexts/program/init.fc because it only covers
 /dev/initctl not /udev/initctl and not /.dev/initctl.

 i think this one is the only one that's really really critical
 [except on redhat of course where they all should be /u?dev]
 because if /.dev/initctl gets set to default_t, you're stuffed
 at next boot.

 l.



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [idea] udev + selinux

[Luke Kenneth Casson Leighton]

On Tue, Aug 31, 2004 at 10:49:08AM +0100, Luke Kenneth Casson Leighton wrote:

> > 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].
> 
>  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.
> 
>  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.
> 
>  should you choose to deal with this, replace /u?dev with /[\.u]dev or
>  some suitable regexp that i haven't a clue how to write so i just
>  did /.?u?dev and that did the trick.
 
 it's insufficient to add /.?u?dev to just file_contexts/types.fc
 you also have to search in file_contexts/program/* for /dev
 and set the right context there, too.

 there is i believe a bug at present in
 e.g. file_contexts/program/init.fc because it only covers
 /dev/initctl not /udev/initctl and not /.dev/initctl.

 i think this one is the only one that's really really critical
 [except on redhat of course where they all should be /u?dev]
 because if /.dev/initctl gets set to default_t, you're stuffed
 at next boot.

 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: [idea] udev + selinux

[Luke Kenneth Casson Leighton]

On Mon, Aug 30, 2004 at 07:37:44PM +0200, Nigel Kukard wrote:
> Just an idea, but why not have udev set the context on its root path?
> 
> I have a simplistic patch for this if its a good idea.

 ah ha.  very funny.

 now i have re-read what you've said, now that i have enough
 background based on your further explanations in this thread,
 _now_ i have enough context to understand your question.

 okay.

 let me reiterate what i believe you have said.

 you have patched the program udev (0.030-10?)

 [and yes, i would highly recommend sending it to the list(s)
 to make it clear what you mean].

 this patch will run, when it starts up, a call to setfilecon()
 on /dev (or /udev, or whatever the mount point of the devfs is).

 and _just_ on "/dev".

 yes?

 and it's done BEFORE any inodes are EVER created in the new
 /dev, yes?


 assuming yes, then it kinda-solves the need for doing that hacked-up
 relaxed-constraints-patch-to-hooks.c fscontext= option.

 why? because you can mount -t tmpfs /dev blah blah and you don't 
 care what the context is because udev will set the correct one
 when it runs.


 that is - of course - assuming that file_contexts/file_contexts
 _contains_ the correct file context for /dev.


 it might make (i dunno) for a simpler policy.

 what i mean is, have you had to add in the modifications to the
 selinux policy that i sent to the lists last week?

 e.g. these:

	 allow udev_tbl_t device_t:filesystem { associate };
	 allow initctl_t device_t:filesystem { associate };

 and these:

	 +# needed for udev-mounted (/dev) tmpfs
	 +allow $1_tty_device_t device_t:filesystem { associate };
	 +
	 +# to allow users to run df on udev-mounted (/dev) tmpfs
	 +allow $1_t device_t:filesystem { getattr };
	 +   #EXE=/bin/df  NAME=/   :  getattr
	 +

 these are all there for reasons i cannot entirely fathom but
 it starts, in types/file.te, with this:

 	allow { device_type } device_t:filesystem associate;

 which is all because of this:
 
 	mount tmpfs -o fscontext=system_u:object_r:device_t /dev

 
 anyway what i am saying is that if you HAVE NOT got all these patches
 in your selinux policy files, then your approach has distinct
 advantages: less mods to the policy files and less differences between
 a persistent and non-persistent udev filesystem.


 other than that, my intuition is saying "i don't like it" and what that
 means is that in about two or three weeks i will be able to articulate
 clearly and precisely why i don't think it's a good idea.

 it'll likely be something to do with your solution being a two-step
 operation whereas the hacked-up-relaxed-fscontext-hooks.c things is
 a one-step (atomic?)  operation.

 l.



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [idea] udev + selinux

[Luke Kenneth Casson Leighton]

On Mon, Aug 30, 2004 at 07:37:44PM +0200, Nigel Kukard wrote:
> Just an idea, but why not have udev set the context on its root path?
> 
> I have a simplistic patch for this if its a good idea.

 ah ha.  very funny.

 now i have re-read what you've said, now that i have enough
 background based on your further explanations in this thread,
 _now_ i have enough context to understand your question.

 okay.

 let me reiterate what i believe you have said.

 you have patched the program udev (0.030-10?)

 [and yes, i would highly recommend sending it to the list(s)
 to make it clear what you mean].

 this patch will run, when it starts up, a call to setfilecon()
 on /dev (or /udev, or whatever the mount point of the devfs is).

 and _just_ on "/dev".

 yes?

 and it's done BEFORE any inodes are EVER created in the new
 /dev, yes?


 assuming yes, then it kinda-solves the need for doing that hacked-up
 relaxed-constraints-patch-to-hooks.c fscontext= option.

 why? because you can mount -t tmpfs /dev blah blah and you don't 
 care what the context is because udev will set the correct one
 when it runs.


 that is - of course - assuming that file_contexts/file_contexts
 _contains_ the correct file context for /dev.


 it might make (i dunno) for a simpler policy.

 what i mean is, have you had to add in the modifications to the
 selinux policy that i sent to the lists last week?

 e.g. these:

	 allow udev_tbl_t device_t:filesystem { associate };
	 allow initctl_t device_t:filesystem { associate };

 and these:

	 +# needed for udev-mounted (/dev) tmpfs
	 +allow $1_tty_device_t device_t:filesystem { associate };
	 +
	 +# to allow users to run df on udev-mounted (/dev) tmpfs
	 +allow $1_t device_t:filesystem { getattr };
	 +   #EXE=/bin/df  NAME=/   :  getattr
	 +

 these are all there for reasons i cannot entirely fathom but
 it starts, in types/file.te, with this:

 	allow { device_type } device_t:filesystem associate;

 which is all because of this:
 
 	mount tmpfs -o fscontext=system_u:object_r:device_t /dev

 
 anyway what i am saying is that if you HAVE NOT got all these patches
 in your selinux policy files, then your approach has distinct
 advantages: less mods to the policy files and less differences between
 a persistent and non-persistent udev filesystem.


 other than that, my intuition is saying "i don't like it" and what that
 means is that in about two or three weeks i will be able to articulate
 clearly and precisely why i don't think it's a good idea.

 it'll likely be something to do with your solution being a two-step
 operation whereas the hacked-up-relaxed-fscontext-hooks.c things is
 a one-step (atomic?)  operation.

 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: [idea] udev + selinux

[Nigel Kukard]

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

>  you have patched the program udev (0.030-10?)
> 
>  [and yes, i would highly recommend sending it to the list(s)
>  to make it clear what you mean].
> 
>  this patch will run, when it starts up, a call to setfilecon()
>  on /dev (or /udev, or whatever the mount point of the devfs is).
> 
>  and _just_ on "/dev".
> 
>  yes?

correct

> 
>  and it's done BEFORE any inodes are EVER created in the new
>  /dev, yes?
> 

correct

> 
>  assuming yes, then it kinda-solves the need for doing that hacked-up
>  relaxed-constraints-patch-to-hooks.c fscontext= option.
> 

aha, u correct!!!!

>  why? because you can mount -t tmpfs /dev blah blah and you don't 
>  care what the context is because udev will set the correct one
>  when it runs.
> 
> 

perfect!!!!, so that solves the need for the hooks patch, which is in
actual fact wrong.

>  that is - of course - assuming that file_contexts/file_contexts
>  _contains_ the correct file context for /dev.
> 
> 

*nod*

>  it might make (i dunno) for a simpler policy.
> 

yep

>  what i mean is, have you had to add in the modifications to the
>  selinux policy that i sent to the lists last week?
> 
>  e.g. these:
> 
> 	 allow udev_tbl_t device_t:filesystem { associate };
> 	 allow initctl_t device_t:filesystem { associate };
> 
>  and these:
> 
> 	 +# needed for udev-mounted (/dev) tmpfs
> 	 +allow $1_tty_device_t device_t:filesystem { associate };
> 	 +
> 	 +# to allow users to run df on udev-mounted (/dev) tmpfs
> 	 +allow $1_t device_t:filesystem { getattr };
> 	 +   #EXE=/bin/df  NAME=/   :  getattr
> 	 +
> 

had to add quite a couple more, but i'm still working on that to make it
"correct"

>  these are all there for reasons i cannot entirely fathom but
>  it starts, in types/file.te, with this:
> 
>  	allow { device_type } device_t:filesystem associate;
> 

i need this aswell.... which is very interesting, so my "way of doing
it" doesn't solve this problem. i'll keep looking for the solution

>  which is all because of this:
>  
>  	mount tmpfs -o fscontext=system_u:object_r:device_t /dev
> 

this doesn't cause the problem, its something else

>  
>  anyway what i am saying is that if you HAVE NOT got all these patches
>  in your selinux policy files, then your approach has distinct
>  advantages: less mods to the policy files and less differences between
>  a persistent and non-persistent udev filesystem.
> 

correct, i'm still working on it though and it HAS TO BE COMPLETED
SOON!!!!

> 
>  other than that, my intuition is saying "i don't like it" and what that
>  means is that in about two or three weeks i will be able to articulate
>  clearly and precisely why i don't think it's a good idea.
>

*shrug*, just a different outlook, patching userspace instead of kernel
space
 
>  it'll likely be something to do with your solution being a two-step
>  operation whereas the hacked-up-relaxed-fscontext-hooks.c things is
>  a one-step (atomic?)  operation.
> 

kernel developers will very much not like to get patches unless for a
very good reason... *shrug*... guess i have the totally oposite outlook
than you, i've had quite a number of my patches go mainstream though

>  l.

-Nigel


-- 
Nigel Kukard, PhD CompSc
(Chief Executive Officer)
Linux Based Systems Design (Non-Profit)
Web: www.lbsd.net          Email: nkukard@lbsd.net
Tel: (+27) 023 349 8000     Cell: (+27) 082 333 3723
Fax: (+27) 023 349 1395  Support: 086 747 7600
Address: LIGT House, 2 Klipdrift Rd, Rawsonville
Linux Systems Design & Technology Solutions


   The best language to use is the language that was designed for
                  what you want to use it for.



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

Re: [idea] udev + selinux

[Nigel Kukard]

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

>  you have patched the program udev (0.030-10?)
> 
>  [and yes, i would highly recommend sending it to the list(s)
>  to make it clear what you mean].
> 
>  this patch will run, when it starts up, a call to setfilecon()
>  on /dev (or /udev, or whatever the mount point of the devfs is).
> 
>  and _just_ on "/dev".
> 
>  yes?

correct

> 
>  and it's done BEFORE any inodes are EVER created in the new
>  /dev, yes?
> 

correct

> 
>  assuming yes, then it kinda-solves the need for doing that hacked-up
>  relaxed-constraints-patch-to-hooks.c fscontext= option.
> 

aha, u correct!!!!

>  why? because you can mount -t tmpfs /dev blah blah and you don't 
>  care what the context is because udev will set the correct one
>  when it runs.
> 
> 

perfect!!!!, so that solves the need for the hooks patch, which is in
actual fact wrong.

>  that is - of course - assuming that file_contexts/file_contexts
>  _contains_ the correct file context for /dev.
> 
> 

*nod*

>  it might make (i dunno) for a simpler policy.
> 

yep

>  what i mean is, have you had to add in the modifications to the
>  selinux policy that i sent to the lists last week?
> 
>  e.g. these:
> 
> 	 allow udev_tbl_t device_t:filesystem { associate };
> 	 allow initctl_t device_t:filesystem { associate };
> 
>  and these:
> 
> 	 +# needed for udev-mounted (/dev) tmpfs
> 	 +allow $1_tty_device_t device_t:filesystem { associate };
> 	 +
> 	 +# to allow users to run df on udev-mounted (/dev) tmpfs
> 	 +allow $1_t device_t:filesystem { getattr };
> 	 +   #EXE=/bin/df  NAME=/   :  getattr
> 	 +
> 

had to add quite a couple more, but i'm still working on that to make it
"correct"

>  these are all there for reasons i cannot entirely fathom but
>  it starts, in types/file.te, with this:
> 
>  	allow { device_type } device_t:filesystem associate;
> 

i need this aswell.... which is very interesting, so my "way of doing
it" doesn't solve this problem. i'll keep looking for the solution

>  which is all because of this:
>  
>  	mount tmpfs -o fscontext=system_u:object_r:device_t /dev
> 

this doesn't cause the problem, its something else

>  
>  anyway what i am saying is that if you HAVE NOT got all these patches
>  in your selinux policy files, then your approach has distinct
>  advantages: less mods to the policy files and less differences between
>  a persistent and non-persistent udev filesystem.
> 

correct, i'm still working on it though and it HAS TO BE COMPLETED
SOON!!!!

> 
>  other than that, my intuition is saying "i don't like it" and what that
>  means is that in about two or three weeks i will be able to articulate
>  clearly and precisely why i don't think it's a good idea.
>

*shrug*, just a different outlook, patching userspace instead of kernel
space
 
>  it'll likely be something to do with your solution being a two-step
>  operation whereas the hacked-up-relaxed-fscontext-hooks.c things is
>  a one-step (atomic?)  operation.
> 

kernel developers will very much not like to get patches unless for a
very good reason... *shrug*... guess i have the totally oposite outlook
than you, i've had quite a number of my patches go mainstream though

>  l.

-Nigel


-- 
Nigel Kukard, PhD CompSc
(Chief Executive Officer)
Linux Based Systems Design (Non-Profit)
Web: www.lbsd.net          Email: nkukard@lbsd.net
Tel: (+27) 023 349 8000     Cell: (+27) 082 333 3723
Fax: (+27) 023 349 1395  Support: 086 747 7600
Address: LIGT House, 2 Klipdrift Rd, Rawsonville
Linux Systems Design & Technology Solutions


   The best language to use is the language that was designed for
                  what you want to use it for.



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

Re: [idea] udev + selinux

[Luke Kenneth Casson Leighton]

On Tue, Aug 31, 2004 at 06:46:35PM +0200, Nigel Kukard wrote:

> >  assuming yes, then it kinda-solves the need for doing that hacked-up
> >  relaxed-constraints-patch-to-hooks.c fscontext= option.
> > 
> 
> aha, u correct!!!!
> 
> >  why? because you can mount -t tmpfs /dev blah blah and you don't 
> >  care what the context is because udev will set the correct one
> >  when it runs.
> > 
> > 
> 
> perfect!!!!, so that solves the need for the hooks patch, which is in
> actual fact wrong.
 
 oh, is it?  uhm, why?

> >  that is - of course - assuming that file_contexts/file_contexts
> >  _contains_ the correct file context for /dev.
> > 
> > 
> 
> *nod*
> 
> >  it might make (i dunno) for a simpler policy.
> > 
> 
> yep
 
  i _say_ might ... but then you mention that you've done exactly
  the same policy mods that i had to...

> >  what i mean is, have you had to add in the modifications to the
> >  selinux policy that i sent to the lists last week?
> > 
> >  e.g. these:
> > 
> > 	 allow udev_tbl_t device_t:filesystem { associate };
> > 	 allow initctl_t device_t:filesystem { associate };
> > 
> >  and these:
> > 
> > 	 +# needed for udev-mounted (/dev) tmpfs
> > 	 +allow $1_tty_device_t device_t:filesystem { associate };
> > 	 +
> > 	 +# to allow users to run df on udev-mounted (/dev) tmpfs
> > 	 +allow $1_t device_t:filesystem { getattr };
> > 	 +   #EXE=/bin/df  NAME=/   :  getattr
> > 	 +
> > 
> 
> had to add quite a couple more, but i'm still working on that to make it
> "correct"
 
 i think we need the input of more experienced people than us to
 say why these associate things are needed.

> >  these are all there for reasons i cannot entirely fathom but
> >  it starts, in types/file.te, with this:
> > 
> >  	allow { device_type } device_t:filesystem associate;
> > 
> 
> i need this aswell.... which is very interesting, so my "way of doing
> it" doesn't solve this problem. i'll keep looking for the solution
> 
> >  which is all because of this:
> >  
> >  	mount tmpfs -o fscontext=system_u:object_r:device_t /dev
> > 
> 
> this doesn't cause the problem, its something else
> 
> >  
> >  anyway what i am saying is that if you HAVE NOT got all these patches
> >  in your selinux policy files, then your approach has distinct
> >  advantages: less mods to the policy files and less differences between
> >  a persistent and non-persistent udev filesystem.
> > 
> 
> correct, i'm still working on it though and it HAS TO BE COMPLETED
> SOON!!!!

 ah, the joys of the "ItWorksForMe(tm)" approach...

> > 
> >  other than that, my intuition is saying "i don't like it" and what that
> >  means is that in about two or three weeks i will be able to articulate
> >  clearly and precisely why i don't think it's a good idea.
> >
> 
> *shrug*, just a different outlook, patching userspace instead of kernel
> space
>

> >  it'll likely be something to do with your solution being a two-step
> >  operation whereas the hacked-up-relaxed-fscontext-hooks.c things is
> >  a one-step (atomic?)  operation.
> > 
> 
> kernel developers will very much not like to get patches unless for a
> very good reason... 

 a correct implementation of the
 hacked-together-relaxed-fscontext-hooks.c-patch results in an atomic
 operation (mount with a new context which would otherwise need to be
 achieved with two commands: mount followed by restorecon)
 
 in my books, that's a good reason!

> *shrug*... guess i have the totally oposite outlook
> than you, i've had quite a number of my patches go mainstream though
 
 dude, the entire selinux thing is disliked by stacks of debian
 maintainers because of the knock-on implications it has.

 imagine what chaos would ensue if up until now, linux only had
 a FAT filesystem and someone said "hey, there's this _great_ concept
 it's called file ownership and file permissions, i've invented
 something called an ext2 filesystem".

 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 SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [idea] udev + selinux

[Luke Kenneth Casson Leighton]

On Tue, Aug 31, 2004 at 06:46:35PM +0200, Nigel Kukard wrote:

> >  assuming yes, then it kinda-solves the need for doing that hacked-up
> >  relaxed-constraints-patch-to-hooks.c fscontext= option.
> > 
> 
> aha, u correct!!!!
> 
> >  why? because you can mount -t tmpfs /dev blah blah and you don't 
> >  care what the context is because udev will set the correct one
> >  when it runs.
> > 
> > 
> 
> perfect!!!!, so that solves the need for the hooks patch, which is in
> actual fact wrong.
 
 oh, is it?  uhm, why?

> >  that is - of course - assuming that file_contexts/file_contexts
> >  _contains_ the correct file context for /dev.
> > 
> > 
> 
> *nod*
> 
> >  it might make (i dunno) for a simpler policy.
> > 
> 
> yep
 
  i _say_ might ... but then you mention that you've done exactly
  the same policy mods that i had to...

> >  what i mean is, have you had to add in the modifications to the
> >  selinux policy that i sent to the lists last week?
> > 
> >  e.g. these:
> > 
> > 	 allow udev_tbl_t device_t:filesystem { associate };
> > 	 allow initctl_t device_t:filesystem { associate };
> > 
> >  and these:
> > 
> > 	 +# needed for udev-mounted (/dev) tmpfs
> > 	 +allow $1_tty_device_t device_t:filesystem { associate };
> > 	 +
> > 	 +# to allow users to run df on udev-mounted (/dev) tmpfs
> > 	 +allow $1_t device_t:filesystem { getattr };
> > 	 +   #EXE=/bin/df  NAME=/   :  getattr
> > 	 +
> > 
> 
> had to add quite a couple more, but i'm still working on that to make it
> "correct"
 
 i think we need the input of more experienced people than us to
 say why these associate things are needed.

> >  these are all there for reasons i cannot entirely fathom but
> >  it starts, in types/file.te, with this:
> > 
> >  	allow { device_type } device_t:filesystem associate;
> > 
> 
> i need this aswell.... which is very interesting, so my "way of doing
> it" doesn't solve this problem. i'll keep looking for the solution
> 
> >  which is all because of this:
> >  
> >  	mount tmpfs -o fscontext=system_u:object_r:device_t /dev
> > 
> 
> this doesn't cause the problem, its something else
> 
> >  
> >  anyway what i am saying is that if you HAVE NOT got all these patches
> >  in your selinux policy files, then your approach has distinct
> >  advantages: less mods to the policy files and less differences between
> >  a persistent and non-persistent udev filesystem.
> > 
> 
> correct, i'm still working on it though and it HAS TO BE COMPLETED
> SOON!!!!

 ah, the joys of the "ItWorksForMe(tm)" approach...

> > 
> >  other than that, my intuition is saying "i don't like it" and what that
> >  means is that in about two or three weeks i will be able to articulate
> >  clearly and precisely why i don't think it's a good idea.
> >
> 
> *shrug*, just a different outlook, patching userspace instead of kernel
> space
>

> >  it'll likely be something to do with your solution being a two-step
> >  operation whereas the hacked-up-relaxed-fscontext-hooks.c things is
> >  a one-step (atomic?)  operation.
> > 
> 
> kernel developers will very much not like to get patches unless for a
> very good reason... 

 a correct implementation of the
 hacked-together-relaxed-fscontext-hooks.c-patch results in an atomic
 operation (mount with a new context which would otherwise need to be
 achieved with two commands: mount followed by restorecon)
 
 in my books, that's a good reason!

> *shrug*... guess i have the totally oposite outlook
> than you, i've had quite a number of my patches go mainstream though
 
 dude, the entire selinux thing is disliked by stacks of debian
 maintainers because of the knock-on implications it has.

 imagine what chaos would ensue if up until now, linux only had
 a FAT filesystem and someone said "hey, there's this _great_ concept
 it's called file ownership and file permissions, i've invented
 something called an ext2 filesystem".

 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: [idea] udev + selinux

[Stephen Smalley]

On Tue, 2004-08-31 at 15:18, Luke Kenneth Casson Leighton wrote:
>  i think we need the input of more experienced people than us to
>  say why these associate things are needed.

It provides control over the set of files that can live in a given
filesystem, based on their security types (equivalence classes).  As you
are now creating device types in a different filesystem type, further
allow rules are needed to allow that association.

>  a correct implementation of the
>  hacked-together-relaxed-fscontext-hooks.c-patch results in an atomic
>  operation (mount with a new context which would otherwise need to be
>  achieved with two commands: mount followed by restorecon)

The more important issue is that fscontext= lets you set the superblock
security context, not just the root directory context.  restorecon can't
do that.

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



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [idea] udev + selinux

[Stephen Smalley]

On Tue, 2004-08-31 at 15:18, Luke Kenneth Casson Leighton wrote:
>  i think we need the input of more experienced people than us to
>  say why these associate things are needed.

It provides control over the set of files that can live in a given
filesystem, based on their security types (equivalence classes).  As you
are now creating device types in a different filesystem type, further
allow rules are needed to allow that association.

>  a correct implementation of the
>  hacked-together-relaxed-fscontext-hooks.c-patch results in an atomic
>  operation (mount with a new context which would otherwise need to be
>  achieved with two commands: mount followed by restorecon)

The more important issue is that fscontext= lets you set the superblock
security context, not just the root directory context.  restorecon can't
do that.

-- 
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: [idea] udev + selinux

[Luke Kenneth Casson Leighton]

On Tue, Aug 31, 2004 at 03:26:43PM -0400, Stephen Smalley wrote:
> On Tue, 2004-08-31 at 15:18, Luke Kenneth Casson Leighton wrote:
> >  i think we need the input of more experienced people than us to
> >  say why these associate things are needed.
> 
> It provides control over the set of files that can live in a given
> filesystem, based on their security types (equivalence classes).  As you
> are now creating device types in a different filesystem type, further
> allow rules are needed to allow that association.
> 
> >  a correct implementation of the
> >  hacked-together-relaxed-fscontext-hooks.c-patch results in an atomic
> >  operation (mount with a new context which would otherwise need to be
> >  achieved with two commands: mount followed by restorecon)
> 
> The more important issue is that fscontext= lets you set the superblock
> security context, not just the root directory context.  restorecon can't
> do that.
 
 ah.

 thanks for clarifying, steven.

 l.


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [idea] udev + selinux

[Luke Kenneth Casson Leighton]

On Tue, Aug 31, 2004 at 03:26:43PM -0400, Stephen Smalley wrote:
> On Tue, 2004-08-31 at 15:18, Luke Kenneth Casson Leighton wrote:
> >  i think we need the input of more experienced people than us to
> >  say why these associate things are needed.
> 
> It provides control over the set of files that can live in a given
> filesystem, based on their security types (equivalence classes).  As you
> are now creating device types in a different filesystem type, further
> allow rules are needed to allow that association.
> 
> >  a correct implementation of the
> >  hacked-together-relaxed-fscontext-hooks.c-patch results in an atomic
> >  operation (mount with a new context which would otherwise need to be
> >  achieved with two commands: mount followed by restorecon)
> 
> The more important issue is that fscontext= lets you set the superblock
> security context, not just the root directory context.  restorecon can't
> do that.
 
 ah.

 thanks for clarifying, steven.

 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: [idea] udev + selinux

[Jim McCullough]

This should be of great assistance with two home projects currently
and  1 work project due to the filesystem types.  I am still working
through size issues and further locking down the images.

Project 1 = SE Linux image for Netgear MR314 Wireless Lan Router
Project 2 = SE Linux image for Cisco 2501 Router
Project 3 = Debian Sarge Server build on SGI Octane with reiserfs (
Work for Network Management Server )

Thanks,
Jim McCullough

On Tue, 31 Aug 2004 21:02:10 +0100, Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
> On Tue, Aug 31, 2004 at 03:26:43PM -0400, Stephen Smalley wrote:
> > On Tue, 2004-08-31 at 15:18, Luke Kenneth Casson Leighton wrote:
> > >  i think we need the input of more experienced people than us to
> > >  say why these associate things are needed.
> >
> > It provides control over the set of files that can live in a given
> > filesystem, based on their security types (equivalence classes).  As you
> > are now creating device types in a different filesystem type, further
> > allow rules are needed to allow that association.
> >
> > >  a correct implementation of the
> > >  hacked-together-relaxed-fscontext-hooks.c-patch results in an atomic
> > >  operation (mount with a new context which would otherwise need to be
> > >  achieved with two commands: mount followed by restorecon)
> >
> > The more important issue is that fscontext= lets you set the superblock
> > security context, not just the root directory context.  restorecon can't
> > do that.
>  
>  ah.
> 
>  thanks for clarifying, steven.
> 
>  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.
> 


-- 
Jim McCullough


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [idea] udev + selinux

[Jim McCullough]

This should be of great assistance with two home projects currently
and  1 work project due to the filesystem types.  I am still working
through size issues and further locking down the images.

Project 1 = SE Linux image for Netgear MR314 Wireless Lan Router
Project 2 = SE Linux image for Cisco 2501 Router
Project 3 = Debian Sarge Server build on SGI Octane with reiserfs (
Work for Network Management Server )

Thanks,
Jim McCullough

On Tue, 31 Aug 2004 21:02:10 +0100, Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
> On Tue, Aug 31, 2004 at 03:26:43PM -0400, Stephen Smalley wrote:
> > On Tue, 2004-08-31 at 15:18, Luke Kenneth Casson Leighton wrote:
> > >  i think we need the input of more experienced people than us to
> > >  say why these associate things are needed.
> >
> > It provides control over the set of files that can live in a given
> > filesystem, based on their security types (equivalence classes).  As you
> > are now creating device types in a different filesystem type, further
> > allow rules are needed to allow that association.
> >
> > >  a correct implementation of the
> > >  hacked-together-relaxed-fscontext-hooks.c-patch results in an atomic
> > >  operation (mount with a new context which would otherwise need to be
> > >  achieved with two commands: mount followed by restorecon)
> >
> > The more important issue is that fscontext= lets you set the superblock
> > security context, not just the root directory context.  restorecon can't
> > do that.
>  
>  ah.
> 
>  thanks for clarifying, steven.
> 
>  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.
> 


-- 
Jim McCullough

--
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: [idea] udev + selinux

[Luke Kenneth Casson Leighton]

well, the patch is at um.. oh no it's not... um, hang on...
yep, it's _now_ at http://hands.com/~lkcl/selinux/selinux-hooks.patch


On Tue, Aug 31, 2004 at 05:18:05PM -0400, Jim McCullough wrote:
> This should be of great assistance with two home projects currently
> and  1 work project due to the filesystem types.  I am still working
> through size issues and further locking down the images.
> 
> Project 1 = SE Linux image for Netgear MR314 Wireless Lan Router
> Project 2 = SE Linux image for Cisco 2501 Router
> Project 3 = Debian Sarge Server build on SGI Octane with reiserfs (
> Work for Network Management Server )

> > > The more important issue is that fscontext= lets you set the superblock
> > > security context, not just the root directory context.  restorecon can't
> > > do that.



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [idea] udev + selinux

[Luke Kenneth Casson Leighton]

well, the patch is at um.. oh no it's not... um, hang on...
yep, it's _now_ at http://hands.com/~lkcl/selinux/selinux-hooks.patch


On Tue, Aug 31, 2004 at 05:18:05PM -0400, Jim McCullough wrote:
> This should be of great assistance with two home projects currently
> and  1 work project due to the filesystem types.  I am still working
> through size issues and further locking down the images.
> 
> Project 1 = SE Linux image for Netgear MR314 Wireless Lan Router
> Project 2 = SE Linux image for Cisco 2501 Router
> Project 3 = Debian Sarge Server build on SGI Octane with reiserfs (
> Work for Network Management Server )

> > > The more important issue is that fscontext= lets you set the superblock
> > > security context, not just the root directory context.  restorecon can't
> > > do that.


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

[OT] SELinux vs. other systems [was Re: [idea] udev + selinux]

[Linas Vepstas]

On Tue, Aug 31, 2004 at 08:18:10PM +0100, Luke Kenneth Casson Leighton was heard to remark:
>  dude, the entire selinux thing is disliked by stacks of debian
>  maintainers because of the knock-on implications it has.

Totally off-topic remark, unrelated to anything, but I'm waiting 
for somethig to compile :)  

Every now and then, I look at SELinux, and I get scared away by its
complexity.  This complexity makes it very hard to audit, and assure
oneself that its actually providing any real security, as opposed to
the illusion of security.  During this email thread, there are 
references to mysterious rules that neither party in the conversation 
fully understands; this scares me. 

Compare this to less complex security provided by e.g. the Linux 
VServer project.  VServer is intended to allow an ISP to pretend they
have a rack of 100 cpu's all running linux, when in fact they have just
one.  The fact that it provides security is a side-effect; but its 
far simpler, far easier to audit, and allows me to sleep at night.

Another example: Way back in the kernel-2.2 timeframe, I hacked on 
something neat: 'LOMAC': if you came in from a network connection, 
you lost permission to do almost anything, other than to e.g. webserve. 
The system was simple, worked well, the kernel patches were easy to audit, 
you could go home without worrying about priveledge escalation.  

Compare that to this thread, where we are talking about atomic vs.
non-atomic restoration of context for udev-mounted temp file systems.
Shudder. This seems to be begging for an exploit to be discovered.
Are we sure that SELinux is really on the right track here?

--linas


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]

[Richard Troth]

On Tue, 31 Aug 2004, Linas Vepstas wrote:
> Every now and then, I look at SELinux, and I get scared away by its
> complexity.  This complexity makes it very hard to audit, and assure
> oneself that its actually providing any real security, as opposed to
> the illusion of security.   ...

Tough questions.   Good questions!
Still,  I do believe MAC has value in contrast to DAC.
But the opposing "flying buttress" to this is that it all
boils down to binary ... somewhere.   And is THAT part isolated?

> Compare this to less complex security provided by e.g. the Linux
> VServer project.  VServer is intended to allow an ISP to pretend they
> have a rack of 100 cpu's all running linux, when in fact they have just
> one.  The fact that it provides security is a side-effect; but its
> far simpler, far easier to audit, and allows me to sleep at night.

Ahhh...   virtual machines.   (And I don't mean Java.)
I'm thinking VMware and (esp) z/VM (IBM style mainframe).
Been using both or years,  VMware since 1.0 beta and mainframe since ...
well ... I was pretty young at the time.   But not for security per-se,
they have other interesting features.   Linas' mention of VServer
and its side-effect security reminds me of something I read
in the anals of VM hisory:

	http://vm.marist.edu/~vmshare/browse?fn=VMHIST07&ft=NOTE

(Stephen, Howard, and the rest and friends at the NSA
please take no offense.   I found this terribly entertaining.)
Even from its earliest days,  VM (CP) isolated each user,  so:

        "On another  occasion we almost  had an  in-house protest.
         Among the early  users of CP-67/CMS were  both the National
         Security Agency and the CIA;  the fact that the DAT hardware
         isolated each user in his own  address space was viewed as a
         powerful system security feature.   One  time in 1970,  I
         think, the CIA sent two of their people to Cambridge to talk
         about something  that Ed Hendricks  had developed  or was
         working on.   In the atmosphere of  the time,  none of the
         technical people at CSC,  especially Ed,  wanted to talk to
         them at all!   Ed stormed around the halls muttering "damned
         spooks!" for half an hour or  more before Craig Johnson and
         Norm Rasmussen were  able to coerce him  into the meeting.
         Even more amazing is that they were spooks;  there was a man
         and a woman, both of slightly below-average height,  average
         build,  average  everything!   You could stand  and talk
         directly to them or study them for five minutes or more, but
         if you  turned around there  was nothing to  remember and
         nothing to describe; they were effectively invisible."

Thanks to Lynn Wheeler for helping me dig this up.

-- R;



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]

[Richard Troth]

On Tue, 31 Aug 2004, Linas Vepstas wrote:
> Every now and then, I look at SELinux, and I get scared away by its
> complexity.  This complexity makes it very hard to audit, and assure
> oneself that its actually providing any real security, as opposed to
> the illusion of security.   ...

Tough questions.   Good questions!
Still,  I do believe MAC has value in contrast to DAC.
But the opposing "flying buttress" to this is that it all
boils down to binary ... somewhere.   And is THAT part isolated?

> Compare this to less complex security provided by e.g. the Linux
> VServer project.  VServer is intended to allow an ISP to pretend they
> have a rack of 100 cpu's all running linux, when in fact they have just
> one.  The fact that it provides security is a side-effect; but its
> far simpler, far easier to audit, and allows me to sleep at night.

Ahhh...   virtual machines.   (And I don't mean Java.)
I'm thinking VMware and (esp) z/VM (IBM style mainframe).
Been using both or years,  VMware since 1.0 beta and mainframe since ...
well ... I was pretty young at the time.   But not for security per-se,
they have other interesting features.   Linas' mention of VServer
and its side-effect security reminds me of something I read
in the anals of VM hisory:

	http://vm.marist.edu/~vmshare/browse?fn=VMHIST07&ft=NOTE

(Stephen, Howard, and the rest and friends at the NSA
please take no offense.   I found this terribly entertaining.)
Even from its earliest days,  VM (CP) isolated each user,  so:

        "On another  occasion we almost  had an  in-house protest.
         Among the early  users of CP-67/CMS were  both the National
         Security Agency and the CIA;  the fact that the DAT hardware
         isolated each user in his own  address space was viewed as a
         powerful system security feature.   One  time in 1970,  I
         think, the CIA sent two of their people to Cambridge to talk
         about something  that Ed Hendricks  had developed  or was
         working on.   In the atmosphere of  the time,  none of the
         technical people at CSC,  especially Ed,  wanted to talk to
         them at all!   Ed stormed around the halls muttering "damned
         spooks!" for half an hour or  more before Craig Johnson and
         Norm Rasmussen were  able to coerce him  into the meeting.
         Even more amazing is that they were spooks;  there was a man
         and a woman, both of slightly below-average height,  average
         build,  average  everything!   You could stand  and talk
         directly to them or study them for five minutes or more, but
         if you  turned around there  was nothing to  remember and
         nothing to describe; they were effectively invisible."

Thanks to Lynn Wheeler for helping me dig this up.

-- R;


--
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: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]

[Colin Walters]

[ The CC list here is rather nuts, someone needs to trim it...]

On Tue, 2004-08-31 at 17:44 -0500, Linas Vepstas wrote:

> Every now and then, I look at SELinux, and I get scared away by its
> complexity.  

It is actually not that complicated, but if you're unfamiliar with
mandatory access control (as I was when I first started learning about
SELinux), it does require understanding some theory before you dive in.

> This complexity makes it very hard to audit, and assure
> oneself that its actually providing any real security, as opposed to
> the illusion of security.  During this email thread, there are 
> references to mysterious rules that neither party in the conversation 
> fully understands; this scares me. 

Because two people in a thread don't understand SELinux, that means that
it's too complex?  I can certainly find plenty of examples of people not
understanding Linux on linux-kernel; does that imply Linux is too
complex?

> Compare this to less complex security provided by e.g. the Linux 
> VServer project.  VServer is intended to allow an ISP to pretend they
> have a rack of 100 cpu's all running linux, when in fact they have just
> one.  

VServer isn't solving the same problem as SELinux.  VServer is really a
virtualization solution.  For example, it would make sense to run *both*
a virtualization solution like VServer (or Xen, which looks more
promising), and SELinux at the same time.  That way, if e.g. the bind
daemon running in one of the virtualized servers gets cracked, it
doesn't mean a compromise of the whole virtual server.

Now, you can use a virtualization technology as a primitive form of
separation by running e.g. your MTA in one virtual server, your name
server in another, etc.  But that's rather painful, and is only an
approximation to least privilege.

> Another example: Way back in the kernel-2.2 timeframe, I hacked on 
> something neat: 'LOMAC': if you came in from a network connection, 
> you lost permission to do almost anything, other than to e.g. webserve. 
> The system was simple, worked well, the kernel patches were easy to audit, 
> you could go home without worrying about priveledge escalation.  

That's also a rather blunt tool; SELinux is much more flexible.

> Compare that to this thread, where we are talking about atomic vs.
> non-atomic restoration of context for udev-mounted temp file systems.
> Shudder. This seems to be begging for an exploit to be discovered.

I doubt it.  Files created in /dev should have a default type like
device_t which most domains will not have access to.

> Are we sure that SELinux is really on the right track here?

Given the amount of research behind SELinux, and the amount of work
being done on it, I think so, yes.



--
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: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]

[Linas Vepstas]

On Wed, Sep 01, 2004 at 10:29:34AM -0400, Colin Walters was heard to remark:
> [ The CC list here is rather nuts, someone needs to trim it...]
> 
> On Tue, 2004-08-31 at 17:44 -0500, Linas Vepstas wrote:
> 
> > Every now and then, I look at SELinux, and I get scared away by its
> > complexity.  
> 
> It is actually not that complicated, but if you're unfamiliar with
> mandatory access control (as I was when I first started learning about
> SELinux), it does require understanding some theory before you dive in.

Hmm, I thought I understood MAC; I was refering to the large numbers of
rules in SELinux.  Its not obvious (to me) that there isn't a path
through those rules that allows privledge escalation.  

For example: and correct me if I'm wrong, but its quite possible to 
write a complex rule set that intentionally leaves 'holes' allowing
for priveledge escalation.  Thus, by extrapolation, its quite possible
to write a set of rules that accidentally do the same.  When one is
presented with a set of rules, how does one know that they don't have a
hole? Answer: one audits the rules.  Unfortunately, there are a lot
of rules: last time I looked at one of the config files, it was
thousands of lines long.  Thus, a short, simple audit performed by
one person seems out of the question.  

Now, as to auditing...

> it's too complex?  I can certainly find plenty of examples of people not
> understanding Linux on linux-kernel; does that imply Linux is too
> complex?

We've had a fair number of "eyeballs" read the linux kernel, and thus
base our trust in its security on that.  However, the SELinux rules
are unlike the kernel in an important way: they are config files. 
This allows allows some anonymous fedora/debian/gentoo maintainer
to do something dumb like "gee, my USB camera doesn't work with udev,
but then when I change this selinux rule, it does", and poof, you've
lost the security.   I'm presuming that this kind of mucking around is 
far more common than altering lines of source in the kernel that weaken
security.   But I base my presumption on real life: go to any LUG,
hang out with any sysadmin long enough, and you will see them make
changes to config files that are dangerous if not outright incorrect.
Sysadmins are, as a species, people who work with incomplete knowledge
of the systems they administer.


> > Compare this to less complex security provided by e.g. the Linux 
> > VServer project.  

> VServer isn't solving the same problem as SELinux.  

Yes, that's right. I did try to point that out ... 

> That way, if e.g. the bind
> daemon running in one of the virtualized servers gets cracked, it
> doesn't mean a compromise of the whole virtual server.

No...  If the bind deamon gets cracked, it doesn't compromise the 'whole';
it only compromises root and anything else running in that context.  
It does not (in theory) compromise root in the other contexts.  In other 
words, one of the servers could be 0wned by someone truly hostile, 
while the 'whole' remains (theoretically) safe.

> Now, you can use a virtualization technology as a primitive form of
> separation by running e.g. your MTA in one virtual server, your name
> server in another, etc.  But that's rather painful, and is only an
> approximation to least privilege.

Yes, this is exactly what I'm thinking of.  But its not painful, 
it solves 90% or 100% of the needs of a 'typical' ISP/ASP/web server
admin.   Yes, this is indeed a blunt tool... see below:

> > Another example: Way back in the kernel-2.2 timeframe, I hacked on 
> > something neat: 'LOMAC': if you came in from a network connection, 
> > you lost permission to do almost anything, other than to e.g. webserve. 
> > The system was simple, worked well, the kernel patches were easy to audit, 
> > you could go home without worrying about priveledge escalation.  
> 
> That's also a rather blunt tool; SELinux is much more flexible.

What I'm proposing here is that bluntness can be traded for increased
assurances and increased ability to audit the code for "correctness". 
Yes, SELinux is far more flexible; but this is exactly what scares me.

I once thought about re-implementing LoMAC as a ruleset atop of SELinux.
I'm pretty sure that this is possible, but I started thinking that the
complexity of the ruleset may introduce holes that voids the effort.
And that thought disturbed me.

Along with Lomac's 'bluntness' comes 'zero configurability': its
something that could be installed on the proverbial 'Grandma's Linux
desktop', and provide additional security without causing pain.

With selinux, its not only not zero-conf, but its also not clear 
(to me) if the rulesets that install with debian/fedora/etc. actually
provide any additonal security at all against network breakins.
If the rulesets do indeed provide this protection, then there is a 
perception/marketing problem: people like me "don't get it" from
just skimming the selinux web pages.  I'd prefer to get all the 
benefits of SELinux without having to RTFM.


--linas



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]

[Stephen Smalley]

On Wed, 2004-09-01 at 13:25, Linas Vepstas wrote:
> Hmm, I thought I understood MAC; I was refering to the large numbers of
> rules in SELinux.  Its not obvious (to me) that there isn't a path
> through those rules that allows privledge escalation.  
> 
> For example: and correct me if I'm wrong, but its quite possible to 
> write a complex rule set that intentionally leaves 'holes' allowing
> for priveledge escalation.  Thus, by extrapolation, its quite possible
> to write a set of rules that accidentally do the same.  When one is
> presented with a set of rules, how does one know that they don't have a
> hole? Answer: one audits the rules.  Unfortunately, there are a lot
> of rules: last time I looked at one of the config files, it was
> thousands of lines long.  Thus, a short, simple audit performed by
> one person seems out of the question.

The complexity of the rules reflect the complexity of the existing Linux
system and its interactions; SELinux didn't introduce that complexity -
SELinux just enables you to control what happens in that complex
system.  No criticism intended of Linux; the same would apply to any
mainstream operating system, and the complexity just reflects real world
requirements.  And you do have the option of reducing the visible
complexity based on your security goals; if you don't care about the
interactions among a set of processes/resources, you fold the domain and
type space accordingly.  The targeted policy is an example of doing that
to an extreme.

Analysis of that complexity _does_ require automated tools, and such
tools exist.  apol (yum install setools setools-gui) provides support
for analysis, including domain transitions and information flow.  slat
(available from the NSA SELinux site or MITRE) does security goal
checking using a model checker.  Gokyo from IBM Watson (which AFAIK is
unfortunately not released publically yet, perhaps you could encourage
that to happen) analyzes against Biba integrity constraints and
identifies exceptions for further examination.

> However, the SELinux rules
> are unlike the kernel in an important way: they are config files. 
> This allows allows some anonymous fedora/debian/gentoo maintainer
> to do something dumb like "gee, my USB camera doesn't work with udev,
> but then when I change this selinux rule, it does", and poof, you've
> lost the security.

The policy maintainers for the various distros are not anonymous and
appear to take their work quite seriously; rejecting policy changes
despite a reduction in functionality is not uncommon.  You seem to be
assuming that policy for each package is maintained by the individual
package maintainers; that isn't the case, and likely never will be. 
Ditto for sysadmins; most of them should never touch policy at all.

> What I'm proposing here is that bluntness can be traded for increased
> assurances and increased ability to audit the code for "correctness". 
> Yes, SELinux is far more flexible; but this is exactly what scares me.

Reality is complex.  Deal with it.  Being confident in the correctness
of an inadequate security model doesn't help much.

> I once thought about re-implementing LoMAC as a ruleset atop of SELinux.
> I'm pretty sure that this is possible, but I started thinking that the
> complexity of the ruleset may introduce holes that voids the effort.
> And that thought disturbed me.

It isn't actually possible to implement LOMAC via SELinux, but that's
another topic.

> Along with Lomac's 'bluntness' comes 'zero configurability': its
> something that could be installed on the proverbial 'Grandma's Linux
> desktop', and provide additional security without causing pain.

Until Grandma wants to do useful work.  Simple security models are nice
to look at, but they don't capture the behavior of real systems, and it
doesn't matter that the model is "secure"; you just break one of the
trusted subjects authorized to override the security model in order to
get the real work done.  SELinux policy may look weaker to you, but it
actually represents what is being allowed in the system; no exceptions.

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



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]

[Stephen Smalley]

On Wed, 2004-09-01 at 13:25, Linas Vepstas wrote:
> Hmm, I thought I understood MAC; I was refering to the large numbers of
> rules in SELinux.  Its not obvious (to me) that there isn't a path
> through those rules that allows privledge escalation.  
> 
> For example: and correct me if I'm wrong, but its quite possible to 
> write a complex rule set that intentionally leaves 'holes' allowing
> for priveledge escalation.  Thus, by extrapolation, its quite possible
> to write a set of rules that accidentally do the same.  When one is
> presented with a set of rules, how does one know that they don't have a
> hole? Answer: one audits the rules.  Unfortunately, there are a lot
> of rules: last time I looked at one of the config files, it was
> thousands of lines long.  Thus, a short, simple audit performed by
> one person seems out of the question.

The complexity of the rules reflect the complexity of the existing Linux
system and its interactions; SELinux didn't introduce that complexity -
SELinux just enables you to control what happens in that complex
system.  No criticism intended of Linux; the same would apply to any
mainstream operating system, and the complexity just reflects real world
requirements.  And you do have the option of reducing the visible
complexity based on your security goals; if you don't care about the
interactions among a set of processes/resources, you fold the domain and
type space accordingly.  The targeted policy is an example of doing that
to an extreme.

Analysis of that complexity _does_ require automated tools, and such
tools exist.  apol (yum install setools setools-gui) provides support
for analysis, including domain transitions and information flow.  slat
(available from the NSA SELinux site or MITRE) does security goal
checking using a model checker.  Gokyo from IBM Watson (which AFAIK is
unfortunately not released publically yet, perhaps you could encourage
that to happen) analyzes against Biba integrity constraints and
identifies exceptions for further examination.

> However, the SELinux rules
> are unlike the kernel in an important way: they are config files. 
> This allows allows some anonymous fedora/debian/gentoo maintainer
> to do something dumb like "gee, my USB camera doesn't work with udev,
> but then when I change this selinux rule, it does", and poof, you've
> lost the security.

The policy maintainers for the various distros are not anonymous and
appear to take their work quite seriously; rejecting policy changes
despite a reduction in functionality is not uncommon.  You seem to be
assuming that policy for each package is maintained by the individual
package maintainers; that isn't the case, and likely never will be. 
Ditto for sysadmins; most of them should never touch policy at all.

> What I'm proposing here is that bluntness can be traded for increased
> assurances and increased ability to audit the code for "correctness". 
> Yes, SELinux is far more flexible; but this is exactly what scares me.

Reality is complex.  Deal with it.  Being confident in the correctness
of an inadequate security model doesn't help much.

> I once thought about re-implementing LoMAC as a ruleset atop of SELinux.
> I'm pretty sure that this is possible, but I started thinking that the
> complexity of the ruleset may introduce holes that voids the effort.
> And that thought disturbed me.

It isn't actually possible to implement LOMAC via SELinux, but that's
another topic.

> Along with Lomac's 'bluntness' comes 'zero configurability': its
> something that could be installed on the proverbial 'Grandma's Linux
> desktop', and provide additional security without causing pain.

Until Grandma wants to do useful work.  Simple security models are nice
to look at, but they don't capture the behavior of real systems, and it
doesn't matter that the model is "secure"; you just break one of the
trusted subjects authorized to override the security model in order to
get the real work done.  SELinux policy may look weaker to you, but it
actually represents what is being allowed in the system; no exceptions.

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

Lomac questions [was Re: [OT] SELinux vs. other systems]

[Linas Vepstas]

Hi Stephen,

Excellent answer... its been too long since I've played with selinux.
I'll try again.

> > I once thought about re-implementing LoMAC as a ruleset atop of SELinux.
> > I'm pretty sure that this is possible, but I started thinking that the
> > complexity of the ruleset may introduce holes that voids the effort.
> > And that thought disturbed me.
> 
> It isn't actually possible to implement LOMAC via SELinux, but that's
> another topic.

Hmm, why not? 

> > Along with Lomac's 'bluntness' comes 'zero configurability': its
> > something that could be installed on the proverbial 'Grandma's Linux
> > desktop', and provide additional security without causing pain.
> 
> Until Grandma wants to do useful work.  Simple security models are nice
> to look at, but they don't capture the behavior of real systems, and it
> doesn't matter that the model is "secure"; you just break one of the
> trusted subjects authorized to override the security model in order to
> get the real work done.  SELinux policy may look weaker to you, but it
> actually represents what is being allowed in the system; no exceptions.

I don't quite understand this.  I'm currently running Lomac on one of 
my servers, and I can get work done.  It seems to be usable, even if 
it makes some operations, like software install, harder.

I'm not sure what you mean by 'break a trusted subject'.  If you mean
'ssh is trusted, so if ssh is broken, all hope is lost', then yes.
But surely selinux has trusted subjects that may not be trustworthy?

If you mean 'lomac provides explicit tools that allow a sysadmin
to manually move a file from lower to higher trust domains', then,
well, I'm also confused.  Surely selinux also has a way to start
with something untrusted, and then raise its level ... e.g. to
install software downloaded from the net.   

Is the 'broken-ness' the fact that grandma failed to run an anti-virus
scanner and verify checksums, yada yada, before elevating the
priveldge on the downloaded software?

--linas



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Lomac questions [was Re: [OT] SELinux vs. other systems]

[Linas Vepstas]

Hi Stephen,

Excellent answer... its been too long since I've played with selinux.
I'll try again.

> > I once thought about re-implementing LoMAC as a ruleset atop of SELinux.
> > I'm pretty sure that this is possible, but I started thinking that the
> > complexity of the ruleset may introduce holes that voids the effort.
> > And that thought disturbed me.
> 
> It isn't actually possible to implement LOMAC via SELinux, but that's
> another topic.

Hmm, why not? 

> > Along with Lomac's 'bluntness' comes 'zero configurability': its
> > something that could be installed on the proverbial 'Grandma's Linux
> > desktop', and provide additional security without causing pain.
> 
> Until Grandma wants to do useful work.  Simple security models are nice
> to look at, but they don't capture the behavior of real systems, and it
> doesn't matter that the model is "secure"; you just break one of the
> trusted subjects authorized to override the security model in order to
> get the real work done.  SELinux policy may look weaker to you, but it
> actually represents what is being allowed in the system; no exceptions.

I don't quite understand this.  I'm currently running Lomac on one of 
my servers, and I can get work done.  It seems to be usable, even if 
it makes some operations, like software install, harder.

I'm not sure what you mean by 'break a trusted subject'.  If you mean
'ssh is trusted, so if ssh is broken, all hope is lost', then yes.
But surely selinux has trusted subjects that may not be trustworthy?

If you mean 'lomac provides explicit tools that allow a sysadmin
to manually move a file from lower to higher trust domains', then,
well, I'm also confused.  Surely selinux also has a way to start
with something untrusted, and then raise its level ... e.g. to
install software downloaded from the net.   

Is the 'broken-ness' the fact that grandma failed to run an anti-virus
scanner and verify checksums, yada yada, before elevating the
priveldge on the downloaded software?

--linas


--
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: Lomac questions [was Re: [OT] SELinux vs. other systems]

[Luke Kenneth Casson Leighton]

On Thu, Sep 02, 2004 at 12:29:07PM -0500, Linas Vepstas wrote:

> Is the 'broken-ness' the fact that grandma failed to run an anti-virus
> scanner and verify checksums, yada yada, before elevating the
> priveldge on the downloaded software?

 [this is all with the strict policy 1.14 mostly sortof btw]

 i've installed clamav, spamassassin, razor and pyzor.

 oh, and freshclam.

 i then found a little script called clamassassin [google], i then
 searched [google] for some advice on how to set up kmail filters.

 kmail, the clamassassin script and spamc all run under the user
 context.

 the user context is given the right to bind to servers.

 spamd and clamd both run as servers: they have their own
 policies that restrict their operation to what is known
 that they presently do, but they are allowed to listen to
 incoming requests [from spamc and the clamassassin script
 respectively.]

 selinux doesn't in the _slightest_ bit get in the way.


 the only thing that i did find is that razor is a complete pain.

 it endeavours to write log files into /root/razor.log, /tmp/razor.log,
 /razor.log, it's a pain, and selinux is _exactly_ the sort of thing
 that can detect - and stop! - this behaviour.

 pyzor appears to be a lot less haphazard.

 also nobody else appears to have tried to run freshclam [automatic
 update script] before now, so i had to hack the clamav.te policy
 a bit to get it to run.

 l.



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idP47&alloc_id\x10808&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Lomac questions [was Re: [OT] SELinux vs. other systems]

[Luke Kenneth Casson Leighton]

On Thu, Sep 02, 2004 at 12:29:07PM -0500, Linas Vepstas wrote:

> Is the 'broken-ness' the fact that grandma failed to run an anti-virus
> scanner and verify checksums, yada yada, before elevating the
> priveldge on the downloaded software?

 [this is all with the strict policy 1.14 mostly sortof btw]

 i've installed clamav, spamassassin, razor and pyzor.

 oh, and freshclam.

 i then found a little script called clamassassin [google], i then
 searched [google] for some advice on how to set up kmail filters.

 kmail, the clamassassin script and spamc all run under the user
 context.

 the user context is given the right to bind to servers.

 spamd and clamd both run as servers: they have their own
 policies that restrict their operation to what is known
 that they presently do, but they are allowed to listen to
 incoming requests [from spamc and the clamassassin script
 respectively.]

 selinux doesn't in the _slightest_ bit get in the way.


 the only thing that i did find is that razor is a complete pain.

 it endeavours to write log files into /root/razor.log, /tmp/razor.log,
 /razor.log, it's a pain, and selinux is _exactly_ the sort of thing
 that can detect - and stop! - this behaviour.

 pyzor appears to be a lot less haphazard.

 also nobody else appears to have tried to run freshclam [automatic
 update script] before now, so i had to hack the clamav.te policy
 a bit to get it to run.

 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: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]

[Russell Coker]

On Wed, 1 Sep 2004 08:44, Linas Vepstas <linas@austin.ibm.com> wrote:
> Every now and then, I look at SELinux, and I get scared away by its
> complexity.  This complexity makes it very hard to audit, and assure

What auditing are you referring to?  Kernel code, application code, or policy?

The application code is not overly complex.  The kernel code is as good as 
such code can be.  Tresys http://www.tresys.com/ are developing tools for 
auditing SE Linux policy.

> oneself that its actually providing any real security, as opposed to
> the illusion of security.  During this email thread, there are
> references to mysterious rules that neither party in the conversation
> fully understands; this scares me.

Which mysterious rules are you referring to?

> Compare that to this thread, where we are talking about atomic vs.
> non-atomic restoration of context for udev-mounted temp file systems.
> Shudder. This seems to be begging for an exploit to be discovered.
> Are we sure that SELinux is really on the right track here?

The original udev implementation had the device nodes relabelled after 
creation.  As of recent times (since 2002) the default SE Linux policy has 
denied almost all domains (only two system domains) access to device nodes 
labelled as device_t.  This means that there is no window of opportunity for 
an attacker to access a device before it is correctly labelled.

The worst race condition attack would be a DOS attack, cause an access at the 
wrong time and have it be denied when otherwise it would be permitted.  This 
is the least serious of all possible problems related to device labelling.

-- 
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: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]

[Linas Vepstas]

On Thu, Sep 02, 2004 at 10:15:20PM +1000, Russell Coker was heard to remark:
> On Wed, 1 Sep 2004 08:44, Linas Vepstas <linas@austin.ibm.com> wrote:
> > Every now and then, I look at SELinux, and I get scared away by its
> > complexity.  This complexity makes it very hard to audit, and assure
> 
> What auditing are you referring to?  Kernel code, application code, or policy?

policy.
 
> > oneself that its actually providing any real security, as opposed to
> > the illusion of security.  During this email thread, there are
> > references to mysterious rules that neither party in the conversation
> > fully understands; this scares me.
> 
> Which mysterious rules are you referring to?

I wasn't refering to them, the posters to the thread were.  Unfortunately,
I've already deleted those emails.

> labelled as device_t.  This means that there is no window of opportunity for 
> an attacker to access a device before it is correctly labelled.

OK.

Well, here's another idle question, again off-topic: Does SELinux provide 
any sort of assurances that storage media weren't tampered with between
reboots?  

For example, with BIOS/firmware getting more sophisticated over time,
there's potential for an attacker to break in, remotely, into
bios/firmware, shortly before booting into the OS, and then alter 
disk contents.  Yes, I know this is far-fetched, but was just curious.

What got me going on that thread was thinking about udev/hotplug again:
with devices coming and going, disappearing and re-appearing, it isn't
obvious that there wasn't tampering while the device was gone. 

Again, excuse me if this sounds naive, un-informed or far-fetched, 
or terribly off-topic, but: In ye olden days, viruses spread through 
diskettes.   These days, we're plugging-n-playing usb keychains,
cameras, ipods, bluetooth this-n-that; although I haven't heard of 
attacks carried out through these media, its not obivious that these
couldn't be carriers for an attack.

--linas

--
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: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]

[Russell Coker]

On Fri, 3 Sep 2004 03:07, Linas Vepstas <linas@austin.ibm.com> wrote:
> Well, here's another idle question, again off-topic: Does SELinux provide
> any sort of assurances that storage media weren't tampered with between
> reboots?

No, that is outside the scope of the SE Linux project.

I am one of the many people in Red Hat who are involved in working on crypto 
block device support.  One of my own systems has a root file system that is 
AES encrypted with the kernel and initrd (which includes the decryption key) 
on removable media.  Eventually I want to see this become a standard feature 
of Fedora, maybe in FC4.  I think it will address most of what you want in 
this regard.

Note that the NSA guys do not talk to me about any security stuff, so I don't 
expect them to have any involvement in such things.

> For example, with BIOS/firmware getting more sophisticated over time,
> there's potential for an attacker to break in, remotely, into
> bios/firmware, shortly before booting into the OS, and then alter
> disk contents.  Yes, I know this is far-fetched, but was just curious.

When booting from removable media that contains the decryption key the attack 
scenario would be to replace the BIOS with one that sends everything it reads 
from disk (IE everything that the boot loader reads) over an Ethernet 
interface.

A trojan BIOS that modifies the kernel during the boot load process to 
introduce a security hole would be doable if you have adequate resources.

-- 
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: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux]

[Luke Kenneth Casson Leighton]

On Thu, Sep 02, 2004 at 10:15:20PM +1000, Russell Coker wrote:

> > Compare that to this thread, where we are talking about atomic vs.
> > non-atomic restoration of context for udev-mounted temp file systems.
> > Shudder. This seems to be begging for an exploit to be discovered.
> > Are we sure that SELinux is really on the right track here?
> 
> The original udev implementation had the device nodes relabelled after 
> creation.  As of recent times (since 2002) the default SE Linux policy has 
> denied almost all domains (only two system domains) access to device nodes 
> labelled as device_t.  This means that there is no window of opportunity for 
> an attacker to access a device before it is correctly labelled.
> 
> The worst race condition attack would be a DOS attack, cause an access at the 
> wrong time and have it be denied when otherwise it would be permitted.  This 
> is the least serious of all possible problems related to device labelling.

 ... and with the use of matchpathcon() followed by setfscreatecon(),
 it isn't even that: inode, symlink and directory
 creation-plus-filecontext-setting are done as an atomic operation.

 problem goes away.

 the _old_ selinux udev support (0.024), on the other hand, suffered
 from the big-deal-DOS-attack that russell describes above.

 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.