* lots of allow xxx_device_t device_t:filesystem { associate }
@ 2004-08-09 17:52 Luke Kenneth Casson Leighton
2004-08-09 18:43 ` Stephen Smalley
0 siblings, 1 reply; 13+ messages in thread
From: Luke Kenneth Casson Leighton @ 2004-08-09 17:52 UTC (permalink / raw)
To: SE-Linux
hi,
i'm getting an awful lot of the above due to udev creating
inodes in /dev which i decided to associate with device_t.
should i have instead picked a different fscontext (bearing
in mind that this is with the modified 2.6.8 kernel that
doesn't mind associating an xattr-enabled tmpfs with a mount
point)
i have added mount -o fscontext=system_u:object_r:device_t to
/etc/init.d/udev for mounting /dev on a tmpfs.
now i have had to add about 15 or 20 lines so far each for pretty
much every xxx_device_t under the sun, and am concerned that i
am taking the wrong approach.
anyone got any ideas about what i should try next?
ta,
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: lots of allow xxx_device_t device_t:filesystem { associate }
2004-08-09 17:52 lots of allow xxx_device_t device_t:filesystem { associate } Luke Kenneth Casson Leighton
@ 2004-08-09 18:43 ` Stephen Smalley
2004-08-09 19:09 ` Luke Kenneth Casson Leighton
2004-08-09 19:35 ` Luke Kenneth Casson Leighton
0 siblings, 2 replies; 13+ messages in thread
From: Stephen Smalley @ 2004-08-09 18:43 UTC (permalink / raw)
To: Luke Kenneth Casson Leighton; +Cc: SE-Linux
On Mon, 2004-08-09 at 13:52, Luke Kenneth Casson Leighton wrote:
> i'm getting an awful lot of the above due to udev creating
> inodes in /dev which i decided to associate with device_t.
allow device_type device_t:filesystem associate;
should cover most cases.
> now i have had to add about 15 or 20 lines so far each for pretty
> much every xxx_device_t under the sun, and am concerned that i
> am taking the wrong approach.
Other than the associate permission, what else do you need to add?
--
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: lots of allow xxx_device_t device_t:filesystem { associate }
2004-08-09 18:43 ` Stephen Smalley
@ 2004-08-09 19:09 ` Luke Kenneth Casson Leighton
2004-08-09 19:35 ` Luke Kenneth Casson Leighton
1 sibling, 0 replies; 13+ messages in thread
From: Luke Kenneth Casson Leighton @ 2004-08-09 18:59 UTC (permalink / raw)
To: Stephen Smalley; +Cc: SE-Linux, Linux Hotplug Dev List
On Mon, Aug 09, 2004 at 02:43:36PM -0400, Stephen Smalley wrote:
> On Mon, 2004-08-09 at 13:52, Luke Kenneth Casson Leighton wrote:
> > i'm getting an awful lot of the above due to udev creating
> > inodes in /dev which i decided to associate with device_t.
>
> allow device_type device_t:filesystem associate;
> should cover most cases.
thank you: i found this: i was more concerned that i should
be setting mount -o fscontext=....fs_t instead?
> > now i have had to add about 15 or 20 lines so far each for pretty
> > much every xxx_device_t under the sun, and am concerned that i
> > am taking the wrong approach.
>
> Other than the associate permission, what else do you need to add?
eek.
allow initrc_t device_t:lnk_file { create };
for a symlink to be created between /proc/self/fd and /dev/fd
i realise it would be better to move stuff in /etc/init.d/udev
to a separate program, e.g. /sbin/udev-init, and to have that
program be given a separate domain instead of having to add
this to initrc_t.
allow udev_t device_t:file { getattr unlink };
for /sbin/udev to stat and remove /dev/null...
exactly what is going on here i don't know.
allow udev_t self:process { setfscreate };
surprise surprise, it's doing the same thing as restorecon,
so, duh, udev needs this.
more later.
l.
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
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
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: lots of allow xxx_device_t device_t:filesystem { associate }
@ 2004-08-09 19:09 ` Luke Kenneth Casson Leighton
0 siblings, 0 replies; 13+ messages in thread
From: Luke Kenneth Casson Leighton @ 2004-08-09 19:09 UTC (permalink / raw)
To: Stephen Smalley; +Cc: SE-Linux, Linux Hotplug Dev List
On Mon, Aug 09, 2004 at 02:43:36PM -0400, Stephen Smalley wrote:
> On Mon, 2004-08-09 at 13:52, Luke Kenneth Casson Leighton wrote:
> > i'm getting an awful lot of the above due to udev creating
> > inodes in /dev which i decided to associate with device_t.
>
> allow device_type device_t:filesystem associate;
> should cover most cases.
thank you: i found this: i was more concerned that i should
be setting mount -o fscontext=....fs_t instead?
> > now i have had to add about 15 or 20 lines so far each for pretty
> > much every xxx_device_t under the sun, and am concerned that i
> > am taking the wrong approach.
>
> Other than the associate permission, what else do you need to add?
eek.
allow initrc_t device_t:lnk_file { create };
for a symlink to be created between /proc/self/fd and /dev/fd
i realise it would be better to move stuff in /etc/init.d/udev
to a separate program, e.g. /sbin/udev-init, and to have that
program be given a separate domain instead of having to add
this to initrc_t.
allow udev_t device_t:file { getattr unlink };
for /sbin/udev to stat and remove /dev/null...
exactly what is going on here i don't know.
allow udev_t self:process { setfscreate };
surprise surprise, it's doing the same thing as restorecon,
so, duh, udev needs this.
more later.
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: lots of allow xxx_device_t device_t:filesystem { associate }
2004-08-09 19:09 ` Luke Kenneth Casson Leighton
@ 2004-08-09 19:02 ` Stephen Smalley
-1 siblings, 0 replies; 13+ messages in thread
From: Stephen Smalley @ 2004-08-09 19:02 UTC (permalink / raw)
To: Luke Kenneth Casson Leighton; +Cc: SE-Linux, Linux Hotplug Dev List
On Mon, 2004-08-09 at 15:09, Luke Kenneth Casson Leighton wrote:
> thank you: i found this: i was more concerned that i should
> be setting mount -o fscontext=....fs_t instead?
No, I think device_t is appropriate here.
> allow initrc_t device_t:lnk_file { create };
> for a symlink to be created between /proc/self/fd and /dev/fd
>
> i realise it would be better to move stuff in /etc/init.d/udev
> to a separate program, e.g. /sbin/udev-init, and to have that
> program be given a separate domain instead of having to add
> this to initrc_t.
I already see an 'allow initrc_t device_t:lnk_file { unlink };' rule in
initrc.te related to udev operation, so this isn't too surprising.
> allow udev_t device_t:file { getattr unlink };
> for /sbin/udev to stat and remove /dev/null...
/dev/null should show up as chr_file, and should be created with
null_device_t anyway. Is this actually an attempt to unlink udev.tbl?
--
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
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
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: lots of allow xxx_device_t device_t:filesystem { associate }
@ 2004-08-09 19:02 ` Stephen Smalley
0 siblings, 0 replies; 13+ messages in thread
From: Stephen Smalley @ 2004-08-09 19:02 UTC (permalink / raw)
To: Luke Kenneth Casson Leighton; +Cc: SE-Linux, Linux Hotplug Dev List
On Mon, 2004-08-09 at 15:09, Luke Kenneth Casson Leighton wrote:
> thank you: i found this: i was more concerned that i should
> be setting mount -o fscontext=....fs_t instead?
No, I think device_t is appropriate here.
> allow initrc_t device_t:lnk_file { create };
> for a symlink to be created between /proc/self/fd and /dev/fd
>
> i realise it would be better to move stuff in /etc/init.d/udev
> to a separate program, e.g. /sbin/udev-init, and to have that
> program be given a separate domain instead of having to add
> this to initrc_t.
I already see an 'allow initrc_t device_t:lnk_file { unlink };' rule in
initrc.te related to udev operation, so this isn't too surprising.
> allow udev_t device_t:file { getattr unlink };
> for /sbin/udev to stat and remove /dev/null...
/dev/null should show up as chr_file, and should be created with
null_device_t anyway. Is this actually an attempt to unlink udev.tbl?
--
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: lots of allow xxx_device_t device_t:filesystem { associate }
2004-08-09 19:02 ` Stephen Smalley
@ 2004-08-09 19:43 ` Luke Kenneth Casson Leighton
-1 siblings, 0 replies; 13+ messages in thread
From: Luke Kenneth Casson Leighton @ 2004-08-09 19:43 UTC (permalink / raw)
To: Stephen Smalley, g; +Cc: SE-Linux, Linux Hotplug Dev List
On Mon, Aug 09, 2004 at 03:02:57PM -0400, Stephen Smalley wrote:
> On Mon, 2004-08-09 at 15:09, Luke Kenneth Casson Leighton wrote:
> > thank you: i found this: i was more concerned that i should
> > be setting mount -o fscontext=....fs_t instead?
>
> No, I think device_t is appropriate here.
>
> > allow initrc_t device_t:lnk_file { create };
> > for a symlink to be created between /proc/self/fd and /dev/fd
> >
> > i realise it would be better to move stuff in /etc/init.d/udev
> > to a separate program, e.g. /sbin/udev-init, and to have that
> > program be given a separate domain instead of having to add
> > this to initrc_t.
>
> I already see an 'allow initrc_t device_t:lnk_file { unlink };' rule in
> initrc.te related to udev operation, so this isn't too surprising.
>
> > allow udev_t device_t:file { getattr unlink };
> > for /sbin/udev to stat and remove /dev/null...
>
> /dev/null should show up as chr_file, and should be created with
> null_device_t anyway. Is this actually an attempt to unlink udev.tbl?
no, it's definitely an attempt to unlink /dev/null (!).
and it's definitely saying device_t:file.
_after_ init level 1 has completed, ls -Z /dev/null shows
null_device_t on /dev/null.
fuuunnn...
l.
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
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
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: lots of allow xxx_device_t device_t:filesystem { associate }
@ 2004-08-09 19:43 ` Luke Kenneth Casson Leighton
0 siblings, 0 replies; 13+ messages in thread
From: Luke Kenneth Casson Leighton @ 2004-08-09 19:43 UTC (permalink / raw)
To: Stephen Smalley, g; +Cc: SE-Linux, Linux Hotplug Dev List
On Mon, Aug 09, 2004 at 03:02:57PM -0400, Stephen Smalley wrote:
> On Mon, 2004-08-09 at 15:09, Luke Kenneth Casson Leighton wrote:
> > thank you: i found this: i was more concerned that i should
> > be setting mount -o fscontext=....fs_t instead?
>
> No, I think device_t is appropriate here.
>
> > allow initrc_t device_t:lnk_file { create };
> > for a symlink to be created between /proc/self/fd and /dev/fd
> >
> > i realise it would be better to move stuff in /etc/init.d/udev
> > to a separate program, e.g. /sbin/udev-init, and to have that
> > program be given a separate domain instead of having to add
> > this to initrc_t.
>
> I already see an 'allow initrc_t device_t:lnk_file { unlink };' rule in
> initrc.te related to udev operation, so this isn't too surprising.
>
> > allow udev_t device_t:file { getattr unlink };
> > for /sbin/udev to stat and remove /dev/null...
>
> /dev/null should show up as chr_file, and should be created with
> null_device_t anyway. Is this actually an attempt to unlink udev.tbl?
no, it's definitely an attempt to unlink /dev/null (!).
and it's definitely saying device_t:file.
_after_ init level 1 has completed, ls -Z /dev/null shows
null_device_t on /dev/null.
fuuunnn...
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: lots of allow xxx_device_t device_t:filesystem { associate }
2004-08-09 19:43 ` Luke Kenneth Casson Leighton
@ 2004-08-10 6:45 ` Russell Coker
-1 siblings, 0 replies; 13+ messages in thread
From: Russell Coker @ 2004-08-10 6:45 UTC (permalink / raw)
To: Luke Kenneth Casson Leighton
Cc: Stephen Smalley, g, SE-Linux, Linux Hotplug Dev List
On Tue, 10 Aug 2004 05:43, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> > /dev/null should show up as chr_file, and should be created with
> > null_device_t anyway. Is this actually an attempt to unlink udev.tbl?
>
> no, it's definitely an attempt to unlink /dev/null (!).
>
> and it's definitely saying device_t:file.
In that case you probably have a non-SE Linux bug. I guess that some program
is trying to send output to /dev/null when there is no /dev/null device.
--
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
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
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
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: lots of allow xxx_device_t device_t:filesystem { associate }
@ 2004-08-10 6:45 ` Russell Coker
0 siblings, 0 replies; 13+ messages in thread
From: Russell Coker @ 2004-08-10 6:45 UTC (permalink / raw)
To: Luke Kenneth Casson Leighton
Cc: Stephen Smalley, g, SE-Linux, Linux Hotplug Dev List
On Tue, 10 Aug 2004 05:43, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> > /dev/null should show up as chr_file, and should be created with
> > null_device_t anyway. Is this actually an attempt to unlink udev.tbl?
>
> no, it's definitely an attempt to unlink /dev/null (!).
>
> and it's definitely saying device_t:file.
In that case you probably have a non-SE Linux bug. I guess that some program
is trying to send output to /dev/null when there is no /dev/null device.
--
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: lots of allow xxx_device_t device_t:filesystem { associate }
2004-08-10 6:45 ` Russell Coker
@ 2004-08-10 12:45 ` Luke Kenneth Casson Leighton
-1 siblings, 0 replies; 13+ messages in thread
From: Luke Kenneth Casson Leighton @ 2004-08-10 12:45 UTC (permalink / raw)
To: Russell Coker; +Cc: Stephen Smalley, g, SE-Linux, Linux Hotplug Dev List
On Tue, Aug 10, 2004 at 04:45:28PM +1000, Russell Coker wrote:
> On Tue, 10 Aug 2004 05:43, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> > > /dev/null should show up as chr_file, and should be created with
> > > null_device_t anyway. Is this actually an attempt to unlink udev.tbl?
> >
> > no, it's definitely an attempt to unlink /dev/null (!).
> >
> > and it's definitely saying device_t:file.
>
> In that case you probably have a non-SE Linux bug. I guess that some program
> is trying to send output to /dev/null when there is no /dev/null device.
that'd make sense because the comments in /etc/init.d/udev say
"you can't do things like background scripts".
so, this one for _not_ including in the policy files.
l.
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
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
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: lots of allow xxx_device_t device_t:filesystem { associate }
@ 2004-08-10 12:45 ` Luke Kenneth Casson Leighton
0 siblings, 0 replies; 13+ messages in thread
From: Luke Kenneth Casson Leighton @ 2004-08-10 12:45 UTC (permalink / raw)
To: Russell Coker; +Cc: Stephen Smalley, g, SE-Linux, Linux Hotplug Dev List
On Tue, Aug 10, 2004 at 04:45:28PM +1000, Russell Coker wrote:
> On Tue, 10 Aug 2004 05:43, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> > > /dev/null should show up as chr_file, and should be created with
> > > null_device_t anyway. Is this actually an attempt to unlink udev.tbl?
> >
> > no, it's definitely an attempt to unlink /dev/null (!).
> >
> > and it's definitely saying device_t:file.
>
> In that case you probably have a non-SE Linux bug. I guess that some program
> is trying to send output to /dev/null when there is no /dev/null device.
that'd make sense because the comments in /etc/init.d/udev say
"you can't do things like background scripts".
so, this one for _not_ including in the policy files.
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: lots of allow xxx_device_t device_t:filesystem { associate }
2004-08-09 18:43 ` Stephen Smalley
2004-08-09 19:09 ` Luke Kenneth Casson Leighton
@ 2004-08-09 19:35 ` Luke Kenneth Casson Leighton
1 sibling, 0 replies; 13+ messages in thread
From: Luke Kenneth Casson Leighton @ 2004-08-09 19:35 UTC (permalink / raw)
To: Stephen Smalley; +Cc: SE-Linux
On Mon, Aug 09, 2004 at 02:43:36PM -0400, Stephen Smalley wrote:
> On Mon, 2004-08-09 at 13:52, Luke Kenneth Casson Leighton wrote:
> > i'm getting an awful lot of the above due to udev creating
> > inodes in /dev which i decided to associate with device_t.
>
> allow device_type device_t:filesystem associate;
> should cover most cases.
>
> > now i have had to add about 15 or 20 lines so far each for pretty
> > much every xxx_device_t under the sun, and am concerned that i
> > am taking the wrong approach.
>
> Other than the associate permission, what else do you need to add?
okay, i'm attaching my horrible_hacks.te file...
# this is to deal with restorecon devices being associated with udev's
# mounting of /dev as a fscontext=device_t. help, help, gloop!
allow console_device_t device_t:filesystem { associate };
allow devtty_t device_t:filesystem { associate };
allow fixed_disk_device_t device_t:filesystem { associate };
allow memory_device_t device_t:filesystem { associate };
allow mouse_device_t device_t:filesystem { associate };
allow null_device_t device_t:filesystem { associate };
allow ptmx_t device_t:filesystem { associate };
allow random_device_t device_t:filesystem { associate };
allow sound_device_t device_t:filesystem { associate };
allow tty_device_t device_t:filesystem { associate };
allow urandom_device_t device_t:filesystem { associate };
allow zero_device_t device_t:filesystem { associate };
allow device_t device_t:filesystem { associate };
allow initctl_t device_t:filesystem { associate };
allow udev_tbl_t device_t:filesystem { associate };
allow event_device_t device_t:filesystem { associate };
# this is to allow /etc/init.d/udev to do its horrible hacks
# if it wasn't done in /etc/init.d or it wasn't device_t under which
# /dev was mounted (mount ... -o fscontext=....device_t) then this
# would be different or not there:
allow initrc_t device_t:dir { create setattr };
#EXE=/bin/mkdir NAME=pts : create
#EXE=/bin/touch NAME=/ : setattr
allow initrc_t device_t:lnk_file { create };
#EXE=/bin/ln NAME=fd : create
allow initrc_t device_t:blk_file { getattr };
#EXE=/bin/ls PATH=/dev/ram0 : getattr
allow initrc_t device_t:chr_file { getattr read write };
#EXE=/bin/bash NAME=tty : read write
#EXE=/bin/ls PATH=/dev/ptmx : getattr
# not sure about this one
allow initrc_t fixed_disk_device_t:blk_file { getattr };
#EXE=/bin/bash PATH=/dev/ram0 : getattr
allow init_t device_t:fifo_file { getattr read write };
#EXE=/sbin/init PATH=/dev/initctl : getattr
#EXE=/sbin/init NAME=initctl : read write
#
# plus the allow udev ones...
--
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2004-08-10 12:45 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-08-09 17:52 lots of allow xxx_device_t device_t:filesystem { associate } Luke Kenneth Casson Leighton
2004-08-09 18:43 ` Stephen Smalley
2004-08-09 18:59 ` Luke Kenneth Casson Leighton
2004-08-09 19:09 ` Luke Kenneth Casson Leighton
2004-08-09 19:02 ` Stephen Smalley
2004-08-09 19:02 ` Stephen Smalley
2004-08-09 19:43 ` Luke Kenneth Casson Leighton
2004-08-09 19:43 ` Luke Kenneth Casson Leighton
2004-08-10 6:45 ` Russell Coker
2004-08-10 6:45 ` Russell Coker
2004-08-10 12:45 ` Luke Kenneth Casson Leighton
2004-08-10 12:45 ` Luke Kenneth Casson Leighton
2004-08-09 19:35 ` Luke Kenneth Casson Leighton
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.