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 <[email protected]>
> 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 <[email protected]>
> 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;
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
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 <[email protected]>
>> 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 <[email protected]>
>> 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
http://www.tresys.com | oss.tresys.com
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
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
http://www.tresys.com | oss.tresys.com
-----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 http://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-----
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
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
http://www.tresys.com | oss.tresys.com
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
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
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
http://www.tresys.com | oss.tresys.com
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
-----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-----
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
http://www.tresys.com | oss.tresys.com