[refpolicy] RFC: direct_init_entry breaks direct_initrc

[refpolicy] RFC: direct_init_entry breaks direct_initrc

[Dominick Grift]

I have not tested this yet and it is a theory

I was not there when that type attribute was implemented so i do not
know the rationale behind the decision to implement it.

Would be nice if anyone could shed some light on that and would be even
better if this fix is acknowledged

> From fc51afbd178dd6321f51d54939e73b1a94172fb9 Tue, 10 Dec 2013 16:53:08 +0100
> From: Dominick Grift <dominick.grift@gmail.com>
> Date: Tue, 10 Dec 2013 16:51:46 +0100
> Subject: [PATCH] Get rid of direct_init_entry:
> 
> 
> This thing breaks direct_initrc
> 
> This type attribute was associated to domain entry files and used for
> role transitions to system_r
> 
> The transition shouldnt happem on the domain entry file though it should
> happen on the init script executable files
> 
> This was breaking direct_initrc because some executables can be run as
> system service and session service. By using the domain entry file init
> the init_daemon_domain interface and associating direct init entry with
> it and using direct init entry for the role transitions you force
> daemons to use system_r whether they are system or session daemon.
> 
> 
> 
> 
> Signed-off-by: Dominick Grift <dominick.grift@gmail.com>
> diff --git a/policy/modules/system/init.if b/policy/modules/system/init.if
> index 79a45f6..5a7df5e 100644
> --- a/policy/modules/system/init.if
> +++ b/policy/modules/system/init.if
> @@ -191,7 +191,7 @@
>  #
>  interface(`init_daemon_domain',`
>  	gen_require(`
> -		attribute direct_run_init, direct_init, direct_init_entry;
> +		attribute direct_run_init, direct_init;
>  		type initrc_t;
>  		role system_r;
>  		attribute daemon;
> @@ -220,7 +220,6 @@
>  		allow direct_run_init $1:process { noatsecure siginh rlimitinh };
>  
>  		typeattribute $1 direct_init;
> -		typeattribute $2 direct_init_entry;
>  
>  		userdom_dontaudit_use_user_terminals($1)
>  	')
> @@ -982,12 +981,12 @@
>  #
>  interface(`init_run_daemon',`
>  	gen_require(`
> -		attribute direct_run_init, direct_init, direct_init_entry;
> +		attribute direct_run_init, init_script_file_type;
>  		role system_r;
>  	')
>  
>  	typeattribute $1 direct_run_init;
> -	role_transition $2 direct_init_entry system_r;
> +	role_transition $2 init_script_file_type system_r;
>  ')
>  
>  ########################################
> diff --git a/policy/modules/system/init.te b/policy/modules/system/init.te
> index d9d9f5d..116e37a 100644
> --- a/policy/modules/system/init.te
> +++ b/policy/modules/system/init.te
> @@ -27,7 +27,6 @@
>  # by admin domains
>  attribute direct_run_init;
>  attribute direct_init;
> -attribute direct_init_entry;
>  
>  attribute init_script_domain_type;
>  attribute init_script_file_type;

[refpolicy] RFC: direct_init_entry breaks direct_initrc

[Dominick Grift]

On Tue, 2013-12-10 at 16:57 +0100, Dominick Grift wrote:

> >  
> >  		typeattribute $1 direct_init;
> > -		typeattribute $2 direct_init_entry;

Here its actually associated with the init daemon entry file. That is
wrong in my view. The role transition should happen on the init script
not the daemon entry file

> > -	role_transition $2 direct_init_entry system_r;
> > +	role_transition $2 init_script_file_type system_r;

Here is that actual role transition. This is causing problems with
direct_initrc. role transition to system_r should happen on the init
script and not the init daemon executable file

[refpolicy] RFC: direct_init_entry breaks direct_initrc

[Christopher J. PeBenito]

On 12/10/13 10:57, Dominick Grift wrote:
> I have not tested this yet and it is a theory
> 
> I was not there when that type attribute was implemented so i do not
> know the rationale behind the decision to implement it.
> 
> Would be nice if anyone could shed some light on that and would be even
> better if this fix is acknowledged

It seems like it would probably work, but definitely needs to be tested.


>> From fc51afbd178dd6321f51d54939e73b1a94172fb9 Tue, 10 Dec 2013 16:53:08 +0100
>> From: Dominick Grift <dominick.grift@gmail.com>
>> Date: Tue, 10 Dec 2013 16:51:46 +0100
>> Subject: [PATCH] Get rid of direct_init_entry:
>>
>>
>> This thing breaks direct_initrc
>>
>> This type attribute was associated to domain entry files and used for
>> role transitions to system_r
>>
>> The transition shouldnt happem on the domain entry file though it should
>> happen on the init script executable files
>>
>> This was breaking direct_initrc because some executables can be run as
>> system service and session service. By using the domain entry file init
>> the init_daemon_domain interface and associating direct init entry with
>> it and using direct init entry for the role transitions you force
>> daemons to use system_r whether they are system or session daemon.
>>
>>
>>
>>
>> Signed-off-by: Dominick Grift <dominick.grift@gmail.com>
>> diff --git a/policy/modules/system/init.if b/policy/modules/system/init.if
>> index 79a45f6..5a7df5e 100644
>> --- a/policy/modules/system/init.if
>> +++ b/policy/modules/system/init.if
>> @@ -191,7 +191,7 @@
>>  #
>>  interface(`init_daemon_domain',`
>>  	gen_require(`
>> -		attribute direct_run_init, direct_init, direct_init_entry;
>> +		attribute direct_run_init, direct_init;
>>  		type initrc_t;
>>  		role system_r;
>>  		attribute daemon;
>> @@ -220,7 +220,6 @@
>>  		allow direct_run_init $1:process { noatsecure siginh rlimitinh };
>>  
>>  		typeattribute $1 direct_init;
>> -		typeattribute $2 direct_init_entry;
>>  
>>  		userdom_dontaudit_use_user_terminals($1)
>>  	')
>> @@ -982,12 +981,12 @@
>>  #
>>  interface(`init_run_daemon',`
>>  	gen_require(`
>> -		attribute direct_run_init, direct_init, direct_init_entry;
>> +		attribute direct_run_init, init_script_file_type;
>>  		role system_r;
>>  	')
>>  
>>  	typeattribute $1 direct_run_init;
>> -	role_transition $2 direct_init_entry system_r;
>> +	role_transition $2 init_script_file_type system_r;
>>  ')
>>  
>>  ########################################
>> diff --git a/policy/modules/system/init.te b/policy/modules/system/init.te
>> index d9d9f5d..116e37a 100644
>> --- a/policy/modules/system/init.te
>> +++ b/policy/modules/system/init.te
>> @@ -27,7 +27,6 @@
>>  # by admin domains
>>  attribute direct_run_init;
>>  attribute direct_init;
>> -attribute direct_init_entry;
>>  
>>  attribute init_script_domain_type;
>>  attribute init_script_file_type;
> 
> _______________________________________________
> 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] RFC: direct_init_entry breaks direct_initrc

[Dominick Grift]

On Tue, 2014-01-14 at 08:56 -0500, Christopher J. PeBenito wrote:
> On 12/10/13 10:57, Dominick Grift wrote:
> > I have not tested this yet and it is a theory
> > 
> > I was not there when that type attribute was implemented so i do not
> > know the rationale behind the decision to implement it.
> > 
> > Would be nice if anyone could shed some light on that and would be even
> > better if this fix is acknowledged
> 
> It seems like it would probably work, but definitely needs to be tested.
> 

I have tested it. role transitions should happen on the init script and
now on the daemon entry file. This is a bug in the init_run_daemon
interface and it breaks a lot of stuff

Also the init_run_daemon(unconfined_t, unconfined_r) should be make
tunable (direct_sysadm_daemon)

Removing the init_run_daemon(unconfined_t, unconfined_r) like fedora did
does not solve anything in any sustainable way.

I doubt that unconfined_t role transitions at all without that interface
call so you'd end up with: unconfined_u:unconfined_r:daemon_t instead of
unconfined_u:system_r:daemon_t

[refpolicy] RFC: direct_init_entry breaks direct_initrc

[Christopher J. PeBenito]

On Tue Jan 14 09:02:08 2014, Dominick Grift wrote:
> On Tue, 2014-01-14 at 08:56 -0500, Christopher J. PeBenito wrote:
>> On 12/10/13 10:57, Dominick Grift wrote:
>>> I have not tested this yet and it is a theory
>>>
>>> I was not there when that type attribute was implemented so i do not
>>> know the rationale behind the decision to implement it.
>>>
>>> Would be nice if anyone could shed some light on that and would be even
>>> better if this fix is acknowledged
>>
>> It seems like it would probably work, but definitely needs to be tested.
>>
>
> I have tested it. role transitions should happen on the init script and
> now on the daemon entry file. This is a bug in the init_run_daemon
> interface and it breaks a lot of stuff
>
> Also the init_run_daemon(unconfined_t, unconfined_r) should be make
> tunable (direct_sysadm_daemon)

Would you send patches for these?  The first patch I only see as 
inlined comments in the body of the first message.

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

[refpolicy] RFC: direct_init_entry breaks direct_initrc

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/14/2014 09:10 AM, Christopher J. PeBenito wrote:
> On Tue Jan 14 09:02:08 2014, Dominick Grift wrote:
>> On Tue, 2014-01-14 at 08:56 -0500, Christopher J. PeBenito wrote:
>>> On 12/10/13 10:57, Dominick Grift wrote:
>>>> I have not tested this yet and it is a theory
>>>> 
>>>> I was not there when that type attribute was implemented so i do not 
>>>> know the rationale behind the decision to implement it.
>>>> 
>>>> Would be nice if anyone could shed some light on that and would be
>>>> even better if this fix is acknowledged
>>> 
>>> It seems like it would probably work, but definitely needs to be
>>> tested.
>>> 
>> 
>> I have tested it. role transitions should happen on the init script and 
>> now on the daemon entry file. This is a bug in the init_run_daemon 
>> interface and it breaks a lot of stuff
>> 
>> Also the init_run_daemon(unconfined_t, unconfined_r) should be make 
>> tunable (direct_sysadm_daemon)
> 
> Would you send patches for these?  The first patch I only see as inlined
> comments in the body of the first message.
> 
> -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com 
> _______________________________________________ refpolicy mailing list 
> refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy
> 


Well Fedora still does the transition since we have an interface

init_script_role_transition(unconfined_r)


+interface(`init_script_role_transition',`
+       gen_require(`
+               attribute init_script_file_type;
+       ')
+
+       role_transition $1 init_script_file_type system_r;
+')


But I am fine with Dominick's change.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLVTjYACgkQrlYvE4MpobPAzACgjshCRnUkzgdNjyjcxqwDp4Zv
lkoAoLZZ167ZBWx+eBlvYdCa5ZoHfwYN
=4l0D
-----END PGP SIGNATURE-----

[refpolicy] RFC: direct_init_entry breaks direct_initrc

[Dominick Grift]

On Tue, 2014-01-14 at 09:10 -0500, Christopher J. PeBenito wrote:
> On Tue Jan 14 09:02:08 2014, Dominick Grift wrote:
> > On Tue, 2014-01-14 at 08:56 -0500, Christopher J. PeBenito wrote:
> >> On 12/10/13 10:57, Dominick Grift wrote:
> >>> I have not tested this yet and it is a theory
> >>>
> >>> I was not there when that type attribute was implemented so i do not
> >>> know the rationale behind the decision to implement it.
> >>>
> >>> Would be nice if anyone could shed some light on that and would be even
> >>> better if this fix is acknowledged
> >>
> >> It seems like it would probably work, but definitely needs to be tested.
> >>
> >
> > I have tested it. role transitions should happen on the init script and
> > now on the daemon entry file. This is a bug in the init_run_daemon
> > interface and it breaks a lot of stuff
> >
> > Also the init_run_daemon(unconfined_t, unconfined_r) should be make
> > tunable (direct_sysadm_daemon)
> 
> Would you send patches for these?  The first patch I only see as 
> inlined comments in the body of the first message.

Unfortunately i found some other issue during rebasing.

Not only do callers of init_run_daemon() role transition on daemon
executable files instead of init scripts. They turn out to be also
domain transitioning on executable files instead of init scripts.

(so sysadm_t seems to actually run init scripts in the sysadm_t domain
(with direct_initrc=y) (unless i overlooked something)

My previous patches do work and fix many issues but it is not the fix i
was hoping for (i guess i had not tested it enough after all)

Enclosed you will find the rebased patch , and although it builds i have
not been able to test it yet. I need to test this on debian because
Fedora has diverged a lot from refpolicy, is using systemd. I can't test
it on rhel either since that also diverged a lot from refpolicy and
refpolicy probably does not install on el6 due to old user space (does
not support named file transition for one)

I am planning to test this on debian, but for now i just post the patch
for review/comments.

I can't add the patch in-line because git-send-email is broken in my
Fedora

See attachment:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Previously-callers-of-initrundaemon-role-type-transi.patch
Type: text/x-patch
Size: 4940 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20140114/ed243500/attachment.bin 

[refpolicy] RFC: direct_init_entry breaks direct_initrc

[Christopher J. PeBenito]

On 01/14/14 13:30, Dominick Grift wrote:
> On Tue, 2014-01-14 at 09:10 -0500, Christopher J. PeBenito wrote:
>> On Tue Jan 14 09:02:08 2014, Dominick Grift wrote:
>>> On Tue, 2014-01-14 at 08:56 -0500, Christopher J. PeBenito wrote:
>>>> On 12/10/13 10:57, Dominick Grift wrote:
>>>>> I have not tested this yet and it is a theory
>>>>>
>>>>> I was not there when that type attribute was implemented so i do not
>>>>> know the rationale behind the decision to implement it.
>>>>>
>>>>> Would be nice if anyone could shed some light on that and would be even
>>>>> better if this fix is acknowledged
>>>>
>>>> It seems like it would probably work, but definitely needs to be tested.
>>>>
>>>
>>> I have tested it. role transitions should happen on the init script and
>>> now on the daemon entry file. This is a bug in the init_run_daemon
>>> interface and it breaks a lot of stuff
>>>
>>> Also the init_run_daemon(unconfined_t, unconfined_r) should be make
>>> tunable (direct_sysadm_daemon)
>>
>> Would you send patches for these?  The first patch I only see as 
>> inlined comments in the body of the first message.
> 
> Unfortunately i found some other issue during rebasing.
> 
> Not only do callers of init_run_daemon() role transition on daemon
> executable files instead of init scripts. They turn out to be also
> domain transitioning on executable files instead of init scripts.
> 
> (so sysadm_t seems to actually run init scripts in the sysadm_t domain
> (with direct_initrc=y) (unless i overlooked something)
> 
> My previous patches do work and fix many issues but it is not the fix i
> was hoping for (i guess i had not tested it enough after all)
> 
> Enclosed you will find the rebased patch , and although it builds i have
> not been able to test it yet. I need to test this on debian because
> Fedora has diverged a lot from refpolicy, is using systemd. I can't test
> it on rhel either since that also diverged a lot from refpolicy and
> refpolicy probably does not install on el6 due to old user space (does
> not support named file transition for one)
> 
> I am planning to test this on debian, but for now i just post the patch
> for review/comments.

I think you may be able to drop the direct_run_init attribute and put the domtrans you added in the init_run_daemon() interface instead.

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

[refpolicy] RFC: direct_init_entry breaks direct_initrc

[Dominick Grift]

On Tue, 2014-01-14 at 15:44 -0500, Christopher J. PeBenito wrote:
> 
> I think you may be able to drop the direct_run_init attribute and put the domtrans you added in the init_run_daemon() interface instead.
> 

Right, i also got rid of direct_init because was a lose end as well

It builds but still not actually tested

Enclosed i another try:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Fix-directinitrc-and-make-it-also-apply-to-unconfine.patch
Type: text/x-patch
Size: 4791 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20140114/0dc288b5/attachment.bin 

[refpolicy] RFC: direct_init_entry breaks direct_initrc

[Dominick Grift]

On Tue, 2014-01-14 at 23:23 +0100, Dominick Grift wrote:
> On Tue, 2014-01-14 at 15:44 -0500, Christopher J. PeBenito wrote:
> > 
> > I think you may be able to drop the direct_run_init attribute and put the domtrans you added in the init_run_daemon() interface instead.
> > 
> 
> Right, i also got rid of direct_init because was a lose end as well
> 
> It builds but still not actually tested
> 
> Enclosed i another try:
> 

Today i (pretty thoroughly) tested this patch to the extend possible on
Fedora 20, all tests i did ran 100 percent OK

I can't be sure though that i haven't over looked anything because
sometimes i have a hard time reading Fedora policy and understanding
some of the decisions made with regard to init.

I recorded the whole implementation and testing session for reference
purposes and sent it to youtube (the fedora patch i used is in the video
description)

https://www.youtube.com/watch?v=9bIU_Ga3ss4


Might be an interesting video for people who want to learn more about
the work flow of testing modified fedora policy (or other packages)

I havent tested it on Debian yet but i am confident that this works

[refpolicy] RFC: direct_init_entry breaks direct_initrc

[Christopher J. PeBenito]

On 01/14/14 17:23, Dominick Grift wrote:
> On Tue, 2014-01-14 at 15:44 -0500, Christopher J. PeBenito wrote:
>>
>> I think you may be able to drop the direct_run_init attribute and put the domtrans you added in the init_run_daemon() interface instead.
>>
> 
> Right, i also got rid of direct_init because was a lose end as well
> 
> It builds but still not actually tested

On further looking it looks like we shouldn't completely remove the direct_sysadm_daemon block out of init_daemon_domain; the userdom_dontaudit_use_user_terminals($1) should probably remain.  I'd also prefer to separate the unconfined portion out to a separate patch.  Otherwise it looks good.

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

[refpolicy] RFC: direct_init_entry breaks direct_initrc

[Dominick Grift]

On Wed, 2014-01-15 at 08:51 -0500, Christopher J. PeBenito wrote:
> On 01/14/14 17:23, Dominick Grift wrote:
> > On Tue, 2014-01-14 at 15:44 -0500, Christopher J. PeBenito wrote:
> >>
> >> I think you may be able to drop the direct_run_init attribute and put the domtrans you added in the init_run_daemon() interface instead.
> >>
> > 
> > Right, i also got rid of direct_init because was a lose end as well
> > 
> > It builds but still not actually tested
> 
> On further looking it looks like we shouldn't completely remove the direct_sysadm_daemon block out of init_daemon_domain; the userdom_dontaudit_use_user_terminals($1) should probably remain.  I'd also prefer to separate the unconfined portion out to a separate patch.  Otherwise it looks good.
> 

Enclosed patches. Built successfully

By the way this may not be a end-all solution. Since i think commands
like newaliases and rpm *may* also be affected especially with regard to
system_r role but i think that if that turns out to be true that we can
deal with those issue as they arise. (these are some of the very rare
instances where a role transition might also be desired)

In my test on Fedora i did run rpm and did not notice anything except a

allow NetworkManager_t initrc_t:process sigkill;

not sure if that was related but it is kind of weird since Fedora uses
systemd_t so i wasnt expecting anything initrc_t related

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Apply-directinitrc-to-unconfinedrunconfinedt.patch
Type: text/x-patch
Size: 2225 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20140115/b910f0c9/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Change-behavior-of-initrundaemon.patch
Type: text/x-patch
Size: 2227 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20140115/b910f0c9/attachment-0003.bin 

[refpolicy] RFC: direct_init_entry breaks direct_initrc

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/15/2014 10:44 AM, Dominick Grift wrote:
> On Wed, 2014-01-15 at 08:51 -0500, Christopher J. PeBenito wrote:
>> On 01/14/14 17:23, Dominick Grift wrote:
>>> On Tue, 2014-01-14 at 15:44 -0500, Christopher J. PeBenito wrote:
>>>> 
>>>> I think you may be able to drop the direct_run_init attribute and put
>>>> the domtrans you added in the init_run_daemon() interface instead.
>>>> 
>>> 
>>> Right, i also got rid of direct_init because was a lose end as well
>>> 
>>> It builds but still not actually tested
>> 
>> On further looking it looks like we shouldn't completely remove the
>> direct_sysadm_daemon block out of init_daemon_domain; the
>> userdom_dontaudit_use_user_terminals($1) should probably remain.  I'd
>> also prefer to separate the unconfined portion out to a separate patch.
>> Otherwise it looks good.
>> 
> 
> Enclosed patches. Built successfully
> 
> By the way this may not be a end-all solution. Since i think commands like
> newaliases and rpm *may* also be affected especially with regard to 
> system_r role but i think that if that turns out to be true that we can 
> deal with those issue as they arise. (these are some of the very rare 
> instances where a role transition might also be desired)
> 
> In my test on Fedora i did run rpm and did not notice anything except a
> 
> allow NetworkManager_t initrc_t:process sigkill;
> 
> not sure if that was related but it is kind of weird since Fedora uses 
> systemd_t so i wasnt expecting anything initrc_t related
> 
> 
NetworkManager_t has lots of transitions to initrc_t, maybe one of these has
not been replaced with systemd yet.




> 
> _______________________________________________ refpolicy mailing list 
> refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLWvt4ACgkQrlYvE4MpobMP+ACfV1G7lQBDmfWF+z4LqF9abfmA
UKEAn2xpQQTbXiHLn1SBLdKrVH38Tgng
=EiNd
-----END PGP SIGNATURE-----

[refpolicy] RFC: direct_init_entry breaks direct_initrc

[Christopher J. PeBenito]

On 01/15/14 10:44, Dominick Grift wrote:
> On Wed, 2014-01-15 at 08:51 -0500, Christopher J. PeBenito wrote:
>> On 01/14/14 17:23, Dominick Grift wrote:
>>> On Tue, 2014-01-14 at 15:44 -0500, Christopher J. PeBenito wrote:
>>>>
>>>> I think you may be able to drop the direct_run_init attribute and put the domtrans you added in the init_run_daemon() interface instead.
>>>>
>>>
>>> Right, i also got rid of direct_init because was a lose end as well
>>>
>>> It builds but still not actually tested
>>
>> On further looking it looks like we shouldn't completely remove the direct_sysadm_daemon block out of init_daemon_domain; the userdom_dontaudit_use_user_terminals($1) should probably remain.  I'd also prefer to separate the unconfined portion out to a separate patch.  Otherwise it looks good.
>>
> 
> Enclosed patches. Built successfully
> 
> By the way this may not be a end-all solution. Since i think commands
> like newaliases and rpm *may* also be affected especially with regard to
> system_r role but i think that if that turns out to be true that we can
> deal with those issue as they arise. (these are some of the very rare
> instances where a role transition might also be desired)

Merged.

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

[refpolicy] RFC: direct_init_entry breaks direct_initrc

[Sven Vermeulen]

On Tue, 2013-12-10 at 17:00 +0100, Dominick Grift wrote:
> On Tue, 2013-12-10 at 16:57 +0100, Dominick Grift wrote:
> 
> > >  
> > >  		typeattribute $1 direct_init;
> > -		typeattribute $2 direct_init_entry;
> 
> Here its actually associated with the init daemon entry file. That is
> wrong in my view. The role transition should happen on the init script
> not the daemon entry file
> 
> > > -	role_transition $2 direct_init_entry system_r;
> > > +	role_transition $2 init_script_file_type system_r;
>
> Here is that actual role transition. This is causing problems with
> direct_initrc. role transition to system_r should happen on the init
> script and not the init daemon executable file

In Gentoo, we don't use the direct_* attributes so I can't tell you that
they do (or do not) cause problems. 

hpl htdocs # seinfo -adirect_init -x
   direct_init
hpl htdocs # seinfo -adirect_run_init -x
   direct_run_init
hpl htdocs # seinfo -adirect_init_entry -x
   direct_init_entry

What we do is we have the following set:

seutil_init_script_run_runinit(sysadm_t, sysadm_r)
. seutil_init_script_domtrans_runinit(sysadm_t)
. . init_script_file_domtrans(sysadm_t, run_init_t)
. . . domain_auto_trans(sysadm_t, initrc_exec_t, run_init_t)

This ensures that, if sysadm_t executes an initrc_exec_t script, the script
is launched in the run_init_t context. Then, our init system (OpenRC) calls
a shared library we provide (linked with libselinux) which sets the next
execution context to system_u:system_r:initrc_t (using setexeccon) and
re-executes the script.

Wkr,
  Sven Vermeulen

[refpolicy] RFC: direct_init_entry breaks direct_initrc

[Dominick Grift]

On Wed, 2013-12-11 at 09:33 +0100, Sven Vermeulen wrote:
> 
> What we do is we have the following set:
> 
> seutil_init_script_run_runinit(sysadm_t, sysadm_r)
> . seutil_init_script_domtrans_runinit(sysadm_t)
> . . init_script_file_domtrans(sysadm_t, run_init_t)
> . . . domain_auto_trans(sysadm_t, initrc_exec_t, run_init_t)
> 
> This ensures that, if sysadm_t executes an initrc_exec_t script, the script
> is launched in the run_init_t context. Then, our init system (OpenRC) calls
> a shared library we provide (linked with libselinux) which sets the next
> execution context to system_u:system_r:initrc_t (using setexeccon) and
> re-executes the script.
> 

Thanks. Do the *_admin() interfaces work in Gentoo?

The role transition in the *_admin() interfaces happen on the init
scripts, So if they work in Gentoo then i think we can be pretty certain
that the change i am suggesting in my patch will not break the SELinux
policy openrc solution.

It's a bit harder to verify init related stuff now though because
gentoo, debian and fedora each use a different init systems now

I believe we need to make sure to role transition on the init scripts
only because if we role transition on the daemon executable files
themselves then we get conflicts with executable files that can be run
both as a system service as well as a sessions service.

[refpolicy] RFC: direct_init_entry breaks direct_initrc

[Sven Vermeulen]

On Wed, Dec 11, 2013 at 09:56:37AM +0100, Dominick Grift wrote:
> Thanks. Do the *_admin() interfaces work in Gentoo?
> 
> The role transition in the *_admin() interfaces happen on the init
> scripts, So if they work in Gentoo then i think we can be pretty certain
> that the change i am suggesting in my patch will not break the SELinux
> policy openrc solution.

Yes they do.

In case of such transitions, upon executing the script, the context is
already initrc_t (in the system_r role). The SELinux code that OpenRC calls
checks the current context, sees that it is not run_init_t and gracefully
returns (no further actions taken) and the "normal" flow continues.

> It's a bit harder to verify init related stuff now though because
> gentoo, debian and fedora each use a different init systems now

Indeed. I wouldn't mind splitting the init code into their respective
domains, although that will be a "hell of a job", while there are still
important shared aspects to it.

> I believe we need to make sure to role transition on the init scripts
> only because if we role transition on the daemon executable files
> themselves then we get conflicts with executable files that can be run
> both as a system service as well as a sessions service.

Indeed. 

Wkr,
	Sven Vermeulen

[refpolicy] RFC: direct_init_entry breaks direct_initrc

[Dominick Grift]

On Wed, 2013-12-11 at 10:52 +0100, Sven Vermeulen wrote:

> > It's a bit harder to verify init related stuff now though because
> > gentoo, debian and fedora each use a different init systems now
> 
> Indeed. I wouldn't mind splitting the init code into their respective
> domains, although that will be a "hell of a job", while there are still
> important shared aspects to it.

Looking at Fedoras' solution i now think that this probably will not be
optimal although i cannot think of any really convincing arguments to
back up my statement, other then that it is probably a bit too late for
that now, and that it is probably not as efficient.

We can make the systemd specific policy conditional, and if we do that
consistent then that should probably be okay

Thanks