Red Hat Bugzilla – Bug 692296
MLS policy roles are more separate than with RHEL5
Last modified: 2012-08-08 14:29:11 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):
Steps to Reproduce:
For more information, see this mail thread:
Linda could you try to install this policy and see if it solves your problem.
Miroslav we could add this and wrap it with the same boolean that we had in RHEL5.
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.
try this local policy
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.
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.
BTW, I tried the policy from comment #6 and it worked for me in the little bit of testing I've done with it.
The problem is the most of rules which are needed
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.
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.
(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 :)
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.
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.
Ok, then I will make default the following
No I think we want that for MLS policy.
Yes, I mean these rules will be default without "ifndef(`enable_mls',`".
Fixed in selinux-policy-3.7.19-84.el6
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.