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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
