[refpolicy] Showing role attributes + issue when calling selinux utilities

[refpolicy] Showing role attributes + issue when calling selinux utilities

[Sven Vermeulen]

Hi guys,

Continuing the 20120215 release testing, I noticed that I can't call
run_init anymore:

  ~# run_init
  -bash: /usr/sbin/run_init: Permission denied

Same for newrole:

  ~# newrole -r sysadm_r
  -bash: /usr/bin/newrole: Permission denied

The denial is because of invalid context:

~# dmesg | tail -1
[ 6165.059146] type=1401 audit(1330261818.013:2712): security_compute_sid:
invalid context root:staff_r:newrole_t for scontext=root:staff_r:newrole_t
tcontext=root:staff_r:newrole_t tclass=unix_stream_socket

It looks that it has something to do with the role attribute support,
because seutil_run_runinit has changed between 20110726 and 20120215 to that
regard:

  ~$ ## 20110726 policy
  ~$ seshowif seutil_run_runinit
  interface(`seutil_run_runinit',`
          gen_require(`
                  type run_init_t;
                  role system_r;
          ')
  
          auth_run_chk_passwd(run_init_t, $2)
          seutil_domtrans_runinit($1)
          role $2 types run_init_t;
  
          allow $2 system_r;
  ')

  ~$ ## 20120215 policy
  $ seshowif seutil_run_runinit
  interface(`seutil_run_runinit',`
          gen_require(`
                  attribute_role run_init_roles;
          ')
  
          seutil_domtrans_runinit($1)
          roleattribute $2 run_init_roles;
  ')

Do I need to include "allow $2 system_r" again here?

Another question: is it possible to query the role attributes on the system?
seinfo only shows those for types...

Wkr,
	Sven Vermeulen

[refpolicy] Showing role attributes + issue when calling selinux utilities

[Sven Vermeulen]

On Sun, Feb 26, 2012 at 02:19:27PM +0100, Sven Vermeulen wrote:
> ~# dmesg | tail -1
> [ 6165.059146] type=1401 audit(1330261818.013:2712): security_compute_sid:
> invalid context root:staff_r:newrole_t for scontext=root:staff_r:newrole_t
> tcontext=root:staff_r:newrole_t tclass=unix_stream_socket
[...]
>           role $2 types run_init_t;
[...]
>           roleattribute $2 run_init_roles;


Looks like the issue is that there is nowhere a rule like so:

	role run_init_roles types run_init_t;

Adding that to the policy makes the tests go further. Same for

	role newrole_roles types newrole_t;

Wkr,
	Sven Vermeulen

[refpolicy] Showing role attributes + issue when calling selinux utilities

[Harry Ciao]

I am very glad finally someone else also discovered this issue. I had 
discovered it months ago and posted a patch to fix it, however, it had 
not been integrated or even acked.

Please search for my two emails entitled as "Make role attributes able 
to type their "own" types." sent around 2011-12-15 to the refpolicy 
mailing list.

Aside from new_roles and run_init_roles, some other role attributes such 
as groupadd_roles, useradd_roles and chfn_roles should have been able to 
type with their counterpart domains.

Thanks,
Harry


On 02/26/2012 09:19 PM, Sven Vermeulen wrote:
> Hi guys,
>
> Continuing the 20120215 release testing, I noticed that I can't call
> run_init anymore:
>
>    ~# run_init
>    -bash: /usr/sbin/run_init: Permission denied
>
> Same for newrole:
>
>    ~# newrole -r sysadm_r
>    -bash: /usr/bin/newrole: Permission denied
>
> The denial is because of invalid context:
>
> ~# dmesg | tail -1
> [ 6165.059146] type=1401 audit(1330261818.013:2712): security_compute_sid:
> invalid context root:staff_r:newrole_t for scontext=root:staff_r:newrole_t
> tcontext=root:staff_r:newrole_t tclass=unix_stream_socket
>
> It looks that it has something to do with the role attribute support,
> because seutil_run_runinit has changed between 20110726 and 20120215 to that
> regard:
>
>    ~$ ## 20110726 policy
>    ~$ seshowif seutil_run_runinit
>    interface(`seutil_run_runinit',`
>            gen_require(`
>                    type run_init_t;
>                    role system_r;
>            ')
>
>            auth_run_chk_passwd(run_init_t, $2)
>            seutil_domtrans_runinit($1)
>            role $2 types run_init_t;
>
>            allow $2 system_r;
>    ')
>
>    ~$ ## 20120215 policy
>    $ seshowif seutil_run_runinit
>    interface(`seutil_run_runinit',`
>            gen_require(`
>                    attribute_role run_init_roles;
>            ')
>
>            seutil_domtrans_runinit($1)
>            roleattribute $2 run_init_roles;
>    ')
>
> Do I need to include "allow $2 system_r" again here?
>
> Another question: is it possible to query the role attributes on the system?
> seinfo only shows those for types...
>
> Wkr,
> 	Sven Vermeulen
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>

[refpolicy] Showing role attributes + issue when calling selinux utilities

[Christopher J. PeBenito]

On 02/26/12 21:31, Harry Ciao wrote:
> I am very glad finally someone else also discovered this issue. I had 
> discovered it months ago and posted a patch to fix it, however, it had 
> not been integrated or even acked.
> 
> Please search for my two emails entitled as "Make role attributes able 
> to type their "own" types." sent around 2011-12-15 to the refpolicy 
> mailing list.
> 
> Aside from new_roles and run_init_roles, some other role attributes such 
> as groupadd_roles, useradd_roles and chfn_roles should have been able to 
> type with their counterpart domains.

Sorry I missed that patch.  I'll go get it.
 
> On 02/26/2012 09:19 PM, Sven Vermeulen wrote:
>> Hi guys,
>>
>> Continuing the 20120215 release testing, I noticed that I can't call
>> run_init anymore:
>>
>>    ~# run_init
>>    -bash: /usr/sbin/run_init: Permission denied
>>
>> Same for newrole:
>>
>>    ~# newrole -r sysadm_r
>>    -bash: /usr/bin/newrole: Permission denied
>>
>> The denial is because of invalid context:
>>
>> ~# dmesg | tail -1
>> [ 6165.059146] type=1401 audit(1330261818.013:2712): security_compute_sid:
>> invalid context root:staff_r:newrole_t for scontext=root:staff_r:newrole_t
>> tcontext=root:staff_r:newrole_t tclass=unix_stream_socket
>>
>> It looks that it has something to do with the role attribute support,
>> because seutil_run_runinit has changed between 20110726 and 20120215 to that
>> regard:
>>
>>    ~$ ## 20110726 policy
>>    ~$ seshowif seutil_run_runinit
>>    interface(`seutil_run_runinit',`
>>            gen_require(`
>>                    type run_init_t;
>>                    role system_r;
>>            ')
>>
>>            auth_run_chk_passwd(run_init_t, $2)
>>            seutil_domtrans_runinit($1)
>>            role $2 types run_init_t;
>>
>>            allow $2 system_r;
>>    ')
>>
>>    ~$ ## 20120215 policy
>>    $ seshowif seutil_run_runinit
>>    interface(`seutil_run_runinit',`
>>            gen_require(`
>>                    attribute_role run_init_roles;
>>            ')
>>
>>            seutil_domtrans_runinit($1)
>>            roleattribute $2 run_init_roles;
>>    ')
>>
>> Do I need to include "allow $2 system_r" again here?
>>
>> Another question: is it possible to query the role attributes on the system?
>> seinfo only shows those for types...
>>
>> Wkr,
>> 	Sven Vermeulen
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy at oss.tresys.com
>> http://oss.tresys.com/mailman/listinfo/refpolicy
>>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy


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

[refpolicy] Showing role attributes + issue when calling selinux utilities

[Harry Ciao]

No big deal, thank you Christ!

Have a good day!

Harry

On 02/27/2012 11:15 PM, Christopher J. PeBenito wrote:
> On 02/26/12 21:31, Harry Ciao wrote:
>> I am very glad finally someone else also discovered this issue. I had
>> discovered it months ago and posted a patch to fix it, however, it had
>> not been integrated or even acked.
>>
>> Please search for my two emails entitled as "Make role attributes able
>> to type their "own" types." sent around 2011-12-15 to the refpolicy
>> mailing list.
>>
>> Aside from new_roles and run_init_roles, some other role attributes such
>> as groupadd_roles, useradd_roles and chfn_roles should have been able to
>> type with their counterpart domains.
> Sorry I missed that patch.  I'll go get it.
>
>> On 02/26/2012 09:19 PM, Sven Vermeulen wrote:
>>> Hi guys,
>>>
>>> Continuing the 20120215 release testing, I noticed that I can't call
>>> run_init anymore:
>>>
>>>     ~# run_init
>>>     -bash: /usr/sbin/run_init: Permission denied
>>>
>>> Same for newrole:
>>>
>>>     ~# newrole -r sysadm_r
>>>     -bash: /usr/bin/newrole: Permission denied
>>>
>>> The denial is because of invalid context:
>>>
>>> ~# dmesg | tail -1
>>> [ 6165.059146] type=1401 audit(1330261818.013:2712): security_compute_sid:
>>> invalid context root:staff_r:newrole_t for scontext=root:staff_r:newrole_t
>>> tcontext=root:staff_r:newrole_t tclass=unix_stream_socket
>>>
>>> It looks that it has something to do with the role attribute support,
>>> because seutil_run_runinit has changed between 20110726 and 20120215 to that
>>> regard:
>>>
>>>     ~$ ## 20110726 policy
>>>     ~$ seshowif seutil_run_runinit
>>>     interface(`seutil_run_runinit',`
>>>             gen_require(`
>>>                     type run_init_t;
>>>                     role system_r;
>>>             ')
>>>
>>>             auth_run_chk_passwd(run_init_t, $2)
>>>             seutil_domtrans_runinit($1)
>>>             role $2 types run_init_t;
>>>
>>>             allow $2 system_r;
>>>     ')
>>>
>>>     ~$ ## 20120215 policy
>>>     $ seshowif seutil_run_runinit
>>>     interface(`seutil_run_runinit',`
>>>             gen_require(`
>>>                     attribute_role run_init_roles;
>>>             ')
>>>
>>>             seutil_domtrans_runinit($1)
>>>             roleattribute $2 run_init_roles;
>>>     ')
>>>
>>> Do I need to include "allow $2 system_r" again here?
>>>
>>> Another question: is it possible to query the role attributes on the system?
>>> seinfo only shows those for types...
>>>
>>> Wkr,
>>> 	Sven Vermeulen
>>> _______________________________________________
>>> refpolicy mailing list
>>> refpolicy at oss.tresys.com
>>> http://oss.tresys.com/mailman/listinfo/refpolicy
>>>
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy at oss.tresys.com
>> http://oss.tresys.com/mailman/listinfo/refpolicy
>