Bug 1015779

Summary: staff_u cannot access external media (file_t)
Product: [Fedora] Fedora Reporter: William Brown <william>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: dominick.grift, dwalsh, lvrabec, mgrepl
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-10-07 13:43:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description William Brown 2013-10-05 10:53:48 UTC
Description of problem:
A user with the selinux user type of staff_u is unable to access external USB media under /run/media/<username>. The mount point to the user is:
ls -alZ /run/media/william 
ls: cannot access /run/media/william/backups: Permission denied
drwxr-x---+ root root system_u:object_r:mnt_t:s0       .
drwxr-xr-x. root root system_u:object_r:mnt_t:s0       ..
?---------  ?    ?                                     backups


As unconfined it is:

ls -alZ /run/media/william/
drwxr-x---+ root root system_u:object_r:mnt_t:s0       .
drwxr-xr-x. root root system_u:object_r:mnt_t:s0       ..
drwxr-xr-x. root root system_u:object_r:file_t:s0      backups

Either staff_u should be able to access file_t, or external media should be mounted with a different label allowing access.

Attempting to restorecon on /run/media, I can see a large number of restorecon:  Warning no default label for /run/media/william/

Should this have a different filecontext attached?


Version-Release number of selected component (if applicable):
selinux-policy-3.12.1-74.8.fc19.noarch

How reproducible:
Always

Comment 1 Dominick Grift 2013-10-05 15:26:57 UTC
The file_t type security identifier is associated to whats called the file initial security identifiers.

initial security identifiers are hardcoded into SELinux, and are used for:

1. system initialization
2. predefined resources
3. for failover

The file ISID falls in the last category. It is used for failover.

The file ISID is automatically associated by SELinux to object that how no security context inforation associated to it currently. SELinux notices that the mounted partition has not labeling information stored persistently, and so SELinux kicks in and labels the objects with the file_t sid ( again, which is associated to the file isid )

We do not want to allow confined users to be able to operate on resources that has no security labels associated

The solution is to use on of the four ways available to label the resources.

If the filesystem in question supports the security extended attribute then labeling information can be stored persistently on the objects. Thus in that case you only have to take care of labeling once.

Comment 2 William Brown 2013-10-05 23:29:25 UTC
Luckily, my external storage does support labelling. However, in the case it did not, what is the correct course of action?

Additionally, what command should be used to label this? I do not feel it right to add the external media with semanage fcontext + restorecon.

Comment 3 Daniel Walsh 2013-10-07 13:43:52 UTC
You could mount the device with a label.  But file_t would not be returned on a device that does not support labeling. Most likely it would have been something like dosfs_t.  Or the label of the file system.