Bug 1015779 - staff_u cannot access external media (file_t)
Summary: staff_u cannot access external media (file_t)
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-05 10:53 UTC by William Brown
Modified: 2013-10-07 13:43 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-10-07 13:43:52 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.