Re: user guide drafts: Maintaining SELinux Labels

Re: user guide drafts: Maintaining SELinux Labels

[Murray McAllister]

Clarkson, Mike R (US SSA) wrote:
> 
>> -----Original Message-----
>> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov]
> On
>> Behalf Of Glenn Faden
>> Sent: Wednesday, October 08, 2008 8:46 AM
>> To: Daniel J Walsh
>> Cc: Murray McAllister; SE Linux
>> Subject: Re: user guide drafts: Maintaining SELinux Labels
>>
>> Daniel J Walsh wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Murray McAllister wrote:
>>>
>>>> Hi,
>>>>
>>>> The following are the first few drafts of the "Maintaining SELinux
>>>> Labels" sections. Any comments and corrections are appreciated.
>>>>
>>>> Cheers.
>>>>
>>>> Copying Files and Directories
>>>>
>>>> When files and directories are copied, they inherit the SELinux
> context
>>>> of the parent directory they are copied to. This helps ensure files
> and
>>>> directories are labeled with the correct SELinux context after
> being
>>>> moved. The following example demonstrates copying a file from a
> user's
>>>> home directory to /var/www/html/, which is used by the Apache HTTP
>>>> Server. Since the file is copied, it inherits the correct SELinux
>> context:
>> Is this true when using MLS policy? Assuming the policy allows a
> subject
>> to create a file in a directory, shouldn't the newly created file's
>> SELinux context have the same sensitivity as the subject who wrote it?
> 
>> Or is the new file's type copied from the directory and the
> sensitivity
>> copied from the subject?
> 
> You are correct, the type is copied from the directory and the level is
> copied from the subject. It might also be worth mentioning that the type
> is copied from the directory as default behavior, which can be
> overridden with type_transition statements.
> 
>> --Glenn
I've changed the first paragraph. How about:

When files and directories are copied, they inherit the SELinux context 
of the parent directory they are copied to[1]. This helps ensure files 
and directories are labeled with the correct SELinux context after being 
copied. Also, when a file is copied over an existing file, the existing 
file's context is maintained. On systems running the MLS policy, when 
files are copied, they inherit the type from the parent directory they 
are being copied to, and the level from the process that copied them.

Is the last sentence, is "the level from the process that copied them" 
correct? Should it be "from the process or user that..."?

[1] By default, the type is copied from the parent directory. This 
behavior can be overridden by using type_transition statements in custom 
SELinux policies.

I've included an example at the end of the section to show copying a 
file over an existing one.

Thanks for your feedback.

--
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: user guide drafts: Maintaining SELinux Labels

[Stephen Smalley]

On Thu, 2008-10-09 at 10:26 +1000, Murray McAllister wrote:
> Clarkson, Mike R (US SSA) wrote:
> > 
> >> -----Original Message-----
> >> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov]
> > On
> >> Behalf Of Glenn Faden
> >> Sent: Wednesday, October 08, 2008 8:46 AM
> >> To: Daniel J Walsh
> >> Cc: Murray McAllister; SE Linux
> >> Subject: Re: user guide drafts: Maintaining SELinux Labels
> >>
> >> Daniel J Walsh wrote:
> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >>> Hash: SHA1
> >>>
> >>> Murray McAllister wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> The following are the first few drafts of the "Maintaining SELinux
> >>>> Labels" sections. Any comments and corrections are appreciated.
> >>>>
> >>>> Cheers.
> >>>>
> >>>> Copying Files and Directories
> >>>>
> >>>> When files and directories are copied, they inherit the SELinux
> > context
> >>>> of the parent directory they are copied to. This helps ensure files
> > and
> >>>> directories are labeled with the correct SELinux context after
> > being
> >>>> moved. The following example demonstrates copying a file from a
> > user's
> >>>> home directory to /var/www/html/, which is used by the Apache HTTP
> >>>> Server. Since the file is copied, it inherits the correct SELinux
> >> context:
> >> Is this true when using MLS policy? Assuming the policy allows a
> > subject
> >> to create a file in a directory, shouldn't the newly created file's
> >> SELinux context have the same sensitivity as the subject who wrote it?
> > 
> >> Or is the new file's type copied from the directory and the
> > sensitivity
> >> copied from the subject?
> > 
> > You are correct, the type is copied from the directory and the level is
> > copied from the subject. It might also be worth mentioning that the type
> > is copied from the directory as default behavior, which can be
> > overridden with type_transition statements.
> > 
> >> --Glenn
> I've changed the first paragraph. How about:
> 
> When files and directories are copied, they inherit the SELinux context 
> of the parent directory they are copied to[1].

Not exactly, no.  The security context of a new file is computed from a
combination of the security context of the creating process and the
security context of the parent directory, and may further be adjusted by
policy rules.  The user identity and level are inherited from the
creating process.  The role is always object_r presently.  The type is
inherited from the parent directory unless there is a type transition
rule in the policy for the (creating process domain, parent directory
type, file object class) triple.  For example, when a process creates a
file in /tmp, there is usually a type transition rule defined such that
each domain gets its own private temporary file type.

>  This helps ensure files 
> and directories are labeled with the correct SELinux context after being 
> copied. Also, when a file is copied over an existing file, the existing 
> file's context is maintained.

Unless the user specified options to cp to preserve the context of the
original on the copy.

>  On systems running the MLS policy, when 
> files are copied, they inherit the type from the parent directory they 
> are being copied to, and the level from the process that copied them.
> 
> Is the last sentence, is "the level from the process that copied them" 
> correct? Should it be "from the process or user that..."?
> 
> [1] By default, the type is copied from the parent directory. This 
> behavior can be overridden by using type_transition statements in custom 
> SELinux policies.
> 
> I've included an example at the end of the section to show copying a 
> file over an existing one.
> 
> Thanks for your feedback.
> 
> --
> 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.
-- 
Stephen Smalley
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: user guide drafts: Maintaining SELinux Labels

[Murray McAllister]

Stephen Smalley wrote:
> On Thu, 2008-10-09 at 10:26 +1000, Murray McAllister wrote:
>> Clarkson, Mike R (US SSA) wrote:
>>>> -----Original Message-----
>>>> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov]
>>> On
>>>> Behalf Of Glenn Faden
>>>> Sent: Wednesday, October 08, 2008 8:46 AM
>>>> To: Daniel J Walsh
>>>> Cc: Murray McAllister; SE Linux
>>>> Subject: Re: user guide drafts: Maintaining SELinux Labels
>>>>
>>>> Daniel J Walsh wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Murray McAllister wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> The following are the first few drafts of the "Maintaining SELinux
>>>>>> Labels" sections. Any comments and corrections are appreciated.
>>>>>>
>>>>>> Cheers.
>>>>>>
>>>>>> Copying Files and Directories
>>>>>>
>>>>>> When files and directories are copied, they inherit the SELinux
>>> context
>>>>>> of the parent directory they are copied to. This helps ensure files
>>> and
>>>>>> directories are labeled with the correct SELinux context after
>>> being
>>>>>> moved. The following example demonstrates copying a file from a
>>> user's
>>>>>> home directory to /var/www/html/, which is used by the Apache HTTP
>>>>>> Server. Since the file is copied, it inherits the correct SELinux
>>>> context:
>>>> Is this true when using MLS policy? Assuming the policy allows a
>>> subject
>>>> to create a file in a directory, shouldn't the newly created file's
>>>> SELinux context have the same sensitivity as the subject who wrote it?
>>>> Or is the new file's type copied from the directory and the
>>> sensitivity
>>>> copied from the subject?
>>> You are correct, the type is copied from the directory and the level is
>>> copied from the subject. It might also be worth mentioning that the type
>>> is copied from the directory as default behavior, which can be
>>> overridden with type_transition statements.
>>>
>>>> --Glenn
>> I've changed the first paragraph. How about:
>>
>> When files and directories are copied, they inherit the SELinux context 
>> of the parent directory they are copied to[1].
> 
> Not exactly, no.  The security context of a new file is computed from a
> combination of the security context of the creating process and the
> security context of the parent directory, and may further be adjusted by
> policy rules.  The user identity and level are inherited from the
> creating process.  The role is always object_r presently.  The type is
> inherited from the parent directory unless there is a type transition
> rule in the policy for the (creating process domain, parent directory
> type, file object class) triple.  For example, when a process creates a
> file in /tmp, there is usually a type transition rule defined such that
> each domain gets its own private temporary file type.
> 
>>  This helps ensure files 
>> and directories are labeled with the correct SELinux context after being 
>> copied. Also, when a file is copied over an existing file, the existing 
>> file's context is maintained.
> 
> Unless the user specified options to cp to preserve the context of the
> original on the copy.
Thanks. How about:

When files and directories are copied, the SELinux context of the new 
file or directory depends on the context of the creating process, and 
the context of the target, parent directory: the type is inherited from 
the target, parent directory (unless a type transition rule exists[1]); 
the SELinux user identity and level are inherited from the creating 
process; and the role is always object_r, which is a generic role for 
files. This helps ensure files and directories are labeled with the 
correct SELinux context after being copied.

Also, when a file is copied over an existing file, the existing file's 
context is maintained, unless the user specified cp options to preserve 
the context of the original file, such as --preserve=context.

#Is the following required, or is it covered by the above:

On systems running the MLS policy, when files and directories are 
copied, they inherit the type from the parent directory they are being 
copied to, and the level from the process that copied them.

[1] By default, the type is copied from the parent directory. This 
behavior can be overridden by using type_transition statements in custom 
SELinux policies. Type transition rules are for a creating process 
domain, parent directory type, and file object class triple. For 
example, when a process creates a file in /tmp/, a type transition rule 
is usually defined so that each domain gets its own private, temporary 
file type.
>>  On systems running the MLS policy, when 
>> files are copied, they inherit the type from the parent directory they 
>> are being copied to, and the level from the process that copied them.
>>
>> Is the last sentence, is "the level from the process that copied them" 
>> correct? Should it be "from the process or user that..."?
>>
>> [1] By default, the type is copied from the parent directory. This 
>> behavior can be overridden by using type_transition statements in custom 
>> SELinux policies.
>>
>> I've included an example at the end of the section to show copying a 
>> file over an existing one.
>>
>> Thanks for your feedback.
>>
>> --
>> 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.


--
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: user guide drafts: Maintaining SELinux Labels

[Russell Coker]

On Saturday 11 October 2008 15:15, Murray McAllister <mmcallis@redhat.com> 
wrote:
> When files and directories are copied, the SELinux context of the new
> file or directory depends on the context of the creating process, and
> the context of the target, parent directory: the type is inherited from
> the target, parent directory (unless a type transition rule exists[1]);
> the SELinux user identity and level are inherited from the creating
> process; and the role is always object_r, which is a generic role for
> files. This helps ensure files and directories are labeled with the
> correct SELinux context after being copied.

I'm not sure how the last sentence is supposed to link with the rest - it 
certainly doesn't correspond to the second-last sentence.

object_r is for future support and also to give a regular format of the 
context for all operations.  Note that files under /proc that relate to 
processes have different roles.

> Also, when a file is copied over an existing file, the existing file's
> context is maintained, unless the user specified cp options to preserve
> the context of the original file, such as --preserve=context.

Also the -Z option to cp deserves a mention.

> #Is the following required, or is it covered by the above:
>
> On systems running the MLS policy, when files and directories are
> copied, they inherit the type from the parent directory they are being
> copied to, and the level from the process that copied them.

Probably.

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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: user guide drafts: Maintaining SELinux Labels

[Murray McAllister]

Russell Coker wrote:
> On Saturday 11 October 2008 15:15, Murray McAllister <mmcallis@redhat.com> 
> wrote:
>> When files and directories are copied, the SELinux context of the new
>> file or directory depends on the context of the creating process, and
>> the context of the target, parent directory: the type is inherited from
>> the target, parent directory (unless a type transition rule exists[1]);
>> the SELinux user identity and level are inherited from the creating
>> process; and the role is always object_r, which is a generic role for
>> files. This helps ensure files and directories are labeled with the
>> correct SELinux context after being copied.
> 
> I'm not sure how the last sentence is supposed to link with the rest - it 
> certainly doesn't correspond to the second-last sentence.
That was from the old, wrong text. I moved it around a little:

When files and directories are copied, the SELinux context of the new 
file or directory depends on the context of the creating process, and 
the context of the target, parent directory. This helps ensure files and 
directories are labeled with the correct SELinux context after being 
copied. When files and directories are copied, the type is inherited...
> 
> object_r is for future support and also to give a regular format of the 
> context for all operations.  Note that files under /proc that relate to 
> processes have different roles.
I could only find the system_r and object_r roles in /proc/. Are there 
any others? /proc/pid/* seem to only use system_r (I did not check 
everything).

How about:

object_r is a generic role for used most files. Under the /proc/ 
directory, files relating to processes may use the system_r role.

Thanks again for your help.
> 
>> Also, when a file is copied over an existing file, the existing file's
>> context is maintained, unless the user specified cp options to preserve
>> the context of the original file, such as --preserve=context.
> 
> Also the -Z option to cp deserves a mention.
> 
>> #Is the following required, or is it covered by the above:
>>
>> On systems running the MLS policy, when files and directories are
>> copied, they inherit the type from the parent directory they are being
>> copied to, and the level from the process that copied them.
> 
> Probably.
> 

--
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: user guide drafts: Maintaining SELinux Labels

[Russell Coker]

On Sunday 12 October 2008 10:44, Murray McAllister <mmcallis@redhat.com> 
wrote:
> > object_r is for future support and also to give a regular format of the
> > context for all operations.  Note that files under /proc that relate to
> > processes have different roles.
>
> I could only find the system_r and object_r roles in /proc/. Are there
> any others? /proc/pid/* seem to only use system_r (I did not check
> everything).

Run in a "strict" configuration and you will see staff_r, user_r, and 
sysadm_r, with MLS you will see secadm_r.

> How about:
>
> object_r is a generic role for used most files.

All filesystem objects on persistent storage or network filesystems.

> Under the /proc/ 
> directory, files relating to processes may use the system_r role.

Or the other four roles I listed, and maybe others with customised policy.

Back in 2002 I had machines running with 16 roles and I had the policy working 
well for creating arbitrary roles with minimal effort.

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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: user guide drafts: Maintaining SELinux Labels

[Stephen Smalley]

On Sun, 2008-10-12 at 09:44 +1000, Murray McAllister wrote:
> How about:
> 
> object_r is a generic role for used most files. Under the /proc/ 
> directory, files relating to processes may use the system_r role.

/proc is a pseudo filesystem generated by the kernel and the security
contexts of /proc/pid nodes are identical to the security context of the
associated process.  Thus, any process role can be found in /proc.  But
processes cannot create files there.

> 
> Thanks again for your help.
> > 
> >> Also, when a file is copied over an existing file, the existing file's
> >> context is maintained, unless the user specified cp options to preserve
> >> the context of the original file, such as --preserve=context.
> > 
> > Also the -Z option to cp deserves a mention.
> > 
> >> #Is the following required, or is it covered by the above:
> >>
> >> On systems running the MLS policy, when files and directories are
> >> copied, they inherit the type from the parent directory they are being
> >> copied to, and the level from the process that copied them.
> > 
> > Probably.
> > 
> 
> --
> 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.
-- 
Stephen Smalley
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: user guide drafts: Maintaining SELinux Labels

[Russell Coker]

On Wednesday 15 October 2008 01:18, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> /proc is a pseudo filesystem generated by the kernel and the security
> contexts of /proc/pid nodes are identical to the security context of the
> associated process.  Thus, any process role can be found in /proc.  But
> processes cannot create files there.

Except by calling fork().

Sorry, I felt the need to be pedantic.  ;)

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development


--
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: user guide drafts: Maintaining SELinux Labels

[Stephen Smalley]

On Wed, 2008-10-15 at 05:46 +1000, Russell Coker wrote:
> On Wednesday 15 October 2008 01:18, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > /proc is a pseudo filesystem generated by the kernel and the security
> > contexts of /proc/pid nodes are identical to the security context of the
> > associated process.  Thus, any process role can be found in /proc.  But
> > processes cannot create files there.
> 
> Except by calling fork().
> 
> Sorry, I felt the need to be pedantic.  ;)

Next you'll be arguing that processes can delete files in proc by
calling exit()...

-- 
Stephen Smalley
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: user guide drafts: Maintaining SELinux Labels

[Murray McAllister]

Russell Coker wrote:
> On Saturday 11 October 2008 15:15, Murray McAllister <mmcallis@redhat.com> 
> wrote:
>> When files and directories are copied, the SELinux context of the new
>> file or directory depends on the context of the creating process, and
>> the context of the target, parent directory: the type is inherited from
>> the target, parent directory (unless a type transition rule exists[1]);
>> the SELinux user identity and level are inherited from the creating
>> process; and the role is always object_r, which is a generic role for
>> files. This helps ensure files and directories are labeled with the
>> correct SELinux context after being copied.
> 
> I'm not sure how the last sentence is supposed to link with the rest - it 
> certainly doesn't correspond to the second-last sentence.
> 
> object_r is for future support and also to give a regular format of the 
> context for all operations.  Note that files under /proc that relate to 
> processes have different roles.
> 
>> Also, when a file is copied over an existing file, the existing file's
>> context is maintained, unless the user specified cp options to preserve
>> the context of the original file, such as --preserve=context.
> 
> Also the -Z option to cp deserves a mention.

I started changing the examples to show cp, cp --preserve=context, and 
cp -Z. I had problems with cp -Z on rawhide and fedora 9[1], so I will 
leave that out for now.

Cheers.

[1] <https://bugzilla.redhat.com/show_bug.cgi?id=466653>

--
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: user guide drafts: Maintaining SELinux Labels

[Stephen Smalley]

On Sat, 2008-10-11 at 14:15 +1000, Murray McAllister wrote:
> Thanks. How about:
> 
> When files and directories are copied, the SELinux context of the new 
> file or directory depends on the context of the creating process, and 
> the context of the target, parent directory: the type is inherited from 
> the target, parent directory (unless a type transition rule exists[1]); 
> the SELinux user identity and level are inherited from the creating 
> process; and the role is always object_r, which is a generic role for 
> files. This helps ensure files and directories are labeled with the 
> correct SELinux context after being copied.

It still seems a bit confusing to read.  Part of the issue is that you
are confusing two things above:
- file copying,
- new file creation

The default labeling rules apply whenever a new file is created at
runtime.  File copying is a particular case where a new file is created,
and there are two situations for it:
- (default) New file is created in accordance with the usual default
labeling rules, thereby _not_ necessarily preserving the context of the
original file but rather reflecting the runtime properties of the new
file.  Example:  When a top secret process copies an unclassified file,
the new file is necessarily top secret, not unclassified.
- (when using options to preserve context of the original file) New file
is created with the context of the original file, thereby preserving the
context of the original and _not_ reflecting the runtime properties of
the new file.  The ability to do this is limited by policy and may fail
for a variety of reasons, e.g.:
1) the process may not be authorized to create files with the original
file label (e.g. top secret process may not create unclassified file,
user_t process may not create an etc_t file),
2) the file security context may not be allowed to exist within the
target file system (e.g. top secret file may not be created within a
filesystem capped at secret, passwd_exec_t file may not be created on
removable media).

> Also, when a file is copied over an existing file, the existing file's 
> context is maintained, unless the user specified cp options to preserve 
> the context of the original file, such as --preserve=context.
> 
> #Is the following required, or is it covered by the above:
> 
> On systems running the MLS policy, when files and directories are 
> copied, they inherit the type from the parent directory they are being 
> copied to, and the level from the process that copied them.
> 
> [1] By default, the type is copied from the parent directory. This 
> behavior can be overridden by using type_transition statements in custom 
> SELinux policies. Type transition rules are for a creating process 
> domain, parent directory type, and file object class triple. For 
> example, when a process creates a file in /tmp/, a type transition rule 
> is usually defined so that each domain gets its own private, temporary 
> file type.
> >>  On systems running the MLS policy, when 
> >> files are copied, they inherit the type from the parent directory they 
> >> are being copied to, and the level from the process that copied them.
> >>
> >> Is the last sentence, is "the level from the process that copied them" 
> >> correct? Should it be "from the process or user that..."?
> >>
> >> [1] By default, the type is copied from the parent directory. This 
> >> behavior can be overridden by using type_transition statements in custom 
> >> SELinux policies.
> >>
> >> I've included an example at the end of the section to show copying a 
> >> file over an existing one.
> >>
> >> Thanks for your feedback.
> >>
> >> --
> >> 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.
-- 
Stephen Smalley
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: user guide drafts: Maintaining SELinux Labels

[Murray McAllister]

Stephen Smalley wrote:
> On Sat, 2008-10-11 at 14:15 +1000, Murray McAllister wrote:
>> Thanks. How about:
>>
>> When files and directories are copied, the SELinux context of the new 
>> file or directory depends on the context of the creating process, and 
>> the context of the target, parent directory: the type is inherited from 
>> the target, parent directory (unless a type transition rule exists[1]); 
>> the SELinux user identity and level are inherited from the creating 
>> process; and the role is always object_r, which is a generic role for 
>> files. This helps ensure files and directories are labeled with the 
>> correct SELinux context after being copied.
> 
> It still seems a bit confusing to read.  Part of the issue is that you
> are confusing two things above:
> - file copying,
> - new file creation
> 
> The default labeling rules apply whenever a new file is created at
> runtime.  File copying is a particular case where a new file is created,
> and there are two situations for it:
> - (default) New file is created in accordance with the usual default
> labeling rules, thereby _not_ necessarily preserving the context of the
> original file but rather reflecting the runtime properties of the new
> file.  Example:  When a top secret process copies an unclassified file,
> the new file is necessarily top secret, not unclassified.
> - (when using options to preserve context of the original file) New file
> is created with the context of the original file, thereby preserving the
> context of the original and _not_ reflecting the runtime properties of
> the new file.  The ability to do this is limited by policy and may fail
> for a variety of reasons, e.g.:
> 1) the process may not be authorized to create files with the original
> file label (e.g. top secret process may not create unclassified file,
> user_t process may not create an etc_t file),
> 2) the file security context may not be allowed to exist within the
> target file system (e.g. top secret file may not be created within a
> filesystem capped at secret, passwd_exec_t file may not be created on
> removable media).
Is that because of the file systems on most removable media, or 
something else?

I made an ext3 file system on an USB drive, and "cp --preserve=context 
/usr/bin/passwd /removable/media" preserved the passwd_exect_t type. I 
tested this on Red Hat Enterprise Linux 5.2 and Fedora Rawhide.

I started the section again. Hopefully it is almost right now :(

Copying Files and Directories

When a file or directory is copied, a new file or directory is created 
if it does not exist. That new file or directory's context is based on 
default-labeling rules, not the original file or directory's context 
(unless options were used to preserve the original context). For 
example, files created in user home directories are labeled with the 
user_home_t type:

$ touch file1
$ ls -Z file1
-rw-rw-r--  user1 group1 unconfined_u:object_r:user_home_t:s0 file1

If such a file is copied to another directory, such as /etc/, the new 
file is created in accordance to default-labeling rules for the /etc/ 
directory. Copying a file (without additional options) may not preserve 
the original context:

$ ls -Z file1
-rw-rw-r--  user1 group1 unconfined_u:object_r:user_home_t:s0 file1
# cp file1 /etc/
$ ls -Z /etc/file1
-rw-r--r--  root root unconfined_u:object_r:etc_t:s0   /etc/file1

When file1 is copied to /etc/, if /etc/file1 does not exist, /etc/file1 
is created as a new file. As shown in the example above, /etc/file1 is 
labeled with the etc_t type, in accordance to default-labeling rules.

When a file is copied over an existing file, the existing file's context 
is preserved, unless the user specified cp options to preserve the 
context of the original file, such as --preserve=context. SELinux policy 
may prevent contexts from being preserved during copies.
> 
>> Also, when a file is copied over an existing file, the existing file's 
>> context is maintained, unless the user specified cp options to preserve 
>> the context of the original file, such as --preserve=context.
>>
>> #Is the following required, or is it covered by the above:
>>
>> On systems running the MLS policy, when files and directories are 
>> copied, they inherit the type from the parent directory they are being 
>> copied to, and the level from the process that copied them.
>>
>> [1] By default, the type is copied from the parent directory. This 
>> behavior can be overridden by using type_transition statements in custom 
>> SELinux policies. Type transition rules are for a creating process 
>> domain, parent directory type, and file object class triple. For 
>> example, when a process creates a file in /tmp/, a type transition rule 
>> is usually defined so that each domain gets its own private, temporary 
>> file type.
>>>>  On systems running the MLS policy, when 
>>>> files are copied, they inherit the type from the parent directory they 
>>>> are being copied to, and the level from the process that copied them.
>>>>
>>>> Is the last sentence, is "the level from the process that copied them" 
>>>> correct? Should it be "from the process or user that..."?
>>>>
>>>> [1] By default, the type is copied from the parent directory. This 
>>>> behavior can be overridden by using type_transition statements in custom 
>>>> SELinux policies.
>>>>
>>>> I've included an example at the end of the section to show copying a 
>>>> file over an existing one.
>>>>
>>>> Thanks for your feedback.
>>>>
>>>> --
>>>> 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.


--
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: user guide drafts: Maintaining SELinux Labels

[Stephen Smalley]

On Wed, 2008-10-15 at 11:30 +1000, Murray McAllister wrote:
> Stephen Smalley wrote:
> > 2) the file security context may not be allowed to exist within the
> > target file system (e.g. top secret file may not be created within a
> > filesystem capped at secret, passwd_exec_t file may not be created on
> > removable media).
> Is that because of the file systems on most removable media, or 
> something else?
> 
> I made an ext3 file system on an USB drive, and "cp --preserve=context 
> /usr/bin/passwd /removable/media" preserved the passwd_exect_t type. I 
> tested this on Red Hat Enterprise Linux 5.2 and Fedora Rawhide.

That's because you didn't mount that filesystem with a context= mount
option.  Which hald and friends ought to do for removable media by
default.  There are two situations:
- the filesystem on the removable media may not support extended
attributes at all, or
- the filesystem on the removable media may support them but we may not
want to trust removable media in the same way we apply nosuid nodev
typically when mounting it.

> I started the section again. Hopefully it is almost right now :(
> 
> Copying Files and Directories
> 
> When a file or directory is copied, a new file or directory is created 
> if it does not exist. That new file or directory's context is based on 
> default-labeling rules, not the original file or directory's context 
> (unless options were used to preserve the original context). For 
> example, files created in user home directories are labeled with the 
> user_home_t type:
> 
> $ touch file1
> $ ls -Z file1
> -rw-rw-r--  user1 group1 unconfined_u:object_r:user_home_t:s0 file1
> 
> If such a file is copied to another directory, such as /etc/, the new 
> file is created in accordance to default-labeling rules for the /etc/ 
> directory. Copying a file (without additional options) may not preserve 
> the original context:
> 
> $ ls -Z file1
> -rw-rw-r--  user1 group1 unconfined_u:object_r:user_home_t:s0 file1
> # cp file1 /etc/
> $ ls -Z /etc/file1
> -rw-r--r--  root root unconfined_u:object_r:etc_t:s0   /etc/file1
> 
> When file1 is copied to /etc/, if /etc/file1 does not exist, /etc/file1 
> is created as a new file. As shown in the example above, /etc/file1 is 
> labeled with the etc_t type, in accordance to default-labeling rules.
> 
> When a file is copied over an existing file, the existing file's context 
> is preserved, unless the user specified cp options to preserve the 
> context of the original file, such as --preserve=context. SELinux policy 
> may prevent contexts from being preserved during copies.

Sounds better.

-- 
Stephen Smalley
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: user guide drafts: Maintaining SELinux Labels

[Clarkson, Mike R (US SSA)]

> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov]
On
> Behalf Of Glenn Faden
> Sent: Wednesday, October 08, 2008 8:46 AM
> To: Daniel J Walsh
> Cc: Murray McAllister; SE Linux
> Subject: Re: user guide drafts: Maintaining SELinux Labels
> 
> Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Murray McAllister wrote:
> >
> >> Hi,
> >>
> >> The following are the first few drafts of the "Maintaining SELinux
> >> Labels" sections. Any comments and corrections are appreciated.
> >>
> >> Cheers.
> >>
> >> Copying Files and Directories
> >>
> >> When files and directories are copied, they inherit the SELinux
context
> >> of the parent directory they are copied to. This helps ensure files
and
> >> directories are labeled with the correct SELinux context after
being
> >> moved. The following example demonstrates copying a file from a
user's
> >> home directory to /var/www/html/, which is used by the Apache HTTP
> >> Server. Since the file is copied, it inherits the correct SELinux
> context:
> >>
> Is this true when using MLS policy? Assuming the policy allows a
subject
> to create a file in a directory, shouldn't the newly created file's
> SELinux context have the same sensitivity as the subject who wrote it?

> Or is the new file's type copied from the directory and the
sensitivity
> copied from the subject?

You are correct, the type is copied from the directory and the level is
copied from the subject. It might also be worth mentioning that the type
is copied from the directory as default behavior, which can be
overridden with type_transition statements.

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



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

user guide drafts: Maintaining SELinux Labels

[Murray McAllister]

Hi,

The following are the first few drafts of the "Maintaining SELinux 
Labels" sections. Any comments and corrections are appreciated.

Cheers.

Copying Files and Directories

When files and directories are copied, they inherit the SELinux context 
of the parent directory they are copied to. This helps ensure files and 
directories are labeled with the correct SELinux context after being 
moved. The following example demonstrates copying a file from a user's 
home directory to /var/www/html/, which is used by the Apache HTTP 
Server. Since the file is copied, it inherits the correct SELinux context:

1. Run the cd command without any arguments to change into your home 
directory. Once in your home directory, run the touch file1 command to 
create a file. This file is labeled with the user_home_t type:

$ ls -Z file1
-rw-rw-r--  user1 group1 unconfined_u:object_r:user_home_t:s0 file1

2. Run the ls -dZ /var/www/html/ command to view the SELinux context of 
the /var/www/html/ directory:

$ ls -dZ /var/www/html/
drwxr-xr-x  root root system_u:object_r:httpd_sys_content_t:s0 
/var/www/html/

By default, the /var/www/html/ directory is labeled with the 
httpd_sys_content_t type. Files and directories created under the 
/var/www/html/ directory inherit this type, and as such, they are 
labeled with this type.

3. As the Linux root user, run the cp file1 /var/www/html command to 
copy file1 to the /var/www/html/ directory. Since this file is copied, 
it inherits the httpd_sys_content_t type from the /var/www/html/ directory:

# cp file1 /var/www/html/
# ls -Z /var/www/html/file1
-rw-r--r--  root root unconfined_u:object_r:httpd_sys_content_t:s0 
/var/www/html/file1

<important note>
Copy files and directories, rather than moving them. This helps ensure 
they are labeled with the correct SELinux contexts. Incorrect SELinux 
contexts can prevent processes from accessing such files and directories.
</important note>

Moving Files and Directories

File and directories keep their current SELinux context when they are 
moved. In many cases, this is incorrect for the location they are being 
moved to. The following example demonstrates moving a file from a user's 
home directory to /var/www/html/, which is used by the Apache HTTP 
Server. Since the file is moved, it does not inherit the correct SELinux 
context:

1. Run the cd command without any arguments to change into your home 
directory. Once in your home directory, run the touch file1 command to 
create a file. This file is labeled with the user_home_t type:

$ ls -Z file1
-rw-rw-r--  user1 group1 unconfined_u:object_r:user_home_t:s0 file1

2. Run the ls -dZ /var/www/html/ command to view the SELinux context of 
the /var/www/html/ directory:

$ ls -dZ /var/www/html/
drwxr-xr-x  root root system_u:object_r:httpd_sys_content_t:s0 
/var/www/html/

By default, the /var/www/html/ directory is labeled with the 
httpd_sys_content_t type. Files and directories created under the 
/var/www/html/ directory inherit this type, and as such, they are 
labeled with this type.

3. As the Linux root user, run the mv file1 /var/www/html command to 
move file1 to the /var/www/html directory. Since this file is moved, it 
keeps its current user_home_t type:

# mv file1 /var/www/html
# ls -Z /var/www/html/file1
-rw-rw-r--  user1 group1 unconfined_u:object_r:user_home_t:s0 
/var/www/html/file1

By default, the Apache HTTP Server can not read files that are labeled 
with the user_home_t type. If all files comprising a web page are 
labeled with the user_home_t type, or another type that the Apache HTTP 
Server can not read, permission is denied when attempting to access them 
via Firefox or text-based Web browsers.

<important note>
Moving files and directories with the mv command may result in the wrong 
SELinux context, preventing processes, such as the Apache HTTP Server 
and Samba, from accessing such files and directories.
</important note>

Checking the Default SELinux Context

Use the /usr/sbin/matchpathcon command to check if files and directories 
have the correct SELinux context. From the matchpathcon(8) manual page: 
"matchpathcon queries the system policy and outputs the default security 
context associated with the file path."[1]. The following example 
demonstrates using the /usr/sbin/matchpathcon command to verify that 
files in /var/www/html/ directory are labeled correctly:

1. As the Linux root user, run the touch /var/www/html/file{1,2,3} 
command to create three files (file1, file2, and file3). These files 
inherit the httpd_sys_content_t type from the /var/www/html/ directory:

# touch /var/www/html/file{1,2,3}
# ls -Z /var/www/html/
-rw-r--r--  root root unconfined_u:object_r:httpd_sys_content_t:s0 file1
-rw-r--r--  root root unconfined_u:object_r:httpd_sys_content_t:s0 file2
-rw-r--r--  root root unconfined_u:object_r:httpd_sys_content_t:s0 file3

2. As the Linux root user, run the chcon -t samba_share_t 
/var/www/html/file1 command to change the file1 type to samba_share_t. 
Note: the Apache HTTP Server can not read files or directories labeled 
with the samba_share_t type.

3. The /usr/sbin/matchpathcon -V option compares the current SELinux 
context to the correct, default context in SELinux policy. Run the 
/usr/sbin/matchpathcon -V /var/www/html/* command to check all files in 
the /var/www/html/ directory:

$ /usr/sbin/matchpathcon -V /var/www/html/*
/var/www/html/file1 has context unconfined_u:object_r:samba_share_t:s0, 
should be system_u:object_r:httpd_sys_content_t:s0
/var/www/html/file2 verified.
/var/www/html/file3 verified.

The following output from the /usr/sbin/matchpathcon command explains 
that file1 is labeled with the samba_share_t type, but should be labeled 
with the httpd_sys_content_t type:

/var/www/html/file1 has context unconfined_u:object_r:samba_share_t:s0, 
should be system_u:object_r:httpd_sys_content_t:s0

To resolve the label problem and allow the Apache HTTP Server access to 
file1, as the Linux root user, run the /sbin/restorecon -v 
/var/www/html/file1 command:

# /sbin/restorecon -v /var/www/html/file1
restorecon reset /var/www/html/file1 context 
unconfined_u:object_r:samba_share_t:s0->system_u:object_r:httpd_sys_content_t:s0


[1] The matchpathcon(8) manual page, as shipped with the 
libselinux-utils package in Fedora, is written by Daniel Walsh. Any 
edits or changes in this version were done by Murray McAllister.

--
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: user guide drafts: Maintaining SELinux Labels

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Murray McAllister wrote:
> Hi,
> 
> The following are the first few drafts of the "Maintaining SELinux
> Labels" sections. Any comments and corrections are appreciated.
> 
> Cheers.
> 
> Copying Files and Directories
> 
> When files and directories are copied, they inherit the SELinux context
> of the parent directory they are copied to. This helps ensure files and
> directories are labeled with the correct SELinux context after being
> moved. The following example demonstrates copying a file from a user's
> home directory to /var/www/html/, which is used by the Apache HTTP
> Server. Since the file is copied, it inherits the correct SELinux context:
> 
> 1. Run the cd command without any arguments to change into your home
> directory. Once in your home directory, run the touch file1 command to
> create a file. This file is labeled with the user_home_t type:
> 
> $ ls -Z file1
> -rw-rw-r--  user1 group1 unconfined_u:object_r:user_home_t:s0 file1
> 
> 2. Run the ls -dZ /var/www/html/ command to view the SELinux context of
> the /var/www/html/ directory:
> 
> $ ls -dZ /var/www/html/
> drwxr-xr-x  root root system_u:object_r:httpd_sys_content_t:s0
> /var/www/html/
> 
> By default, the /var/www/html/ directory is labeled with the
> httpd_sys_content_t type. Files and directories created under the
> /var/www/html/ directory inherit this type, and as such, they are
> labeled with this type.
> 
> 3. As the Linux root user, run the cp file1 /var/www/html command to
> copy file1 to the /var/www/html/ directory. Since this file is copied,
> it inherits the httpd_sys_content_t type from the /var/www/html/ directory:
> 
> # cp file1 /var/www/html/
> # ls -Z /var/www/html/file1
> -rw-r--r--  root root unconfined_u:object_r:httpd_sys_content_t:s0
> /var/www/html/file1
> 
> <important note>
> Copy files and directories, rather than moving them. This helps ensure
> they are labeled with the correct SELinux contexts. Incorrect SELinux
> contexts can prevent processes from accessing such files and directories.
> </important note>
> 
Also note that if you copy a file over an existing file the existing
files context will be maintained.

So if I have a file /etc/abc labeled /etc/abc_t and I cp a file /tmp/xyz
labeled /tmp/xyz_t to /etc/abc, it will end up labeled abc_t
> Moving Files and Directories
> 
> File and directories keep their current SELinux context when they are
> moved. In many cases, this is incorrect for the location they are being
> moved to. The following example demonstrates moving a file from a user's
> home directory to /var/www/html/, which is used by the Apache HTTP
> Server. Since the file is moved, it does not inherit the correct SELinux
> context:
> 
> 1. Run the cd command without any arguments to change into your home
> directory. Once in your home directory, run the touch file1 command to
> create a file. This file is labeled with the user_home_t type:
> 
> $ ls -Z file1
> -rw-rw-r--  user1 group1 unconfined_u:object_r:user_home_t:s0 file1
> 
> 2. Run the ls -dZ /var/www/html/ command to view the SELinux context of
> the /var/www/html/ directory:
> 
> $ ls -dZ /var/www/html/
> drwxr-xr-x  root root system_u:object_r:httpd_sys_content_t:s0
> /var/www/html/
> 
> By default, the /var/www/html/ directory is labeled with the
> httpd_sys_content_t type. Files and directories created under the
> /var/www/html/ directory inherit this type, and as such, they are
> labeled with this type.
> 
> 3. As the Linux root user, run the mv file1 /var/www/html command to
> move file1 to the /var/www/html directory. Since this file is moved, it
> keeps its current user_home_t type:
> 
> # mv file1 /var/www/html
> # ls -Z /var/www/html/file1
> -rw-rw-r--  user1 group1 unconfined_u:object_r:user_home_t:s0
> /var/www/html/file1
> 
> By default, the Apache HTTP Server can not read files that are labeled
> with the user_home_t type. If all files comprising a web page are
> labeled with the user_home_t type, or another type that the Apache HTTP
> Server can not read, permission is denied when attempting to access them
> via Firefox or text-based Web browsers.
> 
> <important note>
> Moving files and directories with the mv command may result in the wrong
> SELinux context, preventing processes, such as the Apache HTTP Server
> and Samba, from accessing such files and directories.
> </important note>
> 
> Checking the Default SELinux Context
> 
> Use the /usr/sbin/matchpathcon command to check if files and directories
> have the correct SELinux context. From the matchpathcon(8) manual page:
> "matchpathcon queries the system policy and outputs the default security
> context associated with the file path."[1]. The following example
> demonstrates using the /usr/sbin/matchpathcon command to verify that
> files in /var/www/html/ directory are labeled correctly:
> 
> 1. As the Linux root user, run the touch /var/www/html/file{1,2,3}
> command to create three files (file1, file2, and file3). These files
> inherit the httpd_sys_content_t type from the /var/www/html/ directory:
> 
> # touch /var/www/html/file{1,2,3}
> # ls -Z /var/www/html/
> -rw-r--r--  root root unconfined_u:object_r:httpd_sys_content_t:s0 file1
> -rw-r--r--  root root unconfined_u:object_r:httpd_sys_content_t:s0 file2
> -rw-r--r--  root root unconfined_u:object_r:httpd_sys_content_t:s0 file3
> 
> 2. As the Linux root user, run the chcon -t samba_share_t
> /var/www/html/file1 command to change the file1 type to samba_share_t.
> Note: the Apache HTTP Server can not read files or directories labeled
> with the samba_share_t type.
> 
> 3. The /usr/sbin/matchpathcon -V option compares the current SELinux
> context to the correct, default context in SELinux policy. Run the
> /usr/sbin/matchpathcon -V /var/www/html/* command to check all files in
> the /var/www/html/ directory:
> 
> $ /usr/sbin/matchpathcon -V /var/www/html/*
> /var/www/html/file1 has context unconfined_u:object_r:samba_share_t:s0,
> should be system_u:object_r:httpd_sys_content_t:s0
> /var/www/html/file2 verified.
> /var/www/html/file3 verified.
> 
> The following output from the /usr/sbin/matchpathcon command explains
> that file1 is labeled with the samba_share_t type, but should be labeled
> with the httpd_sys_content_t type:
> 
> /var/www/html/file1 has context unconfined_u:object_r:samba_share_t:s0,
> should be system_u:object_r:httpd_sys_content_t:s0
> 
> To resolve the label problem and allow the Apache HTTP Server access to
> file1, as the Linux root user, run the /sbin/restorecon -v
> /var/www/html/file1 command:
> 
> # /sbin/restorecon -v /var/www/html/file1
> restorecon reset /var/www/html/file1 context
> unconfined_u:object_r:samba_share_t:s0->system_u:object_r:httpd_sys_content_t:s0
> 
> 
> 
> [1] The matchpathcon(8) manual page, as shipped with the
> libselinux-utils package in Fedora, is written by Daniel Walsh. Any
> edits or changes in this version were done by Murray McAllister.
> 
> -- 
> 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.

Everything else looks good.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkjsyaIACgkQrlYvE4MpobMw2gCgpk7w8adyI6rMWDaPXxqyEnM+
rc4AnRmXwiCbP1GV1H1zffCu6g3VjYIc
=oiQh
-----END PGP SIGNATURE-----

--
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: user guide drafts: Maintaining SELinux Labels

[Glenn Faden]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Murray McAllister wrote:
>   
>> Hi,
>>
>> The following are the first few drafts of the "Maintaining SELinux
>> Labels" sections. Any comments and corrections are appreciated.
>>
>> Cheers.
>>
>> Copying Files and Directories
>>
>> When files and directories are copied, they inherit the SELinux context
>> of the parent directory they are copied to. This helps ensure files and
>> directories are labeled with the correct SELinux context after being
>> moved. The following example demonstrates copying a file from a user's
>> home directory to /var/www/html/, which is used by the Apache HTTP
>> Server. Since the file is copied, it inherits the correct SELinux context:
>>     
Is this true when using MLS policy? Assuming the policy allows a subject 
to create a file in a directory, shouldn't the newly created file's 
SELinux context have the same sensitivity as the subject who wrote it? 
Or is the new file's type copied from the directory and the sensitivity 
copied from the subject?

--Glenn

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