CentOS 5 RBAC

CentOS 5 RBAC

[Roy Badami]

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: CentOS 5 RBAC

[Stephen Smalley]

On Wed, 2011-08-31 at 18:01 +0100, Roy Badami wrote:
> 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.

secure_mode_policyload = 1 means "Don't allow any further policy
reloads, changing enforcing mode, or boolean changes (until next
reboot)."

The logic in selinux_set_enforce_mode() in
policy/modules/kernel/selinux.if is:
...
      if(!secure_mode_policyload) {
                allow $1 security_t:security setenforce;
...
}

Notice the logical negation (!) in the above if statement.  

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: CentOS 5 RBAC

[Stephen Smalley]

On Wed, 2011-08-31 at 18:01 +0100, Roy Badami wrote:
> 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;
> ')

At least in the policy sources I am looking at, a policy type that
includes the mcs suffix causes the policy to be built with -D
enable_mcs, not -D enable_mls.  Thus those roles don't get included in
the mcs policy.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: CentOS 5 RBAC

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 4671 bytes --]

On Wed, Aug 31, 2011 at 06:01:15PM +0100, Roy Badami wrote:
> 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.

refpolicy@oss.tresys.com is more appropriate.

> 
> 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)
>                 ')
>         ')
> [...]
> ')

When you build mls policy you get a seperate secadm role when you build strict policy then sysadm role also has the capabilities that secadm role in mls has. 

Not sure how thats done in el5 but currently its done like so: (sysadm.te:)

ifndef(`enable_mls',`
	userdom_security_admin_template(sysadm_t, sysadm_r)
')

meaning if enable_mls is not defined then allow sysadm_t to be security administrator.

secadm role only being in mls policy, is a decision made. probably related to confidentiality or some cerification requirement. i do not know.

As for securemode_policy_load boolean that is conditional policy e.g. when its set then caller is not allowed to "setbool", "load_policy" and "setenforce" (these are permission for the security class)

example (shortened for brevity)

	if(!secure_mode_policyload) {
		allow $1 security_t:security load_policy;
	}

if secure_module_policload is not defined then allow caller to load policy.

as for how come secadm_u is only available in mls i am not sure how but i bet part of it probablty could be that the module just is not installed (can be defined in modules.conf which modules to install)

but the mapping is specified in the users file:

gen_user(staff_u, staff, staff_r sysadm_r ifdef(`enable_mls',`secadm_r auditadm_r'), s0, s0 - mls_systemhigh, mcs_allcats)

basically saying if enable_mls is defined then map secadm_r and auditadm_r roles to staff_u. else not.

> 
> 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

probably a requirement for mls (certification) to have a seperate secadm_r and may not make much sense in strict. therefore sysadm_r also has the secadm capabilities in 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;
> ')

well whether the modules are installed (semodule -l | grep secadm) that i guess would be defined manually in the modules.conf for strict. if the secadm module is installed then it could be that the role is just not mapped to staff_u unless policy is mls ( see above: users file snippet)

> 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@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: CentOS 5 RBAC

[Roy Badami]

[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]

[Resending after accidentally dropping cc to the list]

On 31/08/2011 18:15, Stephen Smalley wrote:
> The logic in selinux_set_enforce_mode() in
> policy/modules/kernel/selinux.if is:
> ...
>        if(!secure_mode_policyload) {
>                  allow $1 security_t:security setenforce;
> ...
> }
>
> Notice the logical negation (!) in the above if statement.
>

Ah, thank you!  I had looked at those lines ealier, without fully 
understanding how the policy fitted together.  Indeed, I set  
secure_mode_policyload to 'on' based on that code to fix the fact that 
root could still run setenforce, even without changing role to 
secadm_r.  But unfortuantely, I see now, the reason root could run 
setenforce without changing to secadm_r is that root gets sysadm_r by 
default - and changing secure_mode_loadpolicy prevents *both* sysadm_r 
*and* secadm_r from administering policy - which wasn't what I was 
trying to achieve.

                 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)
#                       ')

If the allow_sysadm_manage_security boolean was implemented in this 
policy then I could simply set that to 'off'.   Given it's not - what's 
the best way to grant this permission to secadm_r only?  Presumably I 
want to set secure_mode_loadpolicy to 'on' as now so that the shipped 
policy doesn't give permissions, and then load some custom TE rules to 
add the necessary permissions for secadm_r to administer security policy?

Regards

roy




-- 
Roy Badami
Roboreus Ltd
1 New Oxford Street
London WC1A 1NU


[-- Attachment #2: Type: text/html, Size: 3409 bytes --]

Re: CentOS 5 RBAC

[Roy Badami]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

On 31/08/2011 18:24, Stephen Smalley wrote:
>
> At least in the policy sources I am looking at, a policy type that
> includes the mcs suffix causes the policy to be built with -D
> enable_mcs, not -D enable_mls.  Thus those roles don't get included in
> the mcs policy.
>

Yes, you're right - clearly I need glasses :-)

-- 
Roy Badami
Roboreus Ltd
1 New Oxford Street
London WC1A 1NU


[-- Attachment #2: Type: text/html, Size: 1263 bytes --]

Re: CentOS 5 RBAC

[Roy Badami]

On 31/08/2011 18:48, Dominick Grift wrote:
> On Wed, Aug 31, 2011 at 06:01:15PM +0100, Roy Badami wrote:
>> 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.
> refpolicy@oss.tresys.com is more appropriate.

Thanks - I'll bear that one in mind.
>
> When you build mls policy you get a seperate secadm role when you build strict policy then sysadm role also has the capabilities that secadm role in mls has.

Yes, so looks like it does makes sense for me to use the mls policy in 
that case.  Unfortunately in the mls policy on el5 it appears that both 
sysadm_r and secadm_r can both administer security.  secadm_r is 
preveneted from performing other systems administration, but 
unfortunately sysadm_r is not prevented from changint the selinux 
policy, etc.  This wasn't how I was hoping it would work :-(

>
> well whether the modules are installed (semodule -l | grep secadm) that i guess would be defined manually in the modules.conf for strict. if the secadm module is installed then it could be that the role is just not mapped to staff_u unless policy is mls ( see above: users file snippet)
Ah, I'd been trying to figure out how to verify what modules really were 
present in the loaded binary policy - that's very useful, thanks!  As as 
your other pointers to bits of the policy.

Regards

roy

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: CentOS 5 RBAC

[Stephen Smalley]

On Wed, 2011-08-31 at 19:03 +0100, Roy Badami wrote:

> If the allow_sysadm_manage_security boolean was implemented in this
> policy then I could simply set that to 'off'.   Given it's not -
> what's the best way to grant this permission to secadm_r only?
> Presumably I want to set secure_mode_loadpolicy to 'on' as now so that
> the shipped policy doesn't give permissions, and then load some custom
> TE rules to add the necessary permissions for secadm_r to administer
> security policy? 

I think that would work and avoid the need to modify/rebuild the
existing policy.

However, be aware that the sysadm vs secadm distinction is largely
illusory even if you do this.  See this thread for further discussion:
http://marc.info/?t=105457894700002&r=1&w=2

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: CentOS 5 RBAC

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 2218 bytes --]

On Wed, Aug 31, 2011 at 07:14:42PM +0100, Roy Badami wrote:
> On 31/08/2011 18:48, Dominick Grift wrote:
> >On Wed, Aug 31, 2011 at 06:01:15PM +0100, Roy Badami wrote:
> >>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.
> >refpolicy@oss.tresys.com is more appropriate.
> 
> Thanks - I'll bear that one in mind.
> >
> >When you build mls policy you get a seperate secadm role when you build strict policy then sysadm role also has the capabilities that secadm role in mls has.
> 
> Yes, so looks like it does makes sense for me to use the mls policy
> in that case.  Unfortunately in the mls policy on el5 it appears
> that both sysadm_r and secadm_r can both administer security.
> secadm_r is preveneted from performing other systems administration,
> but unfortunately sysadm_r is not prevented from changint the
> selinux policy, etc.  This wasn't how I was hoping it would work :-(
> 
> >
> >well whether the modules are installed (semodule -l | grep secadm) that i guess would be defined manually in the modules.conf for strict. if the secadm module is installed then it could be that the role is just not mapped to staff_u unless policy is mls ( see above: users file snippet)
> Ah, I'd been trying to figure out how to verify what modules really
> were present in the loaded binary policy - that's very useful,
> thanks!  As as your other pointers to bits of the policy.

Well its just an indicator. Some ( core? ) modules are compiled in a single base module, which isnt listed in semodule -l. In a perfect world that would be only about 10 modules or so ( the ones in the kernel layer ) however people have been using the base module as a refuge to hide their broken policy ;)

So most modules should be listed with semodule -l, only few arent listed because they are in base. Which modules exactly are in base is harder to tell. ( you could download the policy source rpm. extract it and look into the enclosed modules-mls.conf file. grep -i it for base. (example: kernel = base)
> 
> Regards
> 
> roy

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: CentOS 5 RBAC

[Stephen Smalley]

On Wed, 2011-08-31 at 14:23 -0400, Stephen Smalley wrote:
> On Wed, 2011-08-31 at 19:03 +0100, Roy Badami wrote:
> 
> > If the allow_sysadm_manage_security boolean was implemented in this
> > policy then I could simply set that to 'off'.   Given it's not -
> > what's the best way to grant this permission to secadm_r only?
> > Presumably I want to set secure_mode_loadpolicy to 'on' as now so that
> > the shipped policy doesn't give permissions, and then load some custom
> > TE rules to add the necessary permissions for secadm_r to administer
> > security policy? 
> 
> I think that would work and avoid the need to modify/rebuild the
> existing policy.
> 
> However, be aware that the sysadm vs secadm distinction is largely
> illusory even if you do this.  See this thread for further discussion:
> http://marc.info/?t=105457894700002&r=1&w=2

BTW, if you're looking to further harden your setup, you might want to
have a look at CLIP,
http://oss.tresys.com/projects/clip

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: CentOS 5 RBAC

[Roy Badami]

> I think that would work and avoid the need to modify/rebuild the
> existing policy.
>
> However, be aware that the sysadm vs secadm distinction is largely
> illusory even if you do this.  See this thread for further discussion:
> http://marc.info/?t=105457894700002&r=1&w=2
>

Any idea what it is that gives sysadm_t write access to 
selinux_config_t:file ?

I can see the rule when I opne the binary policy in apol but I haven't 
had much luck tracking down where it comes from in the policy source.


-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: CentOS 5 RBAC

[Christopher J. PeBenito]

On 09/02/11 07:37, Roy Badami wrote:
> 
>> I think that would work and avoid the need to modify/rebuild the
>> existing policy.
>>
>> However, be aware that the sysadm vs secadm distinction is largely
>> illusory even if you do this.  See this thread for further discussion:
>> http://marc.info/?t=105457894700002&r=1&w=2
>>
> 
> Any idea what it is that gives sysadm_t write access to selinux_config_t:file ?
> 
> I can see the rule when I opne the binary policy in apol but I haven't had much luck tracking down where it comes from in the policy source.

The auth_manage_all_files_except_shadow() call in userdom_admin_user_template().

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: CentOS 5 RBAC

[Roy Badami]

>> Any idea what it is that gives sysadm_t write access to selinux_config_t:file ?
>>
>> I can see the rule when I opne the binary policy in apol but I haven't had much luck tracking down where it comes from in the policy source.
> The auth_manage_all_files_except_shadow() call in userdom_admin_user_template().
>

Ah, thank you!  I would never have found that on my own, given the 
number of macros and attributes that everything indirects through!

So I'm beginning to realise that sysadm_r is probably the wrong starting 
point for me.  I think what I really want to be doing is probably 
creating a new 'limited admin' role (perhaps based on staff_r) and 
adding in only those permissions the role actually needs.

Thanks again,

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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: CentOS 5 RBAC

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 1597 bytes --]

On Fri, Sep 02, 2011 at 02:49:26PM +0100, Roy Badami wrote:
> 
> >>Any idea what it is that gives sysadm_t write access to selinux_config_t:file ?
> >>
> >>I can see the rule when I opne the binary policy in apol but I haven't had much luck tracking down where it comes from in the policy source.
> >The auth_manage_all_files_except_shadow() call in userdom_admin_user_template().
> >
> 
> Ah, thank you!  I would never have found that on my own, given the
> number of macros and attributes that everything indirects through!
> 
> So I'm beginning to realise that sysadm_r is probably the wrong
> starting point for me.  I think what I really want to be doing is
> probably creating a new 'limited admin' role (perhaps based on
> staff_r) and adding in only those permissions the role actually
> needs.

You could create a new role based off of the userdom_base_user_template, and then map this newly created role to the staff_u user. So that staff_u can newrole to the "new role". Then just tailor the role to your requirements.

A key property of the "base_user_template" is that this is not a login user template. So the role can only be access through newrole/su. The new role cannot interact with user home directories.
> 
> Thanks again,
> 
> 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@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]