Bug 692296

Summary: MLS policy roles are more separate than with RHEL5
Product: Red Hat Enterprise Linux 6 Reporter: Linda Knippers <linda.knippers>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED ERRATA QA Contact: Karel Srot <ksrot>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.1CC: borgan, dwalsh, ebenes, ksrot, mmalik, sgrubb
Target Milestone: rcKeywords: Regression, Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: selinux-policy-3.7.19-84.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-19 08:27:07 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 584498, 846801, 846802    

Description Linda Knippers 2011-03-30 20:11:00 EDT
Description of problem:

With the MLS policy on RHEL5, the sysadm_r role could do everything that the 
secadm_r and auditadm_r roles could do.  This was done because having strict separation between sysadm and the other roles made it difficult to do things 
like add users.  Also, the separation between sysadm and secadm seemed rather
arbitrary (sysadm can change the TE part of a security context but not the
mls level) so before RHEL5 shipped, sysadm was given all the secadm and auditadm

With the new policy in RHEL6, the strict separation is back, which means
that the previous problems are back.  Can we put the role definitions
back like they were for RHEL5?

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

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
For more information, see this mail thread:
Comment 2 Daniel Walsh 2011-03-31 10:11:12 EDT
Linda could you try to install this policy and see if it solves your problem.

policy_module(mysysadm, 1.0)
type sysadm_t;
role sysadm_r;
userdom_security_admin_template(sysadm_t, sysadm_r)
Comment 3 Daniel Walsh 2011-03-31 10:12:40 EDT
Miroslav we could add this and wrap it with the same boolean that we had in RHEL5.
Comment 5 Linda Knippers 2011-04-04 17:35:43 EDT
Dan, sorry it took me so long to get back to you. 

Some simple testing indicates that the policy module in #2 gives sysadm_r the permissions for secadm_r but we still can't do auditadm_r operations, so its still not quite like RHEL5.
Comment 6 Miroslav Grepl 2011-04-05 07:06:09 EDT
try this local policy

policy_module(mysysadm, 1.0)
type sysadm_t;
role sysadm_r;

userdom_security_admin_template(sysadm_t, sysadm_r)

logging_run_auditctl(sysadm_t, sysadm_r)
logging_run_auditd(sysadm_t, sysadm_r)
Comment 7 Miroslav Grepl 2011-04-06 03:53:51 EDT
This is allowed by default in RHEL5. There is no boolean since these rules can not be applied using a boolean.

I am closing this bug as WONTFIX. We do not want to make this default for MLS policy in RHEL6.
Comment 8 Linda Knippers 2011-04-06 12:32:26 EDT
If you don't want to make it the default (not sure why since it was the default for RHEL5) then how about an option policy module that can be applied?

I don't know who your users are but if anyone is actually using the RHEL5 MLS policy, this change in behavior will likely break them.

I'd like to have a little more discussion before closing this bug.
Comment 9 Linda Knippers 2011-04-06 12:35:04 EDT
BTW, I tried the policy from comment #6 and it worked for me in the little bit of testing I've done with it.
Comment 10 Miroslav Grepl 2011-04-07 05:17:27 EDT
The problem is the most of rules which are needed

        logging_run_auditctl(sysadm_t, sysadm_r)
        logging_run_auditd(sysadm_t, sysadm_r)


can not be used with "tunable_policy" declaration. Other methods of declaration allow it by default.

I believe we should keep the seperation between these roles in RHEL6 (sysadm_r, secadm_r, auditadm_r). And the newrole command should be used for switching between roles.

But, you are right,  let's discuss it more.

what is your opinion.
Comment 11 Daniel Walsh 2011-04-07 09:55:46 EDT
I dissagree, just allow sysadm_t to do the access.  If we decide we want a weaker admin role we can add that.  But lets make this default to being able to do everything an admin can do.
Comment 12 Eduard Benes 2011-04-07 10:57:03 EDT
(In reply to comment #11)
> I dissagree, just allow sysadm_t to do the access.  If we decide we want a
> weaker admin role we can add that.  But lets make this default to being able to
> do everything an admin can do.

Does it mean all abilities of secadm_r, auditadm_r will be merged into sysadm_r?
I believe the strict separation is good to have with confined users feature, though it makes testing really painful. And, as I was told several times before, MLS isn't supposed to be user friendly :)
Comment 13 Linda Knippers 2011-04-07 11:08:59 EDT
I'm more concerned about the change in behavior from RHEL5, not its user friendliness.  If RHEL5 customers use the mls policy, the RHEL6 policy may break them.
Comment 14 Daniel Walsh 2011-04-07 11:36:50 EDT
You still have the user separation, and you still have auditadm_r and secadm_t.  It is just that sysadm_t has everything that auditadm_t and secadm_t can do.
Which is what the goal was in RHEL5.  If you want separation between a admin and secadm_t, you can fairly easily create myadm_t.  Writing policy for confined users/admins in RHEL6 is vastly easier (not easy) then in RHEL5.

I also think this is justified to not break the RHEL5 mode without a decent justification.
Comment 15 Miroslav Grepl 2011-04-08 01:36:20 EDT
Ok, then I will make default the following

    userdom_security_admin_template(sysadm_t, sysadm_r)

    logging_run_auditctl(sysadm_t, sysadm_r)
Comment 16 Daniel Walsh 2011-04-08 14:27:15 EDT
No I think we want that for MLS policy.
Comment 17 Miroslav Grepl 2011-04-08 15:34:40 EDT
Yes, I mean these rules will be default without "ifndef(`enable_mls',`".
Comment 18 Miroslav Grepl 2011-04-11 06:14:06 EDT
Fixed in selinux-policy-3.7.19-84.el6
Comment 21 errata-xmlrpc 2011-05-19 08:27:07 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.