Bug 1285294 - reconsider allowing type "domain" to read all "base_ro_file_type"
reconsider allowing type "domain" to read all "base_ro_file_type"
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy (Show other bugs)
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Miroslav Grepl
Milos Malik
Depends On:
  Show dependency treegraph
Reported: 2015-11-25 06:22 EST by redhat-airlock
Modified: 2016-06-28 03:01 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-06-28 03:01:44 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description redhat-airlock 2015-11-25 06:22:32 EST
Description of problem:
We are using SELinux to contain processes with least privilege access to the OS file system. All this processes run as a (domain) type which is included in the "domain" attribute, as it is good practice for every domain type. After the update from RHEL 6.6 to 6.7 we saw that our processes are able to read files and directories labeled with "bin_t" (and other). The reason is that a directive was added to allow the attribute "domain" to read all files labeled as "base_ro_file_type":

problematic directives, added with policy-RHEL6.7-e2506.patch
   allow domain base_ro_file_type : file { ioctl read getattr lock open } ; 
   allow domain base_ro_file_type : dir { ioctl read getattr lock search open } ; 

"base_ro_file_type" consists of many common resource types like bin_t, etc_t, usr_t, system_conf_t, this allows all processes to examine a large part of the OS file system, what we consider as a decrease in security.
Our problem now is, since the directive adds these permissions to the "root" attribute "domain" it is not possible to create a domain type that does not have this privileges. In our mind this privileges should have been given to a sub attribute/type of "domain" and not "domain" itself.

Version-Release number of selected component (if applicable): 

How reproducible:
compare results between 6.6 and 6.7
sesearch --allow -s domain -t bin_t -p read | grep "allow domain"

Actual results:
   allow domain base_ro_file_type : file { ioctl read getattr lock open } ; 
   allow domain base_ro_file_type : dir { ioctl read getattr lock search open } ; 
   allow domain base_ro_file_type : lnk_file { read getattr } ;

Expected results:

Additional info:
Comment 2 Daniel Walsh 2015-12-01 15:44:20 EST
Maybe add a boolean for this defaulted to true. And then advanced users could turn it off.
Comment 3 Frank Meier 2015-12-07 04:58:31 EST
Since it is hard to tell, which parts of the system (will) rely on the boolean being true. A later disablement will most likely break these parts. 
A "clean" solution would be to introduce a separate domain attribute which has the privileges to read the "base_ro_file_type". And then all the domain types relying on said read permission would have to be added to this new domain attribute.
But I know, asking for this would mean quite a big change to your policy as it is now. What could also easily break some stuff.
Comment 4 Miroslav Grepl 2015-12-08 06:23:52 EST
We back ported it from RHEL-7 because lot of random domains wanted to access these readable files with contexts which you mentioned. I don't see any real flaws here. We can not do it with a boolean due to policy language. 

Thinking about introducing a new domain which could just add additional complexity to the current complex policy. There is a way to label intended files by a type which is not base_ro.
Comment 5 Daniel Walsh 2015-12-09 14:45:18 EST
Yes if you want to protect executable/files that should not be readable by all domains, then add a type for them. 

They should not be bin_t, usr_t, etc_t, lib_t ...
Comment 6 Miroslav Grepl 2016-06-28 03:01:44 EDT
Closing this bug as WONTFIX based on our previous comments - #4 and #5.

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