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
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
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
>
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
http://www.tresys.com | oss.tresys.com
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
>