about the safety problem in SELinux

about the safety problem in SELinux

[selinux list]

I'm studying the well known ¨safety problem¨ stated the first time in an 
old article by Harrison, Ruzzu, Ullman.
I know there exist lots of different security models that try to address 
the problem of guarantee the safety of a protection system (in a few 
words, a generic configuratrion of a protection system is said to be 
safe if there is no leakage of any generic right from that 
configuration; in other words there is no propagation of rights). Type 
Enforcement should be safe for default. If I am not wrong it has been 
demonstrated RBAC is not safe in general. There are some 
constraint-oriented  approaches which seems to be good in providing safety.

What about SELinux?

I know some of the people who subscribed this mail list are not sure 
SELinux is safe. But in the Flask doc it's written the control over 
right propagation is provided by ensuring that the security policy is 
consulted every time an object has to be accessed (e.g. for every 
security decision). Another thing that let me guess SELinux should be 
safe is that almost everything is configured by TE (RBAC support is very 
poor) and, above all, it is statically configured.
How could a subject acquire a right which is not granted by the security 
policy?
It sounds to me it's trivial to say SELinux is safe but it's a 
formidable task to configure the security policy in a way it can be 
considered secure.

Is it right what I am thinking about or I am on the wrong way?

(I am developing a small tool for policy analisis purpose, for my 
Graduate School Thesis,  and if SELinux is safe it would be of more 
value...)

Thank you and sorry if what I wrote is silly ;)

Giorgio



_________________________________________________________________
Il servizio Postemail sottopone tutti i documenti a una scansione
automatica antivirus con i programmi TREND MICRO.

--
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: about the safety problem in SELinux

[Stephen Smalley]

On Wed, 2003-05-14 at 18:29, selinux list wrote:  
> This is exactly what is prescribed by TE (and its variants like DTE).
> It is why I am so sure the safety problem in SELinux is so trivially
> solved...SELinux should be safe because with Type Enforcement every
> time a subject moves from a domain to another domain, the rights it
> had are lost and others are acquired. 

SELinux implements MAC, so a process cannot transfer rights
(descriptors) to another process unless the recipient process is also
authorized to access the object in the same manner by the MAC policy
(which can only be changed administratively).  SELinux controls
descriptor inheritance across execve (when security context transitions
occur for a process) and descriptor transfer via Unix domain socket IPC.
It also typically revalidates permission on access to deal with
revocation due to a file relabel or policy change; however, this is not
yet complete - we do not presently provide revocation for memory-mapped
files.  Security context transitions are controlled by the policy, as
are file relabels.

Of course, proving specific security properties requires an analysis of
the particular policy configuration.  SELinux just provides the
mechanism for enforcing the policy.

> I completely agree, but SELinux seems safe to me not becouse of RBAC
> support (it is just a user-centric concept to group some user
> identities to assign to some domains...probably SELinux could work
> fine even without RBAC support at all...), but thanks to TE.

Correct.  However, some people like to use the RBAC component as a
further boundary on domain transitions, e.g. you could potentially allow
domain D1 to transition to domain D2 but only permit role R1 to enter
domain D1 and role R2 to enter domain D1 and domain D2.  Using the RBAC
component in that manner is a bit dangerous, as you have to make sure
that there aren't any other permissions granted from D1 to D2 that could
allow R1:D1 to interfere with R2:D2, e.g. signal permissions.

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

slow application of contexts in devfs?

[Christopher J. PeBenito]

I'm running the 2003040709 lsm and selinux patches on a stock kernel,
and I'm seeing some weird behavior on devfs.  When starting up, it seems
that its taking a long time for the contexts to be correctly set on
devfs files (in this case /dev/log).  Here's the appropriate segment of
the kernel messages.  You can see that the policy is loaded, and devfs
is set up using genfs_contexts.  Then shortly later after devfs is
mounted, devfsd gets a denial writing to /dev/log, because its still
labeled as device_t

SELinux:  Completing initialization.
security:  loading policy configuration from
/etc/security/selinux/policy.12
security:  4 users, 5 roles, 467 types
security:  29 classes, 34324 rules
SELinux: initialized (dev 03:03, type ext3), uses PSIDs
SELinux: initialized (dev 00:08, type devpts), uses transition SIDs
SELinux: initialized (dev 00:07, type devfs), uses genfs_contexts
SELinux: initialized (dev 00:06, type binfmt_misc), not configured for
labeling
SELinux: initialized (dev 00:05, type pipefs), uses task SIDs
SELinux: initialized (dev 00:04, type tmpfs), uses transition SIDs
SELinux: initialized (dev 00:03, type sockfs), uses task SIDs
SELinux: initialized (dev 00:02, type proc), uses genfs_contexts
SELinux: initialized (dev 00:01, type bdev), not configured for labeling
SELinux: initialized (dev 00:00, type rootfs), not configured for
labeling
Mounted devfs on /dev
Freeing unused kernel memory: 280k freed
avc:  denied  { write } for  pid=148 exe=/sbin/devfsd path=/log
dev=00:07 ino=421 scontext=system_u:system_r:devfsd_t
tcontext=system_u:object_r:device_t tclass=sock_file


Now, I've verified that the genfscon does exist, grepped out of
policy.conf:

genfscon devfs /log                     system_u:object_r:devlog_t


Its also not just devfsd getting denials, there is a denial on syslog
later on in the boot process.  By the time the machine is done starting
up, /dev/log does have the right context:

srw-rw-rw-  root     root     system_u:object_r:devlog_t       /dev/log

-- 
Chris PeBenito
<pebenito@ieee.org>
AIM: PeBenito78
ICQ#: 10434387

"Engineering does not require science. Science helps
a lot, but people built perfectly good brick walls 
long before they knew why cement works."-Alan Cox

--
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: slow application of contexts in devfs?

[Stephen Smalley]

On Thu, 2003-05-15 at 12:31, Christopher J. PeBenito wrote:
> I'm running the 2003040709 lsm and selinux patches on a stock kernel,
> and I'm seeing some weird behavior on devfs.  When starting up, it seems
> that its taking a long time for the contexts to be correctly set on
> devfs files (in this case /dev/log).  Here's the appropriate segment of
> the kernel messages.  You can see that the policy is loaded, and devfs
> is set up using genfs_contexts.  Then shortly later after devfs is
> mounted, devfsd gets a denial writing to /dev/log, because its still
> labeled as device_t

/dev/log is a name for a Unix domain socket created by syslogd.  Until
syslogd is running and has bound a socket to /dev/log, writing to
/dev/log isn't going to work regardless of your policy.  When syslogd
binds its socket to /dev/log, then it will pick up the correct type
based on the file type transition rule, as with other file creations. 
Why does /dev/log even exist in devfs before syslogd has bound to it? 

-- 
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: slow application of contexts in devfs?

[Russell Coker]

On Fri, 16 May 2003 05:02, Stephen Smalley wrote:
> > is set up using genfs_contexts.  Then shortly later after devfs is
> > mounted, devfsd gets a denial writing to /dev/log, because its still
> > labeled as device_t
>
> /dev/log is a name for a Unix domain socket created by syslogd.  Until
> syslogd is running and has bound a socket to /dev/log, writing to
> /dev/log isn't going to work regardless of your policy.  When syslogd
> binds its socket to /dev/log, then it will pick up the correct type
> based on the file type transition rule, as with other file creations.
> Why does /dev/log even exist in devfs before syslogd has bound to it?

/dev/log doesn't exist in devfs before syslogd has run.

My guess is that syslogd is running in the wrong domain and therefore the type 
transition does not apply.  "ps ax --context | grep syslogd" should give a 
good clue.  Of course for this to happen the machine must have booted in 
permissive mode.

Christopher, would you happen to be running something other than the regular 
syslogd?  Maybe a different syslogd with a file name that doesn't match the 
pattern?

-- 
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: slow application of contexts in devfs?

[Christopher J. PeBenito]

I am using metalog, however I've already fixed up the file contexts, so
its running in the correct domain.  The fact (which didnt occur to me
earlier) is that devfsd starts up before the syslogger in Gentoo.  So
I'll check with our init scripts guy to see why its like this, and if
its possible to reorder this (devfsd's start is in /sbin/rc, not a
regular init script).  Otherwise, I'll just put it on dontaudit.  The
devfsd startup message isn't very interesting anyway.

Chris

On Thu, 2003-05-15 at 18:45, Russell Coker wrote:
> /dev/log doesn't exist in devfs before syslogd has run.
> 
> My guess is that syslogd is running in the wrong domain and therefore the type 
> transition does not apply.  "ps ax --context | grep syslogd" should give a 
> good clue.  Of course for this to happen the machine must have booted in 
> permissive mode.
> 
> Christopher, would you happen to be running something other than the regular 
> syslogd?  Maybe a different syslogd with a file name that doesn't match the 
> pattern?
-- 
Chris PeBenito
<pebenito@ieee.org>
AIM: PeBenito78
ICQ#: 10434387

"Engineering does not require science. Science helps
a lot, but people built perfectly good brick walls 
long before they knew why cement works."-Alan Cox

--
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: slow application of contexts in devfs?

[Russell Coker]

On Fri, 16 May 2003 13:12, Christopher J. PeBenito wrote:
> I am using metalog, however I've already fixed up the file contexts, so

Please tell us the file name so it can be included into the standard policy to 
avoid other people having the same problem.

> its running in the correct domain.  The fact (which didnt occur to me
> earlier) is that devfsd starts up before the syslogger in Gentoo.  So

This is the way it should be.  devfsd starts before sysklogd in Debian too and 
everything works fine.

Are you running that cut-down syslogd that Red Hat uses for the early stages 
of their boot process (the one that causes all the problems)?  If so make 
sure that it is also labelled with the correct context, and also please tell 
us the file name.

-- 
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: slow application of contexts in devfs?

[Stephen Smalley]

On Thu, 2003-05-15 at 23:12, Christopher J. PeBenito wrote:
> I am using metalog, however I've already fixed up the file contexts, so
> its running in the correct domain.  The fact (which didnt occur to me
> earlier) is that devfsd starts up before the syslogger in Gentoo.  So
> I'll check with our init scripts guy to see why its like this, and if
> its possible to reorder this (devfsd's start is in /sbin/rc, not a
> regular init script).  Otherwise, I'll just put it on dontaudit.  The
> devfsd startup message isn't very interesting anyway.

/dev/log shouldn't exist in devfs prior to syslogd (or metalog)
starting.  But perhaps your devfsd is automatically restoring /dev
entries from a backup when it initializes, thereby creating an orphaned
/dev/log that is subsequently removed and re-created by syslogd.

You may need to grant syslogd permission to unlink device_t:sock_file so
that it can remove the orphaned /dev/log left by devfsd.

-- 
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: slow application of contexts in devfs?

[Christopher J. PeBenito]

On Fri, 2003-05-16 at 06:40, Stephen Smalley wrote:
> /dev/log shouldn't exist in devfs prior to syslogd (or metalog)
> starting.  But perhaps your devfsd is automatically restoring /dev
> entries from a backup when it initializes, thereby creating an orphaned
> /dev/log that is subsequently removed and re-created by syslogd.
> 
> You may need to grant syslogd permission to unlink device_t:sock_file so
> that it can remove the orphaned /dev/log left by devfsd.

I agree with your assessment, Stephen.  There is an entry for /dev/log
in devfsd's "dev-state" directory.  Devfsd is restoring this on its
startup.  So, I added:

REGISTER ^log CFUNCTION devfsd-se.so set_sid $devname
system_u:object_r:devlog_t

to my devfsd conflet.  That took care of metalog's unlink denial for
/dev/log.  However, devfsd still gets the denial writing to to /dev/log
because its still system_u:object_r:device_t.  Its somewhat confusing; I
would have thought that the write to /dev/log would be after devfsd's
initialization, so /dev/log would have the correct context.

Another option would be to try to stop devfsd from saving /dev/log into
dev-state in the first place.  Then /dev/log shouldn't be restored at
all.  This is seeming like the cleaner/saner option.

The binary for metalog is metalog.  If you'd like to look at it:
http://metalog.sourceforge.net/.  I like it because of it's built-in
rotation of logs based on age or size, and simple configuration.  The
problem is that metalog is klogd+syslogd, so it doesnt fit in syslogd_t
nicely (I didn't try running it in klogd_t, that might work better).  I
just added policy to syslogd.te.

-- 
Chris PeBenito
<pebenito@ieee.org>
AIM: PeBenito78
ICQ#: 10434387

"Engineering does not require science. Science helps
a lot, but people built perfectly good brick walls 
long before they knew why cement works."-Alan Cox

--
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: slow application of contexts in devfs?

[Russell Coker]

On Sun, 18 May 2003 03:05, Christopher J. PeBenito wrote:
> to my devfsd conflet.  That took care of metalog's unlink denial for
> /dev/log.  However, devfsd still gets the denial writing to to /dev/log
> because its still system_u:object_r:device_t.  Its somewhat confusing; I
> would have thought that the write to /dev/log would be after devfsd's
> initialization, so /dev/log would have the correct context.

It will log the fact that it is changing the SID of /dev/log...

> Another option would be to try to stop devfsd from saving /dev/log into
> dev-state in the first place.  Then /dev/log shouldn't be restored at
> all.  This is seeming like the cleaner/saner option.

That is the correct option.

> The binary for metalog is metalog.  If you'd like to look at it:
> http://metalog.sourceforge.net/.  I like it because of it's built-in
> rotation of logs based on age or size, and simple configuration.  The
> problem is that metalog is klogd+syslogd, so it doesnt fit in syslogd_t
> nicely (I didn't try running it in klogd_t, that might work better).  I
> just added policy to syslogd.te.

I have been considering merging the two domains for smaller systems.  Maybe it 
would be worth doing for the general case?  The difference between them is 
that klogd can read system_map_t (*), and the kernel message log, while 
syslogd is permitted network access, can write files to disk under /var/log, 
and can create /dev/log.

By merging the two we allow syslogd to read system map files under /boot which 
isn't that important and we allow syslogd to read the kernel message log 
directly (as it gets all the same data indirectly anyway that does not seem a 
problem).  klogd gets to write files under /var/log and to create a socket 
under /dev.  Is this enough of a problem to need a separate domain?


(*) The current policy allows reading file and lnk_file objects of boot_t as 
well.  A quick test suggests that klogd does not need such boot_t file access 
and I have changed my policy accordingly.

-- 
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: slow application of contexts in devfs?

[Christopher J. PeBenito]

Well the IGNOREs in the devfsd.conf for /dev/log took care of the
denials.

Most Gentoo users tend to use syslogs that don't have a separate klogd
(syslog-ng, metalog, msyslog), so I've been merging klogd and syslogd. 
In the case of sysklogd, we felt that it was reasonable to run klogd and
syslogd in the same domain.  Of course theres nothing stopping the users
from getting the separate syslogd and klogd policies if they really want
it.

On Sat, 2003-05-17 at 14:11, Russell Coker wrote: 
> On Sun, 18 May 2003 03:05, Christopher J. PeBenito wrote:
> > problem is that metalog is klogd+syslogd, so it doesnt fit in syslogd_t
> > nicely (I didn't try running it in klogd_t, that might work better).  I
> > just added policy to syslogd.te.
> 
> I have been considering merging the two domains for smaller systems.  Maybe it 
> would be worth doing for the general case?  The difference between them is 
> that klogd can read system_map_t (*), and the kernel message log, while 
> syslogd is permitted network access, can write files to disk under /var/log, 
> and can create /dev/log.
> 
> By merging the two we allow syslogd to read system map files under /boot which 
> isn't that important and we allow syslogd to read the kernel message log 
> directly (as it gets all the same data indirectly anyway that does not seem a 
> problem).  klogd gets to write files under /var/log and to create a socket 
> under /dev.  Is this enough of a problem to need a separate domain?
> 
> 
> (*) The current policy allows reading file and lnk_file objects of boot_t as 
> well.  A quick test suggests that klogd does not need such boot_t file access 
> and I have changed my policy accordingly.

-- 
Chris PeBenito
<pebenito@ieee.org>
AIM: PeBenito78
ICQ#: 10434387

"Engineering does not require science. Science helps
a lot, but people built perfectly good brick walls 
long before they knew why cement works."-Alan Cox

--
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: slow application of contexts in devfs?

[Stephen Smalley]

On Sat, 2003-05-17 at 13:05, Christopher J. PeBenito wrote:
> The binary for metalog is metalog.  If you'd like to look at it:
> http://metalog.sourceforge.net/.  I like it because of it's built-in
> rotation of logs based on age or size, and simple configuration.  The
> problem is that metalog is klogd+syslogd, so it doesnt fit in syslogd_t
> nicely (I didn't try running it in klogd_t, that might work better).  I
> just added policy to syslogd.te.

Given that it performs rotation of the logs, you may want to also look
into integrating the logrotate.te policy and the logrotate patch into
metalog.  The logrotate patch is necessary to ensure that the log
security contexts are preserved when they are rotated.

-- 
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: slow application of contexts in devfs?

[Stephen Smalley]

On Sat, 2003-05-17 at 15:11, Russell Coker wrote:
> I have been considering merging the two domains for smaller systems.  Maybe it 
> would be worth doing for the general case?  The difference between them is 
> that klogd can read system_map_t (*), and the kernel message log, while 
> syslogd is permitted network access, can write files to disk under /var/log, 
> and can create /dev/log.
> 
> By merging the two we allow syslogd to read system map files under /boot which 
> isn't that important and we allow syslogd to read the kernel message log 
> directly (as it gets all the same data indirectly anyway that does not seem a 
> problem).  klogd gets to write files under /var/log and to create a socket 
> under /dev.  Is this enough of a problem to need a separate domain?

klogd can be redirected to a particular file rather than going through
syslogd, and syslogd may be set up to accept remote logging requests as
well as local ones.  Hence, it may be worthwhile to keep them as
separate domains in the example policy, even if people choose to fold
them in certain environments.
  
-- 
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: slow application of contexts in devfs?

[Russell Coker]

On Mon, 19 May 2003 21:39, Stephen Smalley wrote:
> On Sat, 2003-05-17 at 13:05, Christopher J. PeBenito wrote:
> > The binary for metalog is metalog.  If you'd like to look at it:
> > http://metalog.sourceforge.net/.  I like it because of it's built-in
> > rotation of logs based on age or size, and simple configuration.  The
> > problem is that metalog is klogd+syslogd, so it doesnt fit in syslogd_t
> > nicely (I didn't try running it in klogd_t, that might work better).  I
> > just added policy to syslogd.te.
>
> Given that it performs rotation of the logs, you may want to also look
> into integrating the logrotate.te policy and the logrotate patch into
> metalog.  The logrotate patch is necessary to ensure that the log
> security contexts are preserved when they are rotated.

logrotate runs scripts related to log file rotation on behalf of daemons 
(generally scripts to do whatever is necessary to cause the daemon to use the 
new files).  Having all this done in the main syslogd_t domain is probably 
not desirable.  But then having all the things in logrotate_t that are 
currently in it probably isn't a good idea either.  Maybe if we change 
logrotate to use a different domain for those scripts then we could have it 
run in syslogd_t.

Another issue is that it would be nice to have syslogd only be able to create 
and append to log files, not delete or modify.

-- 
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: slow application of contexts in devfs?

[Christopher J. PeBenito]

I should be more specific, metalog only rotates the logs
created/modified by itself, not logs from daemons that don't log thru
syslog.  So, stuff like the apache access/error log or mysqld logs are
still rotated with logrotate.

On Mon, 2003-05-19 at 06:39, Stephen Smalley wrote:
> On Sat, 2003-05-17 at 13:05, Christopher J. PeBenito wrote:
> > http://metalog.sourceforge.net/.  I like it because of it's built-in
> > rotation of logs based on age or size, and simple configuration.  The
> Given that it performs rotation of the logs, you may want to also look
> into integrating the logrotate.te policy and the logrotate patch into
> metalog.  The logrotate patch is necessary to ensure that the log
> security contexts are preserved when they are rotated.
-- 
Chris PeBenito
<pebenito@ieee.org>
AIM: PeBenito78
ICQ#: 10434387

"Engineering does not require science. Science helps
a lot, but people built perfectly good brick walls 
long before they knew why cement works."-Alan Cox

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

SE Linux mentioned in large Australian newspaper website

[Faye]

Russell has been interviewed for the Technology section of Australia's
"The Age" newspaper, and talks about SE Linux:

http://www.theage.com.au/articles/2003/07/02/1056825450368.html

faye
-- 
Message from Our Sponsor on ttytv at 00:01 ...
Faye Coker			    faye@lurking-grue.org
Current stomping ground: 	    Melbourne, Australia 


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