I'm trying to understand the RBAC features in the version of the mls
(and also strict) policies that ship with CentOS 5.6 - I'm not sure if
this is the best place to ask or if there's a more appropriate list.
Starting with the mls policy, and setting the secure_mode_loadpolicy
boolean to 'on' I then get that *neither* sysadm_r *nor* secadm_r can
issue commands such as setenforce. Yet userdomain.te contains the
following code:
ifdef(`strict_policy',`
[...]
optional_policy(`
seutil_run_restorecon(sysadm_t,sysadm_r,admin_terminal)
seutil_run_runinit(sysadm_t,sysadm_r,admin_terminal)
ifdef(`enable_mls',`
userdom_security_administrator(secadm_t,secadm_r,{ secadm_tty_device_t
sysadm_devpts_t })
# tunable_policy(`allow_sysadm_manage_security',`
userdom_security_administrator(sysadm_t,sysadm_r,admin_terminal)
# ')
', `
userdom_security_administrator(sysadm_t,sysadm_r,admin_terminal)
')
')
[...]
')
Now as far as I can see from the specfile the mls policy passes NAME=mls
TYPE=strict-mls to the makefile, and the makefile in turn defines
strict_policy and enable_mls in response to TYPE=strict-mls - and yet as
far as I can tell from running apol the actual binary policy in the
selinux-policy-mls RPM ends up not containing any TE rule to allow
sysadm_t or secadm_t to run setenforce - despite the fact that it would
appear that the userdom_security_administrator macro should appear to
expand into such rules.
What am I overlooking here?
Just out of interest, I then went and tried the strict policy. Yet this
policy doesn't even have a secadm_r and again I don't understand why.
The specfile builds it with NAME=strict TYPE=strict-mcs and from my
reading of the makefile an -mcs policy should again set enable_mls.
And kernel.ke continas the following, so I don't quite see why the
policy doesn't end up containing these roles.
ifdef(`enable_mls',`
role secadm_r;
role auditadm_r;
')
Any pointers to what I'm missing here would be appreciated.
Regards
Roy
--
Roy Badami
Roboreus Ltd
1 New Oxford Street
London WC1A 1NU
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
