user guide drafts: "Mounting File Systems"

user guide drafts: "Mounting File Systems"

[Murray McAllister]

Hi,

The following is a rough draft for the "Mounting File Systems" sections. 
Any comments and corrections are appreciated.

Thanks!

Mounting File Systems

By default, when a third extended file system (ext3) is mounted, the 
files and directories on the file system are labeled with the file_t 
type. The mount command can override SELinux contexts when mounting file 
systems. SELinux context changes with the mount command can be 
per-session only (until the file system is unmounted), or persistent 
(context changes are written to disk).

# what are default_t and file_t?

Temporary Mount Context Changes

As the Linux root user, use the mount -o 
context=SELinux_user:role:type:level option to temporarily override 
existing SELinux contexts. The -o context option requires a Linux 2.6 
kernel. When a file system is mounted with the -o context option:

# does -o context only work with a 2.6 kernels?

* SELinux context changes only occur in kernel memory, and as such, 
context changes are not written to disk. Any context changes made while 
such a file system is mounted are lost when the file system is unmounted.

* If a file system is already labeled, and the contexts are overridden 
with the -o context option, the original contexts return when the file 
system is un-mounted.

* Newly-created files and directories appear to have the SELinux context 
specified with -o context; however, since context changes are not 
written to disk for these situations, context changes are lost when the 
file system is un-mounted.

* The -o context option works even if the file system to be mounted does 
not support extended attributes, although, any context changes made to 
such a file system are lost when the file system is unmounted.

The following example labels all files on the file system to be mounted 
with the httpd_sys_content_t type:

# mount -t ext3 -o context="system_u:object_r:httpd_sys_content_t:s0" 
/dev/sdax /mount/point

-t ext3: The -t ext3 option specifies that an ext3 file system is to be 
mounted. Use the -t option to specify the correct file system. Refer to 
the mount(8) manual page for a list of file systems.

-o context="system_u:object_r:httpd_sys_content_t:s0": The -o 
context="system_u:object_r:httpd_sys_content_t:s0" option specifies the 
SELinux context for all files on the file system to be mounted, as well 
as the mount point. This option overrides existing contexts.

Type Enforcement is the main permission control used in SELinux targeted 
policy. For the most part, SELinux users and roles can be ignored, so, 
when overriding the SELinux context with mount, use the SELinux system_u 
user and object_r role, and concentrate on the type. In this example, 
all files on the /dev/sdax file system will be labeled with the 
httpd_sys_content_t type.

/dev/sdax /mount/point: Specifies that the /dev/sdax device will be 
mounted to the /mount/point/ directory.

<note>
When a file system is mounted with the -o context option, it is not 
possible to use the chcon command to change the SELinux context. Using 
chcon on such a file system results in a Operation not supported error.
</note>

Persistent Mount Context Changes

As the Linux root user, use the mount -o 
defcontext=SELinux_user:role:type:level option to persistently change 
the default SELinux context for a file system. The -o defcontext option 
requires a file system that supports extended attributes, since changes 
are written to disk. When a file system is mounted with the -o 
defcontext option:

* Existing files keep their current contexts.

* Context changes are written to disk, and are not lost if the file 
system is unmounted. Newly-created files and files copied to such a file 
system inherit the SELinux context specified with the -o defcontext 
option. For example, if a file system is mounted with the -o 
defcontext="system_u:object_r:httpd_sys_content_t:s0" option, and a new 
file is created on the mounted file system, that file is labeled with 
the httpd_sys_content_t type. If the file system is unmounted and then 
mounted without a context option, that file is still labeled with the 
httpd_sys_content_t type.

The following example changes the default SELinux context for the file 
system to be mounted to system_u:object_r:httpd_sys_content_t:s0:

# mount -t ext3 -o defcontext="system_u:object_r:httpd_sys_content_t:s0" 
/dev/sdax /mount/point

[fill in similar to the previous section]

# I do not understand the fscontext option. Should that be included?

# Is there any common use cases that should have examples here, such as 
mounting a cd and sharing it via http or nfs?

Apologies for any typos :(

--
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: "Mounting File Systems"

[Murray McAllister]

Murray McAllister wrote:
> Hi,
> 
> The following is a rough draft for the "Mounting File Systems" sections. 
> Any comments and corrections are appreciated.
> 
> Thanks!
> 
> Mounting File Systems
> 
> By default, when a third extended file system (ext3) is mounted, the 
> files and directories on the file system are labeled with the file_t 
> type. The mount command can override SELinux contexts when mounting file 
> systems. SELinux context changes with the mount command can be 
> per-session only (until the file system is unmounted), or persistent 
> (context changes are written to disk).
> 
> # what are default_t and file_t?
Sorry. I found 
<http://fedoraproject.org/wiki/SELinux/Troubleshooting/AVCDecisions> 
which looks like it answers it.
> 
> Temporary Mount Context Changes
> 
> As the Linux root user, use the mount -o 
> context=SELinux_user:role:type:level option to temporarily override 
> existing SELinux contexts. The -o context option requires a Linux 2.6 
> kernel. When a file system is mounted with the -o context option:
> 
> # does -o context only work with a 2.6 kernels?
> 
> * SELinux context changes only occur in kernel memory, and as such, 
> context changes are not written to disk. Any context changes made while 
> such a file system is mounted are lost when the file system is unmounted.
> 
> * If a file system is already labeled, and the contexts are overridden 
> with the -o context option, the original contexts return when the file 
> system is un-mounted.
> 
> * Newly-created files and directories appear to have the SELinux context 
> specified with -o context; however, since context changes are not 
> written to disk for these situations, context changes are lost when the 
> file system is un-mounted.
> 
> * The -o context option works even if the file system to be mounted does 
> not support extended attributes, although, any context changes made to 
> such a file system are lost when the file system is unmounted.
> 
> The following example labels all files on the file system to be mounted 
> with the httpd_sys_content_t type:
> 
> # mount -t ext3 -o context="system_u:object_r:httpd_sys_content_t:s0" 
> /dev/sdax /mount/point
> 
> -t ext3: The -t ext3 option specifies that an ext3 file system is to be 
> mounted. Use the -t option to specify the correct file system. Refer to 
> the mount(8) manual page for a list of file systems.
> 
> -o context="system_u:object_r:httpd_sys_content_t:s0": The -o 
> context="system_u:object_r:httpd_sys_content_t:s0" option specifies the 
> SELinux context for all files on the file system to be mounted, as well 
> as the mount point. This option overrides existing contexts.
> 
> Type Enforcement is the main permission control used in SELinux targeted 
> policy. For the most part, SELinux users and roles can be ignored, so, 
> when overriding the SELinux context with mount, use the SELinux system_u 
> user and object_r role, and concentrate on the type. In this example, 
> all files on the /dev/sdax file system will be labeled with the 
> httpd_sys_content_t type.
> 
> /dev/sdax /mount/point: Specifies that the /dev/sdax device will be 
> mounted to the /mount/point/ directory.
> 
> <note>
> When a file system is mounted with the -o context option, it is not 
> possible to use the chcon command to change the SELinux context. Using 
> chcon on such a file system results in a Operation not supported error.
> </note>
> 
> Persistent Mount Context Changes
> 
> As the Linux root user, use the mount -o 
> defcontext=SELinux_user:role:type:level option to persistently change 
> the default SELinux context for a file system. The -o defcontext option 
> requires a file system that supports extended attributes, since changes 
> are written to disk. When a file system is mounted with the -o 
> defcontext option:
> 
> * Existing files keep their current contexts.
> 
> * Context changes are written to disk, and are not lost if the file 
> system is unmounted. Newly-created files and files copied to such a file 
> system inherit the SELinux context specified with the -o defcontext 
> option. For example, if a file system is mounted with the -o 
> defcontext="system_u:object_r:httpd_sys_content_t:s0" option, and a new 
> file is created on the mounted file system, that file is labeled with 
> the httpd_sys_content_t type. If the file system is unmounted and then 
> mounted without a context option, that file is still labeled with the 
> httpd_sys_content_t type.
> 
> The following example changes the default SELinux context for the file 
> system to be mounted to system_u:object_r:httpd_sys_content_t:s0:
> 
> # mount -t ext3 -o defcontext="system_u:object_r:httpd_sys_content_t:s0" 
> /dev/sdax /mount/point
> 
> [fill in similar to the previous section]
> 
> # I do not understand the fscontext option. Should that be included?
> 
> # Is there any common use cases that should have examples here, such as 
> mounting a cd and sharing it via http or nfs?
> 
> Apologies for any typos :(
> 


--
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: "Mounting File Systems"

[Murray McAllister]

Murray McAllister wrote:
> Murray McAllister wrote:
>> Hi,
>>
>> The following is a rough draft for the "Mounting File Systems" 
>> sections. Any comments and corrections are appreciated.
>>
>> Thanks!
>>
>> Mounting File Systems
>>
>> By default, when a third extended file system (ext3) is mounted, the 
>> files and directories on the file system are labeled with the file_t 
>> type. The mount command can override SELinux contexts when mounting 
>> file systems. SELinux context changes with the mount command can be 
>> per-session only (until the file system is unmounted), or persistent 
>> (context changes are written to disk).

Sorry for all the spam. Should I add a note that this only applies if 
mounted to a newly-created directory under / ?

Thanks.

--
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: "Mounting File Systems"

[Russell Coker]

On Friday 10 October 2008 18:26, Murray McAllister <mmcallis@redhat.com> 
wrote:
> As the Linux root user, use the mount -o
> context=SELinux_user:role:type:level option to temporarily override
> existing SELinux contexts. The -o context option requires a Linux 2.6
> kernel. When a file system is mounted with the -o context option:
>
> # does -o context only work with a 2.6 kernels?

Given that Red Hat never supported SE Linux on a kernel before 2.6, and that 
any form of SE Linux support before 2.6 is prehistoric and no-one can really 
remember it, what is the point of mentioning pre 2.6 stuff?

Mentioning things that are different between RHEL4 and RHEL5 makes sense, as 
does differences with other distributions, and differences in the last few 
Fedora releases.

I don't recall when -o context appeared (ask google).  I do recall that it 
came in stages.  Do a test, you might find that RHEL4 works differently to 
RHEL5.  Incidentally if you don't already have one, I suggest that you get a 
Xen machine with instances for RHEL4, RHEL5, and the last few Fedoras - 
you'll need it to test such things.

> * SELinux context changes only occur in kernel memory, and as such,
> context changes are not written to disk. Any context changes made while
> such a file system is mounted are lost when the file system is unmounted.

What do you mean?

In a test with CentOS 5.2 I was unable to change the context of a file:

# mount /var/lib/xen/save -ocontext=system_u:object_r:mnt_t:s0
# chcon -t root_t /var/lib/xen/save
chcon: failed to change context of /var/lib/xen/save to 
system_u:object_r:root_t: Operation not supported

This is similar to what you wrote below in the <note> section.

> * If a file system is already labeled, and the contexts are overridden
> with the -o context option, the original contexts return when the file
> system is un-mounted.

Or if the filesystem isn't labelled then it remains in that state.

> * Newly-created files and directories appear to have the SELinux context
> specified with -o context; however, since context changes are not
> written to disk for these situations, context changes are lost when the
> file system is un-mounted.
>
> * The -o context option works even if the file system to be mounted does
> not support extended attributes, although, any context changes made to
> such a file system are lost when the file system is unmounted.
>
> The following example labels all files on the file system to be mounted
> with the httpd_sys_content_t type:
>
> # mount -t ext3 -o context="system_u:object_r:httpd_sys_content_t:s0"
> /dev/sdax /mount/point
>
> -t ext3: The -t ext3 option specifies that an ext3 file system is to be
> mounted. Use the -t option to specify the correct file system. Refer to
> the mount(8) manual page for a list of file systems.

Generally mount can figure that out by itself.

> -o context="system_u:object_r:httpd_sys_content_t:s0": The -o
> context="system_u:object_r:httpd_sys_content_t:s0" option specifies the
> SELinux context for all files on the file system to be mounted, as well
> as the mount point. This option overrides existing contexts.
>
> Type Enforcement is the main permission control used in SELinux targeted
> policy. For the most part, SELinux users and roles can be ignored, so,
> when overriding the SELinux context with mount, use the SELinux system_u
> user and object_r role, and concentrate on the type. In this example,
> all files on the /dev/sdax file system will be labeled with the
> httpd_sys_content_t type.

At this time object_r is the only supported role for files.  That may change 
in the near future.

> <note>
> When a file system is mounted with the -o context option, it is not
> possible to use the chcon command to change the SELinux context. Using
> chcon on such a file system results in a Operation not supported error.
> </note>

-- 
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: "Mounting File Systems"

[Stephen Smalley]

On Fri, 2008-10-10 at 17:26 +1000, Murray McAllister wrote:
> Hi,
> 
> The following is a rough draft for the "Mounting File Systems" sections. 
> Any comments and corrections are appreciated.
> 
> Thanks!
> 
> Mounting File Systems
> 
> By default, when a third extended file system (ext3) is mounted, the 

You should generalize this to "a filesystem that supports extended
attributes, such as ext[234], jfs, xfs, or jffs2".

> files and directories on the file system are labeled with the file_t 
> type.

Not exactly.  The correct statement is that a file that does not have a
security context set on disk (due to being created on a non-selinux
kernel) on a filesystem that supports extended attributes will be
treated as having the file_t type (or more precisely, the security
context associated with the file initial SID).  On a properly labeled
filesystem, there should be no files with file_t.

>  The mount command can override SELinux contexts when mounting file 
> systems. SELinux context changes with the mount command can be 
> per-session only (until the file system is unmounted), or persistent 
> (context changes are written to disk).

This doesn't sound right either.  The context= mount option can be used
to treat all files on a given filesystem as having the specified
security context.  That context is never stored in the filesystem
itself, although obviously you can put context= mount options into your
fstab in order to make them happen whenever the filesystem is mounted.
The purpose of the context= mount option is twofold:
- to support coarse-grained labeling of filesystems that do not support
extended attributes, and
- to support overriding/ignoring the extended attributes on a filesystem
when you do not want to trust it to supply them (similar to the nosuid
option, useful for e.g. removable media).

> # what are default_t and file_t?

default_t is a type specified in file_contexts as the default type for
any file that does not match any other pattern in the file_contexts
configuration.  So for example if you have a /foobar on your disk, it
will likely end up getting labeled with default_t.  default_t files may
exist on a properly labeled filesystem but should generally be
inaccessible to confined domains - they indicate that you need to update
your file_contexts configuration to include patterns for that part of
the file tree.

file_t is the type used in the context associated with the initial file
SID that gets assigned to files by the kernel when there is no extended
attribute for the security context on the file yet the filesystem type
supports such attributes.  file_t files should not exist on a properly
labeled filesystem; they indicate that files were created while running
a non-selinux kernel.

> Temporary Mount Context Changes
> 
> As the Linux root user, use the mount -o 
> context=SELinux_user:role:type:level option to temporarily override 
> existing SELinux contexts. The -o context option requires a Linux 2.6 
> kernel. When a file system is mounted with the -o context option:
> 
> # does -o context only work with a 2.6 kernels?
> 
> * SELinux context changes only occur in kernel memory, and as such, 
> context changes are not written to disk. Any context changes made while 
> such a file system is mounted are lost when the file system is unmounted.

There shouldn't be any context changes when you use a context mount; it
prohibits setting of the context by applications.

> * If a file system is already labeled, and the contexts are overridden 
> with the -o context option, the original contexts return when the file 
> system is un-mounted.

The extended attributes are not modified, but they will only be visible
if you mount without the context option.

> Persistent Mount Context Changes
> 
> As the Linux root user, use the mount -o 
> defcontext=SELinux_user:role:type:level option to persistently change 
> the default SELinux context for a file system.

No.  This just changes the default context used by the kernel for files
that lack an extended attribute on disk, from the context associated
with the initial file SID to the specified context.  IOW, this just
changes from using file_t to using some other label.

>  The -o defcontext option 
> requires a file system that supports extended attributes, since changes 
> are written to disk. When a file system is mounted with the -o 
> defcontext option:
> 
> * Existing files keep their current contexts.
> 
> * Context changes are written to disk, and are not lost if the file 
> system is unmounted. Newly-created files and files copied to such a file 
> system inherit the SELinux context specified with the -o defcontext 
> option. For example, if a file system is mounted with the -o 
> defcontext="system_u:object_r:httpd_sys_content_t:s0" option, and a new 
> file is created on the mounted file system, that file is labeled with 
> the httpd_sys_content_t type. If the file system is unmounted and then 
> mounted without a context option, that file is still labeled with the 
> httpd_sys_content_t type.
> 
> The following example changes the default SELinux context for the file 
> system to be mounted to system_u:object_r:httpd_sys_content_t:s0:
> 
> # mount -t ext3 -o defcontext="system_u:object_r:httpd_sys_content_t:s0" 
> /dev/sdax /mount/point
> 
> [fill in similar to the previous section]
> 
> # I do not understand the fscontext option. Should that be included?

I'm pretty sure that James and/or Eric have written description of all
of the context mount options before.
fscontext= sets the filesystem security context, a context that is
applied for certain permission checks on the entire filesystem like
mounting as well as used to control what file security contexts can
exist within the filesystem.

rootcontext= sets the security context for the root directory of the
filesystem, useful for e.g. tmpfs mounts where you want the root to take
on a specific context but allow other files within it to have individual
contexts.

> # Is there any common use cases that should have examples here, such as 
> mounting a cd and sharing it via http or nfs?

-- 
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: "Mounting File Systems"

[Stephen Smalley]

On Fri, 2008-10-10 at 17:26 +1000, Murray McAllister wrote:
> Hi,
> 
> The following is a rough draft for the "Mounting File Systems" sections. 
> Any comments and corrections are appreciated.

I'd have to say that this entire section is confusing - it is written in
terms of low level mechanism and corner cases and not in terms of how
users actually interact with SELinux and their common experience.

For example, file_t is something users should never see in practice.  As
setroubleshoot says, it indicates that they should relabel their
filesystems - they likely have been running with SELinux disabled at
some prior point in time and have re-enabled it without relabeling.

Likewise, default_t is the unusual case where a file falls completely
outside of the file tree specifications in file_contexts.

It also doesn't describe context mounts in terms of why and how they are
used.  See for example the original explanation of mountpoint labeling
(i.e. context mounts) in:
http://www.linuxjournal.com/article/7426

> Thanks!
> 
> Mounting File Systems
> 
> By default, when a third extended file system (ext3) is mounted, the 
> files and directories on the file system are labeled with the file_t 
> type. The mount command can override SELinux contexts when mounting file 
> systems. SELinux context changes with the mount command can be 
> per-session only (until the file system is unmounted), or persistent 
> (context changes are written to disk).
> 
> # what are default_t and file_t?
> 
> Temporary Mount Context Changes
> 
> As the Linux root user, use the mount -o 
> context=SELinux_user:role:type:level option to temporarily override 
> existing SELinux contexts. The -o context option requires a Linux 2.6 
> kernel. When a file system is mounted with the -o context option:
> 
> # does -o context only work with a 2.6 kernels?
> 
> * SELinux context changes only occur in kernel memory, and as such, 
> context changes are not written to disk. Any context changes made while 
> such a file system is mounted are lost when the file system is unmounted.
> 
> * If a file system is already labeled, and the contexts are overridden 
> with the -o context option, the original contexts return when the file 
> system is un-mounted.
> 
> * Newly-created files and directories appear to have the SELinux context 
> specified with -o context; however, since context changes are not 
> written to disk for these situations, context changes are lost when the 
> file system is un-mounted.
> 
> * The -o context option works even if the file system to be mounted does 
> not support extended attributes, although, any context changes made to 
> such a file system are lost when the file system is unmounted.
> 
> The following example labels all files on the file system to be mounted 
> with the httpd_sys_content_t type:
> 
> # mount -t ext3 -o context="system_u:object_r:httpd_sys_content_t:s0" 
> /dev/sdax /mount/point
> 
> -t ext3: The -t ext3 option specifies that an ext3 file system is to be 
> mounted. Use the -t option to specify the correct file system. Refer to 
> the mount(8) manual page for a list of file systems.
> 
> -o context="system_u:object_r:httpd_sys_content_t:s0": The -o 
> context="system_u:object_r:httpd_sys_content_t:s0" option specifies the 
> SELinux context for all files on the file system to be mounted, as well 
> as the mount point. This option overrides existing contexts.
> 
> Type Enforcement is the main permission control used in SELinux targeted 
> policy. For the most part, SELinux users and roles can be ignored, so, 
> when overriding the SELinux context with mount, use the SELinux system_u 
> user and object_r role, and concentrate on the type. In this example, 
> all files on the /dev/sdax file system will be labeled with the 
> httpd_sys_content_t type.
> 
> /dev/sdax /mount/point: Specifies that the /dev/sdax device will be 
> mounted to the /mount/point/ directory.
> 
> <note>
> When a file system is mounted with the -o context option, it is not 
> possible to use the chcon command to change the SELinux context. Using 
> chcon on such a file system results in a Operation not supported error.
> </note>
> 
> Persistent Mount Context Changes
> 
> As the Linux root user, use the mount -o 
> defcontext=SELinux_user:role:type:level option to persistently change 
> the default SELinux context for a file system. The -o defcontext option 
> requires a file system that supports extended attributes, since changes 
> are written to disk. When a file system is mounted with the -o 
> defcontext option:
> 
> * Existing files keep their current contexts.
> 
> * Context changes are written to disk, and are not lost if the file 
> system is unmounted. Newly-created files and files copied to such a file 
> system inherit the SELinux context specified with the -o defcontext 
> option. For example, if a file system is mounted with the -o 
> defcontext="system_u:object_r:httpd_sys_content_t:s0" option, and a new 
> file is created on the mounted file system, that file is labeled with 
> the httpd_sys_content_t type. If the file system is unmounted and then 
> mounted without a context option, that file is still labeled with the 
> httpd_sys_content_t type.
> 
> The following example changes the default SELinux context for the file 
> system to be mounted to system_u:object_r:httpd_sys_content_t:s0:
> 
> # mount -t ext3 -o defcontext="system_u:object_r:httpd_sys_content_t:s0" 
> /dev/sdax /mount/point
> 
> [fill in similar to the previous section]
> 
> # I do not understand the fscontext option. Should that be included?
> 
> # Is there any common use cases that should have examples here, such as 
> mounting a cd and sharing it via http or nfs?
> 
> Apologies for any typos :(
> 
> --
> 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: "Mounting File Systems"

[Eric Paris]

On Fri, 2008-10-10 at 09:11 -0400, Stephen Smalley wrote:
> On Fri, 2008-10-10 at 17:26 +1000, Murray McAllister wrote:
> > Hi,
> > 
> > The following is a rough draft for the "Mounting File Systems" sections. 
> > Any comments and corrections are appreciated.
> > 
> > Thanks!
> > 
> > Mounting File Systems
> > 
> > By default, when a third extended file system (ext3) is mounted, the 
> 
> You should generalize this to "a filesystem that supports extended
> attributes, such as ext[234], jfs, xfs, or jffs2".
> 
> > files and directories on the file system are labeled with the file_t 
> > type.
> 
> Not exactly.  The correct statement is that a file that does not have a
> security context set on disk (due to being created on a non-selinux
> kernel) on a filesystem that supports extended attributes will be
> treated as having the file_t type (or more precisely, the security
> context associated with the file initial SID).  On a properly labeled
> filesystem, there should be no files with file_t.

might be worth mentioning that the context assigned to unlabeled files
on filesystems that supports xattrs can be set with defcontext=.   opps,
I see you did that later on, only as sds pointed out you didn't get it
quite right.

<aside> Dan, you always said you disliked how file_t meant there was no
label and unlabeled_t meant there was a bad label.  Maybe we could move
to using defcontext= to assign a type you like for at least the file_t
case... </aside>

> > * Context changes are written to disk, and are not lost if the file 
> > system is unmounted. Newly-created files and files copied to such a file 
> > system inherit the SELinux context specified with the -o defcontext 
> > option. For example, if a file system is mounted with the -o 
> > defcontext="system_u:object_r:httpd_sys_content_t:s0" option, and a new 
> > file is created on the mounted file system, that file is labeled with 
> > the httpd_sys_content_t type. If the file system is unmounted and then 
> > mounted without a context option, that file is still labeled with the 
> > httpd_sys_content_t type.

I didn't know this (am I supposed to admit that?)  I always thought
normal label inheritance still took place even with defcontext=.
Anyway, if you can double check that would be great...

mount -o httpd_sys_context_t
mkdir testdir/
chcon tmp_t testdir/
touch testdir/file
ls -lZ testdir/

if file is httpd_sys_context_t you are right.  if file is tmp_t normal
inheritance took place....

> I'm pretty sure that James and/or Eric have written description of all
> of the context mount options before.
> fscontext= sets the filesystem security context, a context that is
> applied for certain permission checks on the entire filesystem like
> mounting as well as used to control what file security contexts can
> exist within the filesystem.

Its not relevant to 99% of people at this time (same for defcontext and
rootcontext), but that might change if we start making better policies
to protect against accidental information leakage. All three should get
a short blurb, context= needs the most description.  The most
interesting use of fscontext is the 'associate' permission check.  It
allows you to say that things labeled company_confidential_t are not
allowed to be saved on a filesystem with fscontext=removable_media_t.
We don't make much (any?) use of this feature, but fscontext is a very
general label controlling the entire fs, can it be mounted, can certain
data be written to it, etc, etc...

> rootcontext= sets the security context for the root directory of the
> filesystem, useful for e.g. tmpfs mounts where you want the root to take
> on a specific context but allow other files within it to have individual
> contexts.

again, not brilliantly interesting for most people as usually dan just
fixes it with a restorecon somewhere in the init scripts for most
people.  I find it most useful when mounting tmpfs somewhere.  Say you
want to make /usr/src/redhat/BUILD a tmpfs.  Easiest way to make sure
you don't see any denials or need extra magic would be to include a
rootcontext=src_t in the fstab...

> 
> > # Is there any common use cases that should have examples here, such as 
> > mounting a cd and sharing it via http or nfs?

exporting a FAT fs using http is common enough and uses context=

a discussion of multiple nfs mounts using context= could be useful.  If
you don't know why it would be usefull context me off list and I'll
explain all the nfs mount magic   :)

-Eric


--
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: "Mounting File Systems"

[Stephen Smalley]

On Fri, 2008-10-10 at 09:45 -0400, Eric Paris wrote:
> On Fri, 2008-10-10 at 09:11 -0400, Stephen Smalley wrote:
> > On Fri, 2008-10-10 at 17:26 +1000, Murray McAllister wrote:
> > > Hi,
> > > 
> > > The following is a rough draft for the "Mounting File Systems" sections. 
> > > Any comments and corrections are appreciated.
> > > 
> > > Thanks!
> > > 
> > > Mounting File Systems
> > > 
> > > By default, when a third extended file system (ext3) is mounted, the 
> > 
> > You should generalize this to "a filesystem that supports extended
> > attributes, such as ext[234], jfs, xfs, or jffs2".
> > 
> > > files and directories on the file system are labeled with the file_t 
> > > type.
> > 
> > Not exactly.  The correct statement is that a file that does not have a
> > security context set on disk (due to being created on a non-selinux
> > kernel) on a filesystem that supports extended attributes will be
> > treated as having the file_t type (or more precisely, the security
> > context associated with the file initial SID).  On a properly labeled
> > filesystem, there should be no files with file_t.
> 
> might be worth mentioning that the context assigned to unlabeled files
> on filesystems that supports xattrs can be set with defcontext=.   opps,
> I see you did that later on, only as sds pointed out you didn't get it
> quite right.
> 
> <aside> Dan, you always said you disliked how file_t meant there was no
> label and unlabeled_t meant there was a bad label.  Maybe we could move
> to using defcontext= to assign a type you like for at least the file_t
> case... </aside>
> 
> > > * Context changes are written to disk, and are not lost if the file 
> > > system is unmounted. Newly-created files and files copied to such a file 
> > > system inherit the SELinux context specified with the -o defcontext 
> > > option. For example, if a file system is mounted with the -o 
> > > defcontext="system_u:object_r:httpd_sys_content_t:s0" option, and a new 
> > > file is created on the mounted file system, that file is labeled with 
> > > the httpd_sys_content_t type. If the file system is unmounted and then 
> > > mounted without a context option, that file is still labeled with the 
> > > httpd_sys_content_t type.
> 
> I didn't know this (am I supposed to admit that?)  I always thought
> normal label inheritance still took place even with defcontext=.
> Anyway, if you can double check that would be great...
> 
> mount -o httpd_sys_context_t
> mkdir testdir/
> chcon tmp_t testdir/
> touch testdir/file
> ls -lZ testdir/
> 
> if file is httpd_sys_context_t you are right.  if file is tmp_t normal
> inheritance took place....
> 
> > I'm pretty sure that James and/or Eric have written description of all
> > of the context mount options before.
> > fscontext= sets the filesystem security context, a context that is
> > applied for certain permission checks on the entire filesystem like
> > mounting as well as used to control what file security contexts can
> > exist within the filesystem.
> 
> Its not relevant to 99% of people at this time (same for defcontext and
> rootcontext), but that might change if we start making better policies
> to protect against accidental information leakage. All three should get
> a short blurb, context= needs the most description.  The most
> interesting use of fscontext is the 'associate' permission check.  It
> allows you to say that things labeled company_confidential_t are not
> allowed to be saved on a filesystem with fscontext=removable_media_t.
> We don't make much (any?) use of this feature, but fscontext is a very
> general label controlling the entire fs, can it be mounted, can certain
> data be written to it, etc, etc...
> 
> > rootcontext= sets the security context for the root directory of the
> > filesystem, useful for e.g. tmpfs mounts where you want the root to take
> > on a specific context but allow other files within it to have individual
> > contexts.
> 
> again, not brilliantly interesting for most people as usually dan just
> fixes it with a restorecon somewhere in the init scripts for most
> people.  I find it most useful when mounting tmpfs somewhere.  Say you
> want to make /usr/src/redhat/BUILD a tmpfs.  Easiest way to make sure
> you don't see any denials or need extra magic would be to include a
> rootcontext=src_t in the fstab...

BTW, one interesting tidbit from OpenSolaris FMAC - in Solaris, the
uid/gid/mode information for the root directory of a tmpfs mount
defaults to the attributes of the underlying mount point directory, so I
did likewise for the security context.  Which means that I can set the
security context on the mount point directory as desired (tmp_t
for /tmp, var_run_t for /var/run, ...) and then the tmpfs mount will
pick up the right label automatically from the mount point.  I don't
know if that makes sense in Linux, as they infer the default uid/gid
from the mounting process instead.

-- 
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: "Mounting File Systems"

[Russell Coker]

On Saturday 11 October 2008 00:51, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> BTW, one interesting tidbit from OpenSolaris FMAC - in Solaris, the
> uid/gid/mode information for the root directory of a tmpfs mount
> defaults to the attributes of the underlying mount point directory, so I
> did likewise for the security context.  Which means that I can set the
> security context on the mount point directory as desired (tmp_t
> for /tmp, var_run_t for /var/run, ...) and then the tmpfs mount will
> pick up the right label automatically from the mount point.  I don't
> know if that makes sense in Linux, as they infer the default uid/gid
> from the mounting process instead.

If we are considering that then maybe we also should consider the reverse.  
Having a chcon on the root of a tmpfs filesystem change the mount point.

-- 
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: "Mounting File Systems"

[Murray McAllister]

Eric Paris wrote:
> On Fri, 2008-10-10 at 09:11 -0400, Stephen Smalley wrote:
>> On Fri, 2008-10-10 at 17:26 +1000, Murray McAllister wrote:

>>> * Context changes are written to disk, and are not lost if the file 
>>> system is unmounted. Newly-created files and files copied to such a file 
>>> system inherit the SELinux context specified with the -o defcontext 
>>> option. For example, if a file system is mounted with the -o 
>>> defcontext="system_u:object_r:httpd_sys_content_t:s0" option, and a new 
>>> file is created on the mounted file system, that file is labeled with 
>>> the httpd_sys_content_t type. If the file system is unmounted and then 
>>> mounted without a context option, that file is still labeled with the 
>>> httpd_sys_content_t type.
> 
> I didn't know this 
You're not supposed to. It is wrong. Don't believe what I say :)

(am I supposed to admit that?)  I always thought
> normal label inheritance still took place even with defcontext=.
> Anyway, if you can double check that would be great...
> 
> mount -o httpd_sys_context_t
> mkdir testdir/
> chcon tmp_t testdir/
> touch testdir/file
> ls -lZ testdir/
> 
> if file is httpd_sys_context_t you are right.  if file is tmp_t normal
> inheritance took place....
Inheritance took place. I don't remember what I did last time to think 
otherwise.
> 
> Its not relevant to 99% of people at this time (same for defcontext and
> rootcontext), but that might change if we start making better policies
> to protect against accidental information leakage. All three should get
> a short blurb, context= needs the most description.  The most
> interesting use of fscontext is the 'associate' permission check.  It
> allows you to say that things labeled company_confidential_t are not
> allowed to be saved on a filesystem with fscontext=removable_media_t.
> We don't make much (any?) use of this feature, but fscontext is a very
> general label controlling the entire fs, can it be mounted, can certain
> data be written to it, etc, etc...
I have examples (will post soon) for mounting fat so that it can be 
shared via http, and a single nfs export mounted multiple times with 
different contexts. Please let me know if you want anything else.

Cheers.
> 
>>> # Is there any common use cases that should have examples here, such as 
>>> mounting a cd and sharing it via http or nfs?
> 
> exporting a FAT fs using http is common enough and uses context=
> 
> a discussion of multiple nfs mounts using context= could be useful.  If
> you don't know why it would be usefull context me off list and I'll
> explain all the nfs mount magic   :)
> 
> -Eric
> 

--
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: "Mounting File Systems"

[Murray McAllister]

Stephen Smalley wrote:
> On Fri, 2008-10-10 at 17:26 +1000, Murray McAllister wrote:
>> Hi,
>>
>> The following is a rough draft for the "Mounting File Systems" sections. 
>> Any comments and corrections are appreciated.
> 
> I'd have to say that this entire section is confusing - it is written in
> terms of low level mechanism and corner cases and not in terms of how
> users actually interact with SELinux and their common experience.
> 
> For example, file_t is something users should never see in practice.  As
> setroubleshoot says, it indicates that they should relabel their
> filesystems - they likely have been running with SELinux disabled at
> some prior point in time and have re-enabled it without relabeling.
> 
> Likewise, default_t is the unusual case where a file falls completely
> outside of the file tree specifications in file_contexts.
> 
> It also doesn't describe context mounts in terms of why and how they are
> used.  See for example the original explanation of mountpoint labeling
> (i.e. context mounts) in:
> http://www.linuxjournal.com/article/7426
I have tried to remove the more technical details and include feedback:

Mounting File Systems

Use the mount -o context command to override existing extended 
attributes. This is useful if you do not trust a file system to supply 
the correct attributes, for example, removable media used in multiple 
systems. The mount -o context command can also be used to support 
labeling for file systems that do not support extended attributes, such 
as File Allocation Table (FAT) file systems. The context specified with 
mount -o context is not written to disk: the original contexts are 
preserved, and are seen when mounting without a context option.

Temporary Mount Context Changes

As the Linux root user, use the mount -o 
context=SELinux_user:role:type:level command to mount file systems with 
the specified context, overriding existing contexts if they exist. 
Context changes are not written to disk. In the following example, when 
/dev/sda1 is mounted, all files on that file system are labeled with the 
system_u:object_r:httpd_sys_content_t:s0 context. This example can be 
used to share FAT file systems (or other file systems) via the Apache 
HTTP server:

# mount -o context="system_u:object_r:httpd_sys_content_t:s0" /dev/sda1 
/mount/point

Newly-created files and directories on this file system appear to have 
the SELinux context specified with -o context; however, since context 
changes are not written to disk for these situations, context changes 
are lost when the file system is unmounted. If such a file system is not 
labeled, or does support extended attributes, it stays in that state 
after being unmounted.

Type Enforcement is the main permission control used in SELinux targeted 
policy. For the most part, SELinux users and roles can be ignored, so, 
when overriding the SELinux context with -o context, use the SELinux 
system_u user and object_r role, and concentrate on the type. If you are 
not using the MLS policy or multi-category security, use the s0 level.

<note>
When a file system is mounted with a context option, context changes (by 
users and processes) are prohibited. For example, running chcon on a 
file system mounted with a context option results in a Operation not 
supported error.
</note>

Changing the Default Context

As the Linux root user, use the mount -o 
defcontext=SELinux_user:role:type:level command to change "the default 
security context for unlabeled files"[1]. The defcontext option requires 
a file system that supports extended attributes, since context context 
changes for newly-created files that would otherwise be labeled with the 
file_t type are written to disk. The file_t type is used for files 
(stored on a file system that supports extended attributes) that do not 
have an SELinux context. This type should not exist on correctly-labeled 
file systems.

The following example changes the default context to 
system_u:object_r:httpd_sys_content_t:s0:

# mount -o defcontext="system_u:object_r:httpd_sys_content_t:s0" 
/dev/sda1 /mount/point

In this example, if the file system on /dev/sda1 isn't labeled 
correctly, or isn't labeled at all, newly-created files are labeled with 
httpd_sys_content_t type, rather than the file_t type. If a file that 
would otherwise be labeled with the file_t type is created on this file 
system, it keeps the httpd_sys_content_t type, even when the file system 
is mounted without a context option.

[1] Morris, James. "Filesystem Labeling in SELinux". Published 1 October 
2004. Accessed 14 October 2008: http://www.linuxjournal.com/article/7426.

Multiple NFS Mounts from the same Export

To mount a single NFS export multiple times using a different SELinux 
context for each mount, use the mount -o nosharecache,context options. 
The context specified with with context option is not written to disk:

# mount hostname:/export /local/mount/web -o 
nosharecache,context="system_u:object_r:httpd_sys_content_t:s0"
# mount hostname:/export /local/mount/database -o 
nosharecache,context="system_u:object_r:mysqld_db_t:s0"

In this example, the hostname:/export NFS export is mounted to two 
different directories, /local/mount/web and /local/mount/database. Files 
mounted on /local/mount/web are labeled with the httpd_sys_content_t 
type. Files mounted on /local/mount/database are labeled with the 
mysqld_db_t type.

If a single system runs a MySQL® server as well as an Apache HTTP 
Server, and data files for both of those services are on a single NFS 
export, this example can be used to allow both the MySQL server and the 
Apache HTTP Server access to the required files, without exposing the 
files to other local services.

# This is probably incorrect. I do not know a proper use cases for this.

Note: if you attempt to mount a single NFS export multiple times with 
different contexts, but do not use the nosharecache option, mount fails 
with a mount.nfs: an incorrect mount option was specified error, and the 
following is logged to /var/log/messages:

kernel: SELinux: mount invalid.  Same superblock, different security 
settings for (dev 0:14, type nfs)

Further Information

For further information about file system labeling, refer to James 
Morris's "Filesystem Labeling in SELinux" article: 
http://www.linuxjournal.com/article/7426.
> 
>> Thanks!
>>
>> Mounting File Systems
>>
>> By default, when a third extended file system (ext3) is mounted, the 
>> files and directories on the file system are labeled with the file_t 
>> type. The mount command can override SELinux contexts when mounting file 
>> systems. SELinux context changes with the mount command can be 
>> per-session only (until the file system is unmounted), or persistent 
>> (context changes are written to disk).
>>
>> # what are default_t and file_t?
>>
>> Temporary Mount Context Changes
>>
>> As the Linux root user, use the mount -o 
>> context=SELinux_user:role:type:level option to temporarily override 
>> existing SELinux contexts. The -o context option requires a Linux 2.6 
>> kernel. When a file system is mounted with the -o context option:
>>
>> # does -o context only work with a 2.6 kernels?
>>
>> * SELinux context changes only occur in kernel memory, and as such, 
>> context changes are not written to disk. Any context changes made while 
>> such a file system is mounted are lost when the file system is unmounted.
>>
>> * If a file system is already labeled, and the contexts are overridden 
>> with the -o context option, the original contexts return when the file 
>> system is un-mounted.
>>
>> * Newly-created files and directories appear to have the SELinux context 
>> specified with -o context; however, since context changes are not 
>> written to disk for these situations, context changes are lost when the 
>> file system is un-mounted.
>>
>> * The -o context option works even if the file system to be mounted does 
>> not support extended attributes, although, any context changes made to 
>> such a file system are lost when the file system is unmounted.
>>
>> The following example labels all files on the file system to be mounted 
>> with the httpd_sys_content_t type:
>>
>> # mount -t ext3 -o context="system_u:object_r:httpd_sys_content_t:s0" 
>> /dev/sdax /mount/point
>>
>> -t ext3: The -t ext3 option specifies that an ext3 file system is to be 
>> mounted. Use the -t option to specify the correct file system. Refer to 
>> the mount(8) manual page for a list of file systems.
>>
>> -o context="system_u:object_r:httpd_sys_content_t:s0": The -o 
>> context="system_u:object_r:httpd_sys_content_t:s0" option specifies the 
>> SELinux context for all files on the file system to be mounted, as well 
>> as the mount point. This option overrides existing contexts.
>>
>> Type Enforcement is the main permission control used in SELinux targeted 
>> policy. For the most part, SELinux users and roles can be ignored, so, 
>> when overriding the SELinux context with mount, use the SELinux system_u 
>> user and object_r role, and concentrate on the type. In this example, 
>> all files on the /dev/sdax file system will be labeled with the 
>> httpd_sys_content_t type.
>>
>> /dev/sdax /mount/point: Specifies that the /dev/sdax device will be 
>> mounted to the /mount/point/ directory.
>>
>> <note>
>> When a file system is mounted with the -o context option, it is not 
>> possible to use the chcon command to change the SELinux context. Using 
>> chcon on such a file system results in a Operation not supported error.
>> </note>
>>
>> Persistent Mount Context Changes
>>
>> As the Linux root user, use the mount -o 
>> defcontext=SELinux_user:role:type:level option to persistently change 
>> the default SELinux context for a file system. The -o defcontext option 
>> requires a file system that supports extended attributes, since changes 
>> are written to disk. When a file system is mounted with the -o 
>> defcontext option:
>>
>> * Existing files keep their current contexts.
>>
>> * Context changes are written to disk, and are not lost if the file 
>> system is unmounted. Newly-created files and files copied to such a file 
>> system inherit the SELinux context specified with the -o defcontext 
>> option. For example, if a file system is mounted with the -o 
>> defcontext="system_u:object_r:httpd_sys_content_t:s0" option, and a new 
>> file is created on the mounted file system, that file is labeled with 
>> the httpd_sys_content_t type. If the file system is unmounted and then 
>> mounted without a context option, that file is still labeled with the 
>> httpd_sys_content_t type.
>>
>> The following example changes the default SELinux context for the file 
>> system to be mounted to system_u:object_r:httpd_sys_content_t:s0:
>>
>> # mount -t ext3 -o defcontext="system_u:object_r:httpd_sys_content_t:s0" 
>> /dev/sdax /mount/point
>>
>> [fill in similar to the previous section]
>>
>> # I do not understand the fscontext option. Should that be included?
>>
>> # Is there any common use cases that should have examples here, such as 
>> mounting a cd and sharing it via http or nfs?
>>
>> Apologies for any typos :(
>>
>> --
>> 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: "Mounting File Systems"

[Stephen Smalley]

On Thu, 2008-10-16 at 11:43 +1000, Murray McAllister wrote:
> Mounting File Systems

I'd start first by describing the common behavior, e.g.:

By default, when a filesystem that supports extended attributes is
mounted, the security context for each file is obtained from the
"security.selinux" extended attribute of the file.  Files in filesystems
that do not support extended attributes are assigned a single default
security context from the policy configuration based on filesystem type.

Then you can continue with:

> Use the mount -o context command to override existing extended 
> attributes.

or to specify a different default security context for filesystems that
do not support extended attributes.

>  This is useful if you do not trust a file system to supply 
> the correct attributes, for example, removable media used in multiple 
> systems. The mount -o context command can also be used to support 
> labeling for file systems that do not support extended attributes, such 
> as File Allocation Table (FAT) file systems.

Or NFS filesystems.

>  The context specified with 
> mount -o context is not written to disk: the original contexts are 
> preserved, and are seen when mounting without a context option.

if there were any extended attributes on the disk in the first place.
Which typically won't be the case when using context mounts.

> Temporary Mount Context Changes

I wouldn't call them "temporary".  We have called it mountpoint labeling
or context mounts in the past, and they can be "persistent" in the sense
of putting it in your fstab and having it always applied on every mount.
They just aren't stored on the media.

> As the Linux root user, use the mount -o 
> context=SELinux_user:role:type:level command to mount file systems with 
> the specified context, overriding existing contexts if they exist. 
> Context changes are not written to disk. In the following example, when 
> /dev/sda1 is mounted, all files on that file system are labeled with the 
> system_u:object_r:httpd_sys_content_t:s0 context. This example can be 
> used to share FAT file systems (or other file systems) via the Apache 
> HTTP server:
> 
> # mount -o context="system_u:object_r:httpd_sys_content_t:s0" /dev/sda1 
> /mount/point

I'd tend to give example of mounting removable devices (floppies,
CD/DVDs, USB drives) or NFS filesystems, as that is generally when one
would use a context mount.

> Newly-created files and directories on this file system appear to have 
> the SELinux context specified with -o context; however, since context 
> changes are not written to disk for these situations, context changes 
> are lost when the file system is unmounted. If such a file system is not 
> labeled, or does support extended attributes, it stays in that state 
> after being unmounted.
> 
> Type Enforcement is the main permission control used in SELinux targeted 
> policy. For the most part, SELinux users and roles can be ignored, so, 
> when overriding the SELinux context with -o context, use the SELinux 
> system_u user and object_r role, and concentrate on the type. If you are 
> not using the MLS policy or multi-category security, use the s0 level.
> 
> <note>
> When a file system is mounted with a context option, context changes (by 
> users and processes) are prohibited. For example, running chcon on a 
> file system mounted with a context option results in a Operation not 
> supported error.
> </note>
> 
> Changing the Default Context
> 
> As the Linux root user, use the mount -o 
> defcontext=SELinux_user:role:type:level command to change "the default 
> security context for unlabeled files"[1]. The defcontext option requires 
> a file system that supports extended attributes, since context context

double word

> changes for newly-created files that would otherwise be labeled with the 
> file_t type are written to disk.

What?  The point is that defcontext= is meaningless if the filesystem
doesn't support extended attributes because it means "treat files that
lack an extended attribute as if they had this context".  But the
defcontext itself is not stored on disk.

>  The file_t type is used for files 
> (stored on a file system that supports extended attributes) that do not 
> have an SELinux context. This type should not exist on correctly-labeled 
> file systems.
> 
> The following example changes the default context to 
> system_u:object_r:httpd_sys_content_t:s0:
> 
> # mount -o defcontext="system_u:object_r:httpd_sys_content_t:s0" 
> /dev/sda1 /mount/point

Again, I would tend to use an example that is more realistic, like a
removable device or NFS filesystem.

> In this example, if the file system on /dev/sda1 isn't labeled 
> correctly, or isn't labeled at all, newly-created files are labeled with 
> httpd_sys_content_t type, rather than the file_t type. If a file that 
> would otherwise be labeled with the file_t type is created on this file 
> system, it keeps the httpd_sys_content_t type, even when the file system 
> is mounted without a context option.
> 
> [1] Morris, James. "Filesystem Labeling in SELinux". Published 1 October 
> 2004. Accessed 14 October 2008: http://www.linuxjournal.com/article/7426.
> 
> Multiple NFS Mounts from the same Export
> 
> To mount a single NFS export multiple times using a different SELinux 
> context for each mount, use the mount -o nosharecache,context options. 
> The context specified with with context option is not written to disk:
> 
> # mount hostname:/export /local/mount/web -o 
> nosharecache,context="system_u:object_r:httpd_sys_content_t:s0"
> # mount hostname:/export /local/mount/database -o 
> nosharecache,context="system_u:object_r:mysqld_db_t:s0"

Caveat:  Do not ever do this for overlapping mounts or you'll create a
situation where the same file is accessible under two different security
contexts.

> In this example, the hostname:/export NFS export is mounted to two 
> different directories, /local/mount/web and /local/mount/database. Files 
> mounted on /local/mount/web are labeled with the httpd_sys_content_t 
> type. Files mounted on /local/mount/database are labeled with the 
> mysqld_db_t type.
> 
> If a single system runs a MySQL® server as well as an Apache HTTP 
> Server, and data files for both of those services are on a single NFS 
> export, this example can be used to allow both the MySQL server and the 
> Apache HTTP Server access to the required files, without exposing the 
> files to other local services.
> 
> # This is probably incorrect. I do not know a proper use cases for this.
> 
> Note: if you attempt to mount a single NFS export multiple times with 
> different contexts, but do not use the nosharecache option, mount fails 
> with a mount.nfs: an incorrect mount option was specified error, and the 
> following is logged to /var/log/messages:
> 
> kernel: SELinux: mount invalid.  Same superblock, different security 
> settings for (dev 0:14, type nfs)
> 
> Further Information
> 
> For further information about file system labeling, refer to James 
> Morris's "Filesystem Labeling in SELinux" article: 
> http://www.linuxjournal.com/article/7426.

-- 
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: "Mounting File Systems"

[Murray McAllister]

Stephen Smalley wrote:
> On Thu, 2008-10-16 at 11:43 +1000, Murray McAllister wrote:
>> Mounting File Systems
> 
> I'd start first by describing the common behavior, e.g.:
> 
> By default, when a filesystem that supports extended attributes is
> mounted, the security context for each file is obtained from the
> "security.selinux" extended attribute of the file.  Files in filesystems
> that do not support extended attributes are assigned a single default
> security context from the policy configuration based on filesystem type.
> 
> Then you can continue with:
> 
>> Use the mount -o context command to override existing extended 
>> attributes.
> 
> or to specify a different default security context for filesystems that
> do not support extended attributes.
> 
>>  This is useful if you do not trust a file system to supply 
>> the correct attributes, for example, removable media used in multiple 
>> systems. The mount -o context command can also be used to support 
>> labeling for file systems that do not support extended attributes, such 
>> as File Allocation Table (FAT) file systems.
> 
> Or NFS filesystems.
> 
>>  The context specified with 
>> mount -o context is not written to disk: the original contexts are 
>> preserved, and are seen when mounting without a context option.
> 
> if there were any extended attributes on the disk in the first place.
> Which typically won't be the case when using context mounts.
All of the above sounds good.
> 
>> Temporary Mount Context Changes
> 
> I wouldn't call them "temporary".  We have called it mountpoint labeling
> or context mounts in the past, and they can be "persistent" in the sense
> of putting it in your fstab and having it always applied on every mount.
> They just aren't stored on the media.
Changed to "Context Mounts".
> 
>> As the Linux root user, use the mount -o 
>> context=SELinux_user:role:type:level command to mount file systems with 
>> the specified context, overriding existing contexts if they exist. 
>> Context changes are not written to disk. In the following example, when 
>> /dev/sda1 is mounted, all files on that file system are labeled with the 
>> system_u:object_r:httpd_sys_content_t:s0 context. This example can be 
>> used to share FAT file systems (or other file systems) via the Apache 
>> HTTP server:
>>
>> # mount -o context="system_u:object_r:httpd_sys_content_t:s0" /dev/sda1 
>> /mount/point
> 
> I'd tend to give example of mounting removable devices (floppies,
> CD/DVDs, USB drives) or NFS filesystems, as that is generally when one
> would use a context mount.
I have used an NFS example.
>> Newly-created files and directories on this file system appear to have 
>> the SELinux context specified with -o context; however, since context 
>> changes are not written to disk for these situations, context changes 
>> are lost when the file system is unmounted. If such a file system is not 
>> labeled, or does support extended attributes, it stays in that state 
>> after being unmounted.
>>
>> Type Enforcement is the main permission control used in SELinux targeted 
>> policy. For the most part, SELinux users and roles can be ignored, so, 
>> when overriding the SELinux context with -o context, use the SELinux 
>> system_u user and object_r role, and concentrate on the type. If you are 
>> not using the MLS policy or multi-category security, use the s0 level.
>>
>> <note>
>> When a file system is mounted with a context option, context changes (by 
>> users and processes) are prohibited. For example, running chcon on a 
>> file system mounted with a context option results in a Operation not 
>> supported error.
>> </note>
>>
>> Changing the Default Context
>>
>> As the Linux root user, use the mount -o 
>> defcontext=SELinux_user:role:type:level command to change "the default 
>> security context for unlabeled files"[1]. The defcontext option requires 
>> a file system that supports extended attributes, since context context
> 
> double word
> 
>> changes for newly-created files that would otherwise be labeled with the 
>> file_t type are written to disk.
> 
> What?  The point is that defcontext= is meaningless if the filesystem
> doesn't support extended attributes because it means "treat files that
> lack an extended attribute as if they had this context".  But the
> defcontext itself is not stored on disk.
I was trying to explain (tested on Fedora Rawhide):

1. create a logical volume. mkfs.ext3 [new logical volume].
3. create a /test/ directory. mount the logical volume to /test/
5. create /test/file. This file uses the file_t type.
6. unmount.
7. mount with defcontext option. create /test/file2. File2 uses type 
specified with defcontext. "file" is still labeled with the file_t type.
9. remount with no context option. file2 still has the type specified 
with previous defcontext option.

Is this the expected behavior?
> 
>>  The file_t type is used for files 
>> (stored on a file system that supports extended attributes) that do not 
>> have an SELinux context. This type should not exist on correctly-labeled 
>> file systems.
>>
>> The following example changes the default context to 
>> system_u:object_r:httpd_sys_content_t:s0:
>>
>> # mount -o defcontext="system_u:object_r:httpd_sys_content_t:s0" 
>> /dev/sda1 /mount/point
> 
> Again, I would tend to use an example that is more realistic, like a
> removable device or NFS filesystem.
> 
>> In this example, if the file system on /dev/sda1 isn't labeled 
>> correctly, or isn't labeled at all, newly-created files are labeled with 
>> httpd_sys_content_t type, rather than the file_t type. If a file that 
>> would otherwise be labeled with the file_t type is created on this file 
>> system, it keeps the httpd_sys_content_t type, even when the file system 
>> is mounted without a context option.
>>
>> [1] Morris, James. "Filesystem Labeling in SELinux". Published 1 October 
>> 2004. Accessed 14 October 2008: http://www.linuxjournal.com/article/7426.
>>
>> Multiple NFS Mounts from the same Export
>>
>> To mount a single NFS export multiple times using a different SELinux 
>> context for each mount, use the mount -o nosharecache,context options. 
>> The context specified with with context option is not written to disk:
>>
>> # mount hostname:/export /local/mount/web -o 
>> nosharecache,context="system_u:object_r:httpd_sys_content_t:s0"
>> # mount hostname:/export /local/mount/database -o 
>> nosharecache,context="system_u:object_r:mysqld_db_t:s0"
> 
> Caveat:  Do not ever do this for overlapping mounts or you'll create a
> situation where the same file is accessible under two different security
> contexts.
Is overlapping what I have done above, or do you mean manually mounting 
an NFS export to the same directory that mounts the NFS export via 
autofs? I tried mounting via autofs, and then manually mounting with a 
context option in Rawhide. I had no errors or denials. mount showed:

localhost:/export on /misc/test type nfs 
(rw,soft,initr,sloppy,addr=127.0.0.1)

localhost:/export on /misc/test type nfs 
(rw,context="system_u:object_r:samba_share_t:s0",addr=127.0.0.1)

With both mounted, "ls -Z /misc/test" showed files using the 
samba_share_t type.
> 
>> In this example, the hostname:/export NFS export is mounted to two 
>> different directories, /local/mount/web and /local/mount/database. Files 
>> mounted on /local/mount/web are labeled with the httpd_sys_content_t 
>> type. Files mounted on /local/mount/database are labeled with the 
>> mysqld_db_t type.
>>
>> If a single system runs a MySQL® server as well as an Apache HTTP 
>> Server, and data files for both of those services are on a single NFS 
>> export, this example can be used to allow both the MySQL server and the 
>> Apache HTTP Server access to the required files, without exposing the 
>> files to other local services.
>>
>> # This is probably incorrect. I do not know a proper use cases for this.
>>
>> Note: if you attempt to mount a single NFS export multiple times with 
>> different contexts, but do not use the nosharecache option, mount fails 
>> with a mount.nfs: an incorrect mount option was specified error, and the 
>> following is logged to /var/log/messages:
>>
>> kernel: SELinux: mount invalid.  Same superblock, different security 
>> settings for (dev 0:14, type nfs)
>>
>> Further Information
>>
>> For further information about file system labeling, refer to James 
>> Morris's "Filesystem Labeling in SELinux" article: 
>> http://www.linuxjournal.com/article/7426.
> 


--
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: "Mounting File Systems"

[Murray McAllister]

Stephen Smalley wrote:
> On Thu, 2008-10-16 at 11:43 +1000, Murray McAllister wrote:
>> Mounting File Systems

>>
>> The following example changes the default context to 
>> system_u:object_r:httpd_sys_content_t:s0:
>>
>> # mount -o defcontext="system_u:object_r:httpd_sys_content_t:s0" 
>> /dev/sda1 /mount/point
> 
> Again, I would tend to use an example that is more realistic, like a
> removable device or NFS filesystem.

defcontext and NFS doesn't work. I've never owned a large removable 
device (I asked around the office and the people here use vfat).

Maybe a blurb (as Eric suggested) is better for this, instead of an example.

Thanks.

--
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: "Mounting File Systems"

[Stephen Smalley]

On Mon, 2008-10-20 at 10:07 +1000, Murray McAllister wrote:
> Stephen Smalley wrote:
> > On Thu, 2008-10-16 at 11:43 +1000, Murray McAllister wrote:
> >> Changing the Default Context
> >>
> >> As the Linux root user, use the mount -o 
> >> defcontext=SELinux_user:role:type:level command to change "the default 
> >> security context for unlabeled files"[1]. The defcontext option requires 
> >> a file system that supports extended attributes, since context context
> > 
> > double word
> > 
> >> changes for newly-created files that would otherwise be labeled with the 
> >> file_t type are written to disk.
> > 
> > What?  The point is that defcontext= is meaningless if the filesystem
> > doesn't support extended attributes because it means "treat files that
> > lack an extended attribute as if they had this context".  But the
> > defcontext itself is not stored on disk.
> I was trying to explain (tested on Fedora Rawhide):
> 
> 1. create a logical volume. mkfs.ext3 [new logical volume].
> 3. create a /test/ directory. mount the logical volume to /test/
> 5. create /test/file. This file uses the file_t type.
> 6. unmount.
> 7. mount with defcontext option. create /test/file2. File2 uses type 
> specified with defcontext. "file" is still labeled with the file_t type.
> 9. remount with no context option. file2 still has the type specified 
> with previous defcontext option.
> 
> Is this the expected behavior?

Yes, but not because the defcontext= is being stored on disk.  The
defcontext= option tells the kernel how to internally label files that
lack an extended attribute on disk.  When you create a new file, the
kernel computes a security context for the new file as previously
described based on a combination of the process context and the parent
directory context and optionally a type transition rule if one applies
and stores the computed security context as an extended attribute of the
file.  In your sequence of commands above, what is happening is that the
root directory of the filesystem is internally being labeled by the
kernel with the defcontext value (without ever being stored), and this
is affecting how new files are being labeled since they inherit their
type from the parent directory by default, and those new file labels are
being stored.  But the defcontext= value itself is NOT being stored on
disk.

> >> Multiple NFS Mounts from the same Export
> >>
> >> To mount a single NFS export multiple times using a different SELinux 
> >> context for each mount, use the mount -o nosharecache,context options. 
> >> The context specified with with context option is not written to disk:
> >>
> >> # mount hostname:/export /local/mount/web -o 
> >> nosharecache,context="system_u:object_r:httpd_sys_content_t:s0"
> >> # mount hostname:/export /local/mount/database -o 
> >> nosharecache,context="system_u:object_r:mysqld_db_t:s0"
> > 
> > Caveat:  Do not ever do this for overlapping mounts or you'll create a
> > situation where the same file is accessible under two different security
> > contexts.
> Is overlapping what I have done above, or do you mean manually mounting 
> an NFS export to the same directory that mounts the NFS export via 
> autofs?

It is what you did above - mounting the same subdirectory (/export) from
the same server (hostname) with two different security contexts.  Then
the same files are accessible under two different security contexts.  If
you instead mounted different subdirectories, e.g. /export/web
and /export/db, then it would be ok.

-- 
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: "Mounting File Systems"

[Murray McAllister]

Stephen Smalley wrote:
> On Mon, 2008-10-20 at 10:07 +1000, Murray McAllister wrote:
>> Stephen Smalley wrote:
>>> On Thu, 2008-10-16 at 11:43 +1000, Murray McAllister wrote:
>>>> Changing the Default Context
>>>>
>>>> As the Linux root user, use the mount -o 
>>>> defcontext=SELinux_user:role:type:level command to change "the default 
>>>> security context for unlabeled files"[1]. The defcontext option requires 
>>>> a file system that supports extended attributes, since context context
>>> double word
>>>
>>>> changes for newly-created files that would otherwise be labeled with the 
>>>> file_t type are written to disk.
>>> What?  The point is that defcontext= is meaningless if the filesystem
>>> doesn't support extended attributes because it means "treat files that
>>> lack an extended attribute as if they had this context".  But the
>>> defcontext itself is not stored on disk.
>> I was trying to explain (tested on Fedora Rawhide):
>>
>> 1. create a logical volume. mkfs.ext3 [new logical volume].
>> 3. create a /test/ directory. mount the logical volume to /test/
>> 5. create /test/file. This file uses the file_t type.
>> 6. unmount.
>> 7. mount with defcontext option. create /test/file2. File2 uses type 
>> specified with defcontext. "file" is still labeled with the file_t type.
>> 9. remount with no context option. file2 still has the type specified 
>> with previous defcontext option.
>>
>> Is this the expected behavior?
> 
> Yes, but not because the defcontext= is being stored on disk.  The
> defcontext= option tells the kernel how to internally label files that
> lack an extended attribute on disk.  When you create a new file, the
> kernel computes a security context for the new file as previously
> described based on a combination of the process context and the parent
> directory context and optionally a type transition rule if one applies
> and stores the computed security context as an extended attribute of the
> file.  In your sequence of commands above, what is happening is that the
> root directory of the filesystem is internally being labeled by the
> kernel with the defcontext value (without ever being stored), and this
> is affecting how new files are being labeled since they inherit their
> type from the parent directory by default, and those new file labels are
> being stored.  But the defcontext= value itself is NOT being stored on
> disk.
I have tried to make this clearer. How about:

Changing the Default Context

The file_t type is the default type used for files (stored on file 
systems that support extended attributes) that do not have an SELinux 
context. This type should not exist on correctly-labeled file systems. 
If a new file system is created and not labeled before use, files and 
directories created on it may be labled with the file_t type. If it is 
desirable that this default type for unlabeled files be changed, use the 
the defcontext option when mounting the file system.

The following example mounts a newly-created file system (on /dev/sda2) 
to the newly-created /test/ directory. It assumes that there are no 
rules in /etc/selinux/targeted/contexts/files/ that define a context for 
the /test/ directory:

# mount /dev/sda2 /test/ -o defcontext="system_u:object_r:samba_share_t:s0"

In this example:

* the defcontext option defines that system_u:object_r:samba_share_t:s0 
is "the default security context for unlabeled files"[1].

* when mounted, the root directory (/test/) of the file system is 
labeled with the context specified by defcontext (this label is not 
stored on disk). This affects the labelling for files created under 
/test/: new files inherit the samba_share_t type, and these labels are 
stored on disk.

* the context specified with defcontext is lost when the file system is 
unmounted: the /test/ directory returns to being labeled with the file_t 
type. Files created under /test/ while the file system was mounted with 
a defcontext option retain their labels.

[1] Morris, James. "Filesystem Labeling in SELinux". Published 1 October 
2004. Accessed 14 October 2008: http://www.linuxjournal.com/article/7426.

> 
>>>> Multiple NFS Mounts from the same Export
>>>>
>>>> To mount a single NFS export multiple times using a different SELinux 
>>>> context for each mount, use the mount -o nosharecache,context options. 
>>>> The context specified with with context option is not written to disk:
>>>>
>>>> # mount hostname:/export /local/mount/web -o 
>>>> nosharecache,context="system_u:object_r:httpd_sys_content_t:s0"
>>>> # mount hostname:/export /local/mount/database -o 
>>>> nosharecache,context="system_u:object_r:mysqld_db_t:s0"
>>> Caveat:  Do not ever do this for overlapping mounts or you'll create a
>>> situation where the same file is accessible under two different security
>>> contexts.
>> Is overlapping what I have done above, or do you mean manually mounting 
>> an NFS export to the same directory that mounts the NFS export via 
>> autofs?
> 
> It is what you did above - mounting the same subdirectory (/export) from
> the same server (hostname) with two different security contexts.  Then
> the same files are accessible under two different security contexts.  If
> you instead mounted different subdirectories, e.g. /export/web
> and /export/db, then it would be ok.
> 
Different subdirectories is the example Eric gave me, but I messed it 
up. How about:

Mounting an NFS File System

By default, NFS mounts on the client side are labeled with the nfs_t 
type. Depending on policy configuration, services, such as Apache HTTP 
Server and MySQL, may not be able to read files labeled with the nfs_t 
type. This prevents an NFS file system being mounted and then read or 
exported by another service.

If you would like to mount an NFS file system and read or export that 
file system with another service, use the context option when mounting 
to override the nfs_t type. Use the following context option to mount 
NFS file systems so that they can be shared via the Apache HTTP Server:

mount localhost:/export /local/mount/point -o\
context="system_u:object_r:httpd_sys_content_t:s0"

Since context changes are not written to disk for these situations, 
context changes are lost when the file system is unmounted. If such a 
file system is not labeled, or does support extended attributes, it 
stays in that state after being unmounted.

Multiple NFS Mounts

When mounting multiple mounts from the same NFS export, attempting to 
override the SELinux context of each mount with a different context, 
results in subsequent mount commands failing. In the following example, 
the NFS server has a single export, /export, which has two 
subdirectories, web/ and database/. The following commands attempt two 
mounts from the single NFS export, and try to override the context for 
each one:

# mount localhost:/export/web /local/web -o\
context="system_u:object_r:httpd_sys_content_t:s0"

# mount localhost:/export/database /local/database -o\
context="system_u:object_r:mysqld_db_t:s0"

The second mount command fails, and the following is logged to 
/var/log/messages:

kernel: SELinux: mount invalid.  Same superblock, different security 
settings for (dev 0:15, type nfs)

To mount multiple mounts from a single NFS export, with each mount 
having a different context, use the -o nosharecache,context options. The 
following example mounts multiple mounts from a single NFS export, with 
a different context for each mount (allowing different services access):

# mount localhost:/export/web /local/web -o\
nosharecache,context="system_u:object_r:httpd_sys_content_t:s0"

# mount localhost:/export/database /local/database -o\
nosharecache,context="system_u:object_r:mysqld_db_t:s0"

In this example, localhost:/export/web is mounted locally to 
/local/web/, with all files being labeled with the httpd_sys_content_t 
type, allowing Apache HTTP Server access. localhost:/export/database is 
mounted locally to /local/database, with all files being labeled with 
the mysqld_db_t type, allowing MySQL access. These type changes are not 
written to disk.

<important note>
The nosharecache options allows you to mount the same subdirectory of an 
export multiple times with different contexts (for example, mounting 
/export/web multiple times). Do not mount the same subdirectory from an 
export multiple times with different contexts, as this creates an 
overlapping mount, where files are accessible under two different contexts.
</important note>

Thanks for your help.

--
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: "Mounting File Systems"

[Stephen Smalley]

On Wed, 2008-10-22 at 15:23 +1000, Murray McAllister wrote:
> I have tried to make this clearer. How about:
> 
> Changing the Default Context
> 
> The file_t type is the default type used for files (stored on file 
> systems that support extended attributes) that do not have an SELinux 
> context.

Generalize:  When a file that lacks a SELinux extended attribute on disk
is accessed, the kernel treats it internally as if it had a default
context value defined by the policy.  In common policies, this default
context value has the file_t type, and this should be the only use of
this type so that such files can be distinguished in policy and
generally kept inaccessible to confined domains.

>  This type should not exist on correctly-labeled file systems.

because all files in such filesystems should have a SELinux extended
attribute set on disk, and the file_t type is never used in the
file_contexts configuration.  Instead, a default_t type is set on files
that do not match any other pattern in the file_contexts configuration
in order to distinguish them from files that have no security context on
disk.

> If a new file system is created and not labeled before use, files and 
> directories created on it may be labled with the file_t type. If it is 
> desirable that this default type for unlabeled files be changed, use the 
> the defcontext option when mounting the file system.
> 
> The following example mounts a newly-created file system (on /dev/sda2) 
> to the newly-created /test/ directory. It assumes that there are no 
> rules in /etc/selinux/targeted/contexts/files/ that define a context for 
> the /test/ directory:
> 
> # mount /dev/sda2 /test/ -o defcontext="system_u:object_r:samba_share_t:s0"
> 
> In this example:
> 
> * the defcontext option defines that system_u:object_r:samba_share_t:s0 
> is "the default security context for unlabeled files"[1].
> 
> * when mounted, the root directory (/test/) of the file system is 
> labeled

s/labeled/treated as if it were labeled/
(the label is not set on disk)

>  with the context specified by defcontext (this label is not 
> stored on disk). This affects the labelling for files created under 
> /test/: new files inherit the samba_share_t type, and these labels are 
> stored on disk.
> 
> * the context specified with defcontext is lost when the file system is 
> unmounted: the /test/ directory returns to being labeled with the file_t 
> type.

Not "lost", but not stored on disk.  It will be preserved on each mount
if it is added as a mount option to /etc/fstab or automounter maps.  It
doesn't change to file_t at unmount; it will be treated as file_t (or
more generally, the default context value defined by policy) if it is
later mounted without the defcontext= option.

> Different subdirectories is the example Eric gave me, but I messed it 
> up. How about:
> 
> Mounting an NFS File System
> 
> By default, NFS mounts on the client side are labeled with the nfs_t 
> type.

Generalize:  "labeled with a default context defined by policy for NFS
filesystems.  In common policies, this default context has the nfs_t
type.

>  Depending on policy configuration, services, such as Apache HTTP 
> Server and MySQL, may not be able to read files labeled with the nfs_t 
> type. This prevents an NFS file system being mounted and then read or 
> exported by another service.

Might be booleans that control this area as well; I don't know offhand.

> If you would like to mount an NFS file system and read or export that 
> file system with another service, use the context option when mounting 
> to override the nfs_t type. Use the following context option to mount 
> NFS file systems so that they can be shared via the Apache HTTP Server:
> 
> mount localhost:/export /local/mount/point -o\
> context="system_u:object_r:httpd_sys_content_t:s0"

The options really ought to go into their fstab or automounter maps so
that they are preserved on each mount.

You should also note the types defined to allow multiple services to
access the same content.  Ask Dan.

> Since context changes are not written to disk for these situations, 
> context changes are lost when the file system is unmounted.

Not "lost"; just not stored on disk.  Whether or not it keeps that label
on the next mount depends on whether you mount it with the context
option consistently.  Best way to do that is to put it in your fstab or
automounter configs.

>  If such a 
> file system is not labeled, or does support extended attributes, it 
> stays in that state after being unmounted.
> 
> Multiple NFS Mounts
> 
> When mounting multiple mounts from the same NFS export, attempting to 
> override the SELinux context of each mount with a different context, 
> results in subsequent mount commands failing. In the following example, 
> the NFS server has a single export, /export, which has two 
> subdirectories, web/ and database/. The following commands attempt two 
> mounts from the single NFS export, and try to override the context for 
> each one:
> 
> # mount localhost:/export/web /local/web -o\
> context="system_u:object_r:httpd_sys_content_t:s0"
> 
> # mount localhost:/export/database /local/database -o\
> context="system_u:object_r:mysqld_db_t:s0"
> 
> The second mount command fails, and the following is logged to 
> /var/log/messages:
> 
> kernel: SELinux: mount invalid.  Same superblock, different security 
> settings for (dev 0:15, type nfs)
> 
> To mount multiple mounts from a single NFS export, with each mount 
> having a different context, use the -o nosharecache,context options. The 
> following example mounts multiple mounts from a single NFS export, with 
> a different context for each mount (allowing different services access):
> 
> # mount localhost:/export/web /local/web -o\
> nosharecache,context="system_u:object_r:httpd_sys_content_t:s0"
> 
> # mount localhost:/export/database /local/database -o\
> nosharecache,context="system_u:object_r:mysqld_db_t:s0"
> 
> In this example, localhost:/export/web is mounted locally to 
> /local/web/, with all files being labeled with the httpd_sys_content_t 
> type, allowing Apache HTTP Server access. localhost:/export/database is 
> mounted locally to /local/database, with all files being labeled with 
> the mysqld_db_t type, allowing MySQL access. These type changes are not 
> written to disk.
> 
> <important note>
> The nosharecache options allows you to mount the same subdirectory of an 
> export multiple times with different contexts (for example, mounting 
> /export/web multiple times). Do not mount the same subdirectory from an 
> export multiple times with different contexts, as this creates an 
> overlapping mount, where files are accessible under two different contexts.
> </important note>
> 
> Thanks for your help.
-- 
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: "Mounting File Systems"

[Daniel J Walsh]

Stephen Smalley wrote:
> On Wed, 2008-10-22 at 15:23 +1000, Murray McAllister wrote:
>> I have tried to make this clearer. How about:
>>
>> Changing the Default Context
>>
>> The file_t type is the default type used for files (stored on file 
>> systems that support extended attributes) that do not have an SELinux 
>> context.
> 
> Generalize:  When a file that lacks a SELinux extended attribute on disk
> is accessed, the kernel treats it internally as if it had a default
> context value defined by the policy.  In common policies, this default
> context value has the file_t type, and this should be the only use of
> this type so that such files can be distinguished in policy and
> generally kept inaccessible to confined domains.
> 
>>  This type should not exist on correctly-labeled file systems.
> 
> because all files in such filesystems should have a SELinux extended
> attribute set on disk, and the file_t type is never used in the
> file_contexts configuration.  Instead, a default_t type is set on files
> that do not match any other pattern in the file_contexts configuration
> in order to distinguish them from files that have no security context on
> disk.
> 
>> If a new file system is created and not labeled before use, files and 
>> directories created on it may be labled with the file_t type. If it is 
>> desirable that this default type for unlabeled files be changed, use the 
>> the defcontext option when mounting the file system.
>>
>> The following example mounts a newly-created file system (on /dev/sda2) 
>> to the newly-created /test/ directory. It assumes that there are no 
>> rules in /etc/selinux/targeted/contexts/files/ that define a context for 
>> the /test/ directory:
>>
>> # mount /dev/sda2 /test/ -o defcontext="system_u:object_r:samba_share_t:s0"
>>
>> In this example:
>>
>> * the defcontext option defines that system_u:object_r:samba_share_t:s0 
>> is "the default security context for unlabeled files"[1].
>>
>> * when mounted, the root directory (/test/) of the file system is 
>> labeled
> 
> s/labeled/treated as if it were labeled/
> (the label is not set on disk)
> 
>>  with the context specified by defcontext (this label is not 
>> stored on disk). This affects the labelling for files created under 
>> /test/: new files inherit the samba_share_t type, and these labels are 
>> stored on disk.
>>
>> * the context specified with defcontext is lost when the file system is 
>> unmounted: the /test/ directory returns to being labeled with the file_t 
>> type.
> 
> Not "lost", but not stored on disk.  It will be preserved on each mount
> if it is added as a mount option to /etc/fstab or automounter maps.  It
> doesn't change to file_t at unmount; it will be treated as file_t (or
> more generally, the default context value defined by policy) if it is
> later mounted without the defcontext= option.
> 
>> Different subdirectories is the example Eric gave me, but I messed it 
>> up. How about:
>>
>> Mounting an NFS File System
>>
>> By default, NFS mounts on the client side are labeled with the nfs_t 
>> type.
> 
> Generalize:  "labeled with a default context defined by policy for NFS
> filesystems.  In common policies, this default context has the nfs_t
> type.
> 
>>  Depending on policy configuration, services, such as Apache HTTP 
>> Server and MySQL, may not be able to read files labeled with the nfs_t 
>> type. This prevents an NFS file system being mounted and then read or 
>> exported by another service.
> 
> Might be booleans that control this area as well; I don't know offhand.
> 
/usr/sbin/getsebool -a shows the following booleans available to use
nfs,   "use_nfs_home_dirs"  allows all domains that need access to
homedirs, access to nfs_t.  (cifs_t samba filesystems) have similar
booleans.
allow_ftpd_use_nfs --> off
httpd_use_nfs --> off
qemu_use_nfs --> on
samba_share_nfs --> off
use_nfs_home_dirs --> on
virt_use_nfs --> off
xen_use_nfs --> off

>> If you would like to mount an NFS file system and read or export that 
>> file system with another service, use the context option when mounting 
>> to override the nfs_t type. Use the following context option to mount 
>> NFS file systems so that they can be shared via the Apache HTTP Server:
>>
>> mount localhost:/export /local/mount/point -o\
>> context="system_u:object_r:httpd_sys_content_t:s0"
> 
> The options really ought to go into their fstab or automounter maps so
> that they are preserved on each mount.
> 
> You should also note the types defined to allow multiple services to
> access the same content.  Ask Dan.
> 

public_content_t
public_content_rw_t

>> Since context changes are not written to disk for these situations, 
>> context changes are lost when the file system is unmounted.
> 
> Not "lost"; just not stored on disk.  Whether or not it keeps that label
> on the next mount depends on whether you mount it with the context
> option consistently.  Best way to do that is to put it in your fstab or
> automounter configs.
> 
>>  If such a 
>> file system is not labeled, or does support extended attributes, it 
>> stays in that state after being unmounted.
>>
>> Multiple NFS Mounts
>>
>> When mounting multiple mounts from the same NFS export, attempting to 
>> override the SELinux context of each mount with a different context, 
>> results in subsequent mount commands failing. In the following example, 
>> the NFS server has a single export, /export, which has two 
>> subdirectories, web/ and database/. The following commands attempt two 
>> mounts from the single NFS export, and try to override the context for 
>> each one:
>>
>> # mount localhost:/export/web /local/web -o\
>> context="system_u:object_r:httpd_sys_content_t:s0"
>>
>> # mount localhost:/export/database /local/database -o\
>> context="system_u:object_r:mysqld_db_t:s0"
>>
>> The second mount command fails, and the following is logged to 
>> /var/log/messages:
>>
>> kernel: SELinux: mount invalid.  Same superblock, different security 
>> settings for (dev 0:15, type nfs)
>>
>> To mount multiple mounts from a single NFS export, with each mount 
>> having a different context, use the -o nosharecache,context options. The 
>> following example mounts multiple mounts from a single NFS export, with 
>> a different context for each mount (allowing different services access):
>>
>> # mount localhost:/export/web /local/web -o\
>> nosharecache,context="system_u:object_r:httpd_sys_content_t:s0"
>>
>> # mount localhost:/export/database /local/database -o\
>> nosharecache,context="system_u:object_r:mysqld_db_t:s0"
>>
>> In this example, localhost:/export/web is mounted locally to 
>> /local/web/, with all files being labeled with the httpd_sys_content_t 
>> type, allowing Apache HTTP Server access. localhost:/export/database is 
>> mounted locally to /local/database, with all files being labeled with 
>> the mysqld_db_t type, allowing MySQL access. These type changes are not 
>> written to disk.
>>
>> <important note>
>> The nosharecache options allows you to mount the same subdirectory of an 
>> export multiple times with different contexts (for example, mounting 
>> /export/web multiple times). Do not mount the same subdirectory from an 
>> export multiple times with different contexts, as this creates an 
>> overlapping mount, where files are accessible under two different contexts.
>> </important note>
>>
>> Thanks for your help.


--
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: "Mounting File Systems"

[Murray McAllister]

Stephen Smalley wrote:
> On Wed, 2008-10-22 at 15:23 +1000, Murray McAllister wrote:
>> I have tried to make this clearer. How about:
>>
>> Changing the Default Context
>>
>> The file_t type is the default type used for files (stored on file 
>> systems that support extended attributes) that do not have an SELinux 
>> context.
> 
> Generalize:  When a file that lacks a SELinux extended attribute on disk
> is accessed, the kernel treats it internally as if it had a default
> context value defined by the policy.  In common policies, this default
> context value has the file_t type, and this should be the only use of
> this type so that such files can be distinguished in policy and
> generally kept inaccessible to confined domains.
> 
>>  This type should not exist on correctly-labeled file systems.
> 
> because all files in such filesystems should have a SELinux extended
> attribute set on disk, and the file_t type is never used in the
> file_contexts configuration.  Instead, a default_t type is set on files
> that do not match any other pattern in the file_contexts configuration
> in order to distinguish them from files that have no security context on
> disk.
I have tried to put this information into a section before the mounting 
section (to avoid too much text in them):

The file_t and default_t Types

On file systems that support extended attributes, when a file that lacks 
an SELinux context on disk is accessed, it is treated as if it had a 
default context as defined by SELinux policy. In common policies, this 
default context uses the file_t type. This should be the only use of 
this type, so that files without a context on disk can be distinguished 
in policy, and generally kept inaccessible to confined domains. The 
file_t type should not exist on a correctly-labeled file systems, 
because all files on a system running SELinux should have an SELinux 
context, and the file_t type is never used in file-context configuration.[1]

The default_t type is used on files that do not match any other pattern 
in file-context configuration, so that such files can be distinguished 
from files that do not have a context on disk, and generally kept 
inaccessible to confined domains. If you create a new top-level 
directory, such as /mydirectory/, this directory may be labeled with the 
default_t type. If services need access to such a directory, update the 
file-contexts configuration for this location. Refer to Section 5.7.2, 
“Persistent Changes: semanage fcontext” for details on adding a context 
to the file-context configuration.

[1]Files in /etc/selinux/targeted/contexts/files/ define contexts for 
files and directories. Files in this directory are read by restorecon 
and setfiles to restore files and directories to their default contexts.
> 
>> If a new file system is created and not labeled before use, files and 
>> directories created on it may be labled with the file_t type. If it is 
>> desirable that this default type for unlabeled files be changed, use the 
>> the defcontext option when mounting the file system.
>>
>> The following example mounts a newly-created file system (on /dev/sda2) 
>> to the newly-created /test/ directory. It assumes that there are no 
>> rules in /etc/selinux/targeted/contexts/files/ that define a context for 
>> the /test/ directory:
>>
>> # mount /dev/sda2 /test/ -o defcontext="system_u:object_r:samba_share_t:s0"
>>
>> In this example:
>>
>> * the defcontext option defines that system_u:object_r:samba_share_t:s0 
>> is "the default security context for unlabeled files"[1].
>>
>> * when mounted, the root directory (/test/) of the file system is 
>> labeled
> 
> s/labeled/treated as if it were labeled/
> (the label is not set on disk)
> 
>>  with the context specified by defcontext (this label is not 
>> stored on disk). This affects the labelling for files created under 
>> /test/: new files inherit the samba_share_t type, and these labels are 
>> stored on disk.
>>
>> * the context specified with defcontext is lost when the file system is 
>> unmounted: the /test/ directory returns to being labeled with the file_t 
>> type.
> 
> Not "lost", but not stored on disk.  It will be preserved on each mount
> if it is added as a mount option to /etc/fstab or automounter maps.  It
> doesn't change to file_t at unmount; it will be treated as file_t (or
> more generally, the default context value defined by policy) if it is
> later mounted without the defcontext= option.
I found this confusing so I removed it and left it as:

Files created under /test/ while the file system was mounted with a 
defcontext option retain their labels.
> 
>> Different subdirectories is the example Eric gave me, but I messed it 
>> up. How about:
>>
>> Mounting an NFS File System
>>
>> By default, NFS mounts on the client side are labeled with the nfs_t 
>> type.
> 
> Generalize:  "labeled with a default context defined by policy for NFS
> filesystems.  In common policies, this default context has the nfs_t
> type.
This sounds good.
> 
>>  Depending on policy configuration, services, such as Apache HTTP 
>> Server and MySQL, may not be able to read files labeled with the nfs_t 
>> type. This prevents an NFS file system being mounted and then read or 
>> exported by another service.
> 
> Might be booleans that control this area as well; I don't know offhand.
There are. How about:

As an alternative to mounting file systems with context options, 
Booleans can be turned on to allow services access to file systems 
labeled with the nfs_t type. Refer to [link to section when complete] 
for intructions on configuring Booleans to allow services access to the 
nfs_t type.

Where "[link to section when complete]" is a link the Boolean section 
that details how to do this (it doesn't yet - I need to add it).
> 
>> If you would like to mount an NFS file system and read or export that 
>> file system with another service, use the context option when mounting 
>> to override the nfs_t type. Use the following context option to mount 
>> NFS file systems so that they can be shared via the Apache HTTP Server:
>>
>> mount localhost:/export /local/mount/point -o\
>> context="system_u:object_r:httpd_sys_content_t:s0"
> 
> The options really ought to go into their fstab or automounter maps so
> that they are preserved on each mount.
I've added text similar to the following for each section:

To make the [context] option persistent across mounts, add an entry for 
the file system in /etc/fstab or an automounter map, and use the desired 
context as a mount option.

I did not include examples since there are too many other options, 
particularly for automounting NFS.
> 
> You should also note the types defined to allow multiple services to
> access the same content.  Ask Dan.
I am going to put those in a separate section since the man pages say 
there are additional booleans to set.
> 
>> Since context changes are not written to disk for these situations, 
>> context changes are lost when the file system is unmounted.
> 
> Not "lost"; just not stored on disk.  Whether or not it keeps that label
> on the next mount depends on whether you mount it with the context
> option consistently.  Best way to do that is to put it in your fstab or
> automounter configs.
How about:

since context changes are not written to disk for these situations, the 
context specified with the context option is only retained if the 
context option is used on the next mount, and if the same context is 
specified.
> 
>>  If such a 
>> file system is not labeled, or does support extended attributes, it 
>> stays in that state after being unmounted.
>>
>> Multiple NFS Mounts
>>
>> When mounting multiple mounts from the same NFS export, attempting to 
>> override the SELinux context of each mount with a different context, 
>> results in subsequent mount commands failing. In the following example, 
>> the NFS server has a single export, /export, which has two 
>> subdirectories, web/ and database/. The following commands attempt two 
>> mounts from the single NFS export, and try to override the context for 
>> each one:
>>
>> # mount localhost:/export/web /local/web -o\
>> context="system_u:object_r:httpd_sys_content_t:s0"
>>
>> # mount localhost:/export/database /local/database -o\
>> context="system_u:object_r:mysqld_db_t:s0"
>>
>> The second mount command fails, and the following is logged to 
>> /var/log/messages:
>>
>> kernel: SELinux: mount invalid.  Same superblock, different security 
>> settings for (dev 0:15, type nfs)
>>
>> To mount multiple mounts from a single NFS export, with each mount 
>> having a different context, use the -o nosharecache,context options. The 
>> following example mounts multiple mounts from a single NFS export, with 
>> a different context for each mount (allowing different services access):
>>
>> # mount localhost:/export/web /local/web -o\
>> nosharecache,context="system_u:object_r:httpd_sys_content_t:s0"
>>
>> # mount localhost:/export/database /local/database -o\
>> nosharecache,context="system_u:object_r:mysqld_db_t:s0"
>>
>> In this example, localhost:/export/web is mounted locally to 
>> /local/web/, with all files being labeled with the httpd_sys_content_t 
>> type, allowing Apache HTTP Server access. localhost:/export/database is 
>> mounted locally to /local/database, with all files being labeled with 
>> the mysqld_db_t type, allowing MySQL access. These type changes are not 
>> written to disk.
>>
>> <important note>
>> The nosharecache options allows you to mount the same subdirectory of an 
>> export multiple times with different contexts (for example, mounting 
>> /export/web multiple times). Do not mount the same subdirectory from an 
>> export multiple times with different contexts, as this creates an 
>> overlapping mount, where files are accessible under two different contexts.
>> </important note>
>>
>> Thanks for your help.

--
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: "Mounting File Systems"

[Murray McAllister]

Murray McAllister wrote:
> Stephen Smalley wrote:
>> On Wed, 2008-10-22 at 15:23 +1000, Murray McAllister wrote:

>>>
>>> mount localhost:/export /local/mount/point -o\
>>> context="system_u:object_r:httpd_sys_content_t:s0"
>>
>> The options really ought to go into their fstab or automounter maps so
>> that they are preserved on each mount.
> I've added text similar to the following for each section:
> 
> To make the [context] option persistent across mounts, add an entry for 
> the file system in /etc/fstab or an automounter map, and use the desired 
> context as a mount option.
> 
> I did not include examples since there are too many other options, 
> particularly for automounting NFS.
I'll include an fstab example to make it clear not to use "-o" in fstab.

Thanks for the 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: "Mounting File Systems"

[Murray McAllister]

Daniel J Walsh wrote:
> Stephen Smalley wrote:
>> On Wed, 2008-10-22 at 15:23 +1000, Murray McAllister wrote:

>>>  Depending on policy configuration, services, such as Apache HTTP 
>>> Server and MySQL, may not be able to read files labeled with the nfs_t 
>>> type. This prevents an NFS file system being mounted and then read or 
>>> exported by another service.
>> Might be booleans that control this area as well; I don't know offhand.
>>
> /usr/sbin/getsebool -a shows the following booleans available to use
> nfs,   "use_nfs_home_dirs"  allows all domains that need access to
> homedirs, access to nfs_t.
Do other Booleans have to be turned on? I do not understand the output 
of sesearch -C, for example:

DT allow httpd_t nfs_t : file { ioctl read getattr lock } ; [ 
httpd_enable_homedirs use_nfs_home_dirs && ]

I guess this means both Booleans have to be turned on for the allow rule 
to work?

Stupid question: what do "DT" and "ET" stand for?

Thanks.
   (cifs_t samba filesystems) have similar
> booleans.
> allow_ftpd_use_nfs --> off
> httpd_use_nfs --> off
> qemu_use_nfs --> on
> samba_share_nfs --> off
> use_nfs_home_dirs --> on
> virt_use_nfs --> off
> xen_use_nfs --> off

--
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: "Mounting File Systems"

[Daniel J Walsh]

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

Murray McAllister wrote:
> Daniel J Walsh wrote:
>> Stephen Smalley wrote:
>>> On Wed, 2008-10-22 at 15:23 +1000, Murray McAllister wrote:
> 
>>>>  Depending on policy configuration, services, such as Apache HTTP
>>>> Server and MySQL, may not be able to read files labeled with the
>>>> nfs_t type. This prevents an NFS file system being mounted and then
>>>> read or exported by another service.
>>> Might be booleans that control this area as well; I don't know offhand.
>>>
>> /usr/sbin/getsebool -a shows the following booleans available to use
>> nfs,   "use_nfs_home_dirs"  allows all domains that need access to
>> homedirs, access to nfs_t.
> Do other Booleans have to be turned on? I do not understand the output
> of sesearch -C, for example:
> 
> DT allow httpd_t nfs_t : file { ioctl read getattr lock } ; [
> httpd_enable_homedirs use_nfs_home_dirs && ]
Good question, I don't know.  Yes both booleans have to be turned on in
RHEL5.
> 
> I guess this means both Booleans have to be turned on for the allow rule
> to work?
> 
> Stupid question: what do "DT" and "ET" stand for?
> 
> Thanks.
>   (cifs_t samba filesystems) have similar
>> booleans.
>> allow_ftpd_use_nfs --> off
>> httpd_use_nfs --> off
>> qemu_use_nfs --> on
>> samba_share_nfs --> off
>> use_nfs_home_dirs --> on
>> virt_use_nfs --> off
>> xen_use_nfs --> off
> 
> -- 
> 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.

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

iEYEARECAAYFAkkHop4ACgkQrlYvE4MpobN5nQCeKA/EESk/Ga0vs6Jl6JO9KIsL
TfwAnjgxzu+QQXRWELbJ6uCHA6jfodA6
=+pFc
-----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.