Update for the dbus module so that it can start.
Signed-off-by: Guido Trentalancia <[email protected]>
---
policy/modules/contrib/dbus.te | 1 +
1 file changed, 1 insertion(+)
--- refpolicy-git-06082016-orig/policy/modules/contrib/dbus.te 2016-08-06
21:27:11.344094223 +0200
+++ refpolicy-git-06082016/policy/modules/contrib/dbus.te 2016-08-13
13:20:54.013168684 +0200
@@ -91,6 +91,7 @@ kernel_read_kernel_sysctls(system_dbusd_
corecmd_list_bin(system_dbusd_t)
corecmd_read_bin_pipes(system_dbusd_t)
corecmd_read_bin_sockets(system_dbusd_t)
+corecmd_exec_bin(system_dbusd_t)
corecmd_exec_shell(system_dbusd_t)
dev_read_urand(system_dbusd_t)
On 08/13/2016 11:15 PM, Guido Trentalancia wrote:
> Update for the dbus module so that it can start.
What binary are you referring to?
>
> Signed-off-by: Guido Trentalancia <[email protected]>
> ---
> policy/modules/contrib/dbus.te | 1 +
> 1 file changed, 1 insertion(+)
>
> --- refpolicy-git-06082016-orig/policy/modules/contrib/dbus.te 2016-08-06
> 21:27:11.344094223 +0200
> +++ refpolicy-git-06082016/policy/modules/contrib/dbus.te 2016-08-13
> 13:20:54.013168684 +0200
> @@ -91,6 +91,7 @@ kernel_read_kernel_sysctls(system_dbusd_
> corecmd_list_bin(system_dbusd_t)
> corecmd_read_bin_pipes(system_dbusd_t)
> corecmd_read_bin_sockets(system_dbusd_t)
> +corecmd_exec_bin(system_dbusd_t)
> corecmd_exec_shell(system_dbusd_t)
>
> dev_read_urand(system_dbusd_t)
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160814/d10c3ddc/attachment.bin
On Sun, 14/08/2016 at 11.00 +0200, Dominick Grift wrote:
> On 08/13/2016 11:15 PM, Guido Trentalancia wrote:
> > Update for the dbus module so that it can start.
>
> What binary are you referring to?
Apparently it tries to execute /bin/false. If it fails, it refuses to
start.
> > Signed-off-by: Guido Trentalancia <[email protected]>
> > ---
> > ?policy/modules/contrib/dbus.te |????1 +
> > ?1 file changed, 1 insertion(+)
> >
> > --- refpolicy-git-06082016-orig/policy/modules/contrib/dbus.te
> > 2016-08-06
> > 21:27:11.344094223 +0200
> > +++ refpolicy-git-06082016/policy/modules/contrib/dbus.te 20
> > 16-08-13
> > 13:20:54.013168684 +0200
> > @@ -91,6 +91,7 @@ kernel_read_kernel_sysctls(system_dbusd_
> > ?corecmd_list_bin(system_dbusd_t)
> > ?corecmd_read_bin_pipes(system_dbusd_t)
> > ?corecmd_read_bin_sockets(system_dbusd_t)
> > +corecmd_exec_bin(system_dbusd_t)
> > ?corecmd_exec_shell(system_dbusd_t)
> > ?
> > ?dev_read_urand(system_dbusd_t)
Best regards,
Guido
On 08/13/2016 11:15 PM, Guido Trentalancia wrote:
> Update for the dbus module so that it can start.
I asked about this in your previous patch but got no answer.
This should'nt be added
>
> Signed-off-by: Guido Trentalancia <[email protected]>
> ---
> policy/modules/contrib/dbus.te | 1 +
> 1 file changed, 1 insertion(+)
>
> --- refpolicy-git-06082016-orig/policy/modules/contrib/dbus.te 2016-08-06
> 21:27:11.344094223 +0200
> +++ refpolicy-git-06082016/policy/modules/contrib/dbus.te 2016-08-13
> 13:20:54.013168684 +0200
> @@ -91,6 +91,7 @@ kernel_read_kernel_sysctls(system_dbusd_
> corecmd_list_bin(system_dbusd_t)
> corecmd_read_bin_pipes(system_dbusd_t)
> corecmd_read_bin_sockets(system_dbusd_t)
> +corecmd_exec_bin(system_dbusd_t)
> corecmd_exec_shell(system_dbusd_t)
>
> dev_read_urand(system_dbusd_t)
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160814/fc826428/attachment.bin
On 08/14/2016 09:37 PM, Guido Trentalancia wrote:
> On Sun, 14/08/2016 at 11.00 +0200, Dominick Grift wrote:
>> On 08/13/2016 11:15 PM, Guido Trentalancia wrote:
>>> Update for the dbus module so that it can start.
>>
>> What binary are you referring to?
>
> Apparently it tries to execute /bin/false. If it fails, it refuses to
> start.
>
Oh sorry i overlooked this reply. I can't reproduce this. Please
reproduce and enclose the avc denial. This shouldnt be needed in my
experience.
>>> Signed-off-by: Guido Trentalancia <[email protected]>
>>> ---
>>> policy/modules/contrib/dbus.te | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> --- refpolicy-git-06082016-orig/policy/modules/contrib/dbus.te
>>> 2016-08-06
>>> 21:27:11.344094223 +0200
>>> +++ refpolicy-git-06082016/policy/modules/contrib/dbus.te 20
>>> 16-08-13
>>> 13:20:54.013168684 +0200
>>> @@ -91,6 +91,7 @@ kernel_read_kernel_sysctls(system_dbusd_
>>> corecmd_list_bin(system_dbusd_t)
>>> corecmd_read_bin_pipes(system_dbusd_t)
>>> corecmd_read_bin_sockets(system_dbusd_t)
>>> +corecmd_exec_bin(system_dbusd_t)
>>> corecmd_exec_shell(system_dbusd_t)
>>>
>>> dev_read_urand(system_dbusd_t)
>
> Best regards,
>
> Guido
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160814/9f654707/attachment-0001.bin
Hello Dominick.
> On the 14th August 2016 at 21.40 Dominick Grift <[email protected]>
> wrote:
>
>
> On 08/14/2016 09:37 PM, Guido Trentalancia wrote:
> > On Sun, 14/08/2016 at 11.00 +0200, Dominick Grift wrote:
> >> On 08/13/2016 11:15 PM, Guido Trentalancia wrote:
> >>> Update for the dbus module so that it can start.
> >>
> >> What binary are you referring to?
> >
> > Apparently it tries to execute /bin/false. If it fails, it refuses to
> > start.
> >
>
> Oh sorry i overlooked this reply. I can't reproduce this. Please
> reproduce and enclose the avc denial. This shouldnt be needed in my
> experience.
type=AVC msg=audit(1471048594.845:72): avc: denied { execute } for pid=2075
comm="dbus-daemon-lau" name="false" dev="dm-2" ino=1583337
scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
tcontext=system_u:object_r:bin_t:s0 tclass=file permissive=0
type=SYSCALL msg=audit(1471048594.845:72): arch=c000003e syscall=59 success=no
exit=-13 a0=15c6eb0 a1=15c6740 a2=15c6010 a3=95 items=0 ppid=2074 pid=2075
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) ses=4294967295 comm="dbus-daemon-lau"
exe="/usr/libexec/dbus-daemon-launch-helper"
subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null)
I am not happy to add the permission, but unfortunately, if it refuses to start,
I can't see other choices.
> >>> Signed-off-by: Guido Trentalancia <[email protected]>
> >>> ---
> >>> policy/modules/contrib/dbus.te | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> --- refpolicy-git-06082016-orig/policy/modules/contrib/dbus.te
> >>> 2016-08-06
> >>> 21:27:11.344094223 +0200
> >>> +++ refpolicy-git-06082016/policy/modules/contrib/dbus.te 20
> >>> 16-08-13
> >>> 13:20:54.013168684 +0200
> >>> @@ -91,6 +91,7 @@ kernel_read_kernel_sysctls(system_dbusd_
> >>> corecmd_list_bin(system_dbusd_t)
> >>> corecmd_read_bin_pipes(system_dbusd_t)
> >>> corecmd_read_bin_sockets(system_dbusd_t)
> >>> +corecmd_exec_bin(system_dbusd_t)
> >>> corecmd_exec_shell(system_dbusd_t)
> >>>
> >>> dev_read_urand(system_dbusd_t)
Regards,
Guido
On 08/14/2016 10:05 PM, Guido Trentalancia wrote:
> Hello Dominick.
>
>> On the 14th August 2016 at 21.40 Dominick Grift <[email protected]>
>> wrote:
>>
>>
>> On 08/14/2016 09:37 PM, Guido Trentalancia wrote:
>>> On Sun, 14/08/2016 at 11.00 +0200, Dominick Grift wrote:
>>>> On 08/13/2016 11:15 PM, Guido Trentalancia wrote:
>>>>> Update for the dbus module so that it can start.
>>>>
>>>> What binary are you referring to?
>>>
>>> Apparently it tries to execute /bin/false. If it fails, it refuses to
>>> start.
>>>
>>
>> Oh sorry i overlooked this reply. I can't reproduce this. Please
>> reproduce and enclose the avc denial. This shouldnt be needed in my
>> experience.
>
> type=AVC msg=audit(1471048594.845:72): avc: denied { execute } for pid=2075
> comm="dbus-daemon-lau" name="false" dev="dm-2" ino=1583337
> scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:bin_t:s0 tclass=file permissive=0
> type=SYSCALL msg=audit(1471048594.845:72): arch=c000003e syscall=59 success=no
> exit=-13 a0=15c6eb0 a1=15c6740 a2=15c6010 a3=95 items=0 ppid=2074 pid=2075
> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=(none) ses=4294967295 comm="dbus-daemon-lau"
> exe="/usr/libexec/dbus-daemon-launch-helper"
> subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null)
>
> I am not happy to add the permission, but unfortunately, if it refuses to start,
> I can't see other choices.
>
I can, but it is not pretty.
We should target /usr/libexec/dbus-daemon-launch-helper
You see if you now allow system_dbus_t then we get into issues later
because dbus can be used to start daemons. So we risk daemons ending up
trying to run in the system_dbus_t domain, and if we arent paying
attention that might lead us to associate permisisons to system_dbus_t
that arent actually needed by dbus but instead are needed for some
daemon started by dbus
>>>>> Signed-off-by: Guido Trentalancia <[email protected]>
>>>>> ---
>>>>> policy/modules/contrib/dbus.te | 1 +
>>>>> 1 file changed, 1 insertion(+)
>>>>>
>>>>> --- refpolicy-git-06082016-orig/policy/modules/contrib/dbus.te
>>>>> 2016-08-06
>>>>> 21:27:11.344094223 +0200
>>>>> +++ refpolicy-git-06082016/policy/modules/contrib/dbus.te 20
>>>>> 16-08-13
>>>>> 13:20:54.013168684 +0200
>>>>> @@ -91,6 +91,7 @@ kernel_read_kernel_sysctls(system_dbusd_
>>>>> corecmd_list_bin(system_dbusd_t)
>>>>> corecmd_read_bin_pipes(system_dbusd_t)
>>>>> corecmd_read_bin_sockets(system_dbusd_t)
>>>>> +corecmd_exec_bin(system_dbusd_t)
>>>>> corecmd_exec_shell(system_dbusd_t)
>>>>>
>>>>> dev_read_urand(system_dbusd_t)
>
> Regards,
>
> Guido
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160814/c061d061/attachment.bin
Hello Dominick !
> On the 14th of August 2016 at 22.10 Dominick Grift <[email protected]>
> wrote:
>
>
> On 08/14/2016 10:05 PM, Guido Trentalancia wrote:
> > Hello Dominick.
> >
> >> On the 14th August 2016 at 21.40 Dominick Grift <[email protected]>
> >> wrote:
> >>
> >>
> >> On 08/14/2016 09:37 PM, Guido Trentalancia wrote:
> >>> On Sun, 14/08/2016 at 11.00 +0200, Dominick Grift wrote:
> >>>> On 08/13/2016 11:15 PM, Guido Trentalancia wrote:
> >>>>> Update for the dbus module so that it can start.
> >>>>
> >>>> What binary are you referring to?
> >>>
> >>> Apparently it tries to execute /bin/false. If it fails, it refuses to
> >>> start.
> >>>
> >>
> >> Oh sorry i overlooked this reply. I can't reproduce this. Please
> >> reproduce and enclose the avc denial. This shouldnt be needed in my
> >> experience.
> >
> > type=AVC msg=audit(1471048594.845:72): avc: denied { execute } for
> > pid=2075
> > comm="dbus-daemon-lau" name="false" dev="dm-2" ino=1583337
> > scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
> > tcontext=system_u:object_r:bin_t:s0 tclass=file permissive=0
> > type=SYSCALL msg=audit(1471048594.845:72): arch=c000003e syscall=59
> > success=no
> > exit=-13 a0=15c6eb0 a1=15c6740 a2=15c6010 a3=95 items=0 ppid=2074 pid=2075
> > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> > tty=(none) ses=4294967295 comm="dbus-daemon-lau"
> > exe="/usr/libexec/dbus-daemon-launch-helper"
> > subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null)
> >
> > I am not happy to add the permission, but unfortunately, if it refuses to
> > start,
> > I can't see other choices.
> >
>
> I can, but it is not pretty.
>
> We should target /usr/libexec/dbus-daemon-launch-helper
>
> You see if you now allow system_dbus_t then we get into issues later
> because dbus can be used to start daemons. So we risk daemons ending up
> trying to run in the system_dbus_t domain, and if we arent paying
> attention that might lead us to associate permisisons to system_dbus_t
> that arent actually needed by dbus but instead are needed for some
> daemon started by dbus
Do you want to propose an alternative patch ?
> >>>>> Signed-off-by: Guido Trentalancia <[email protected]>
> >>>>> ---
> >>>>> policy/modules/contrib/dbus.te | 1 +
> >>>>> 1 file changed, 1 insertion(+)
> >>>>>
> >>>>> --- refpolicy-git-06082016-orig/policy/modules/contrib/dbus.te
> >>>>> 2016-08-06
> >>>>> 21:27:11.344094223 +0200
> >>>>> +++ refpolicy-git-06082016/policy/modules/contrib/dbus.te 20
> >>>>> 16-08-13
> >>>>> 13:20:54.013168684 +0200
> >>>>> @@ -91,6 +91,7 @@ kernel_read_kernel_sysctls(system_dbusd_
> >>>>> corecmd_list_bin(system_dbusd_t)
> >>>>> corecmd_read_bin_pipes(system_dbusd_t)
> >>>>> corecmd_read_bin_sockets(system_dbusd_t)
> >>>>> +corecmd_exec_bin(system_dbusd_t)
> >>>>> corecmd_exec_shell(system_dbusd_t)
> >>>>>
> >>>>> dev_read_urand(system_dbusd_t)
On 08/14/2016 10:21 PM, Guido Trentalancia wrote:
> Hello Dominick !
>
>> On the 14th of August 2016 at 22.10 Dominick Grift <[email protected]>
>> wrote:
>>
>>
>> On 08/14/2016 10:05 PM, Guido Trentalancia wrote:
>>> Hello Dominick.
>>>
>>>> On the 14th August 2016 at 21.40 Dominick Grift <[email protected]>
>>>> wrote:
>>>>
>>>>
>>>> On 08/14/2016 09:37 PM, Guido Trentalancia wrote:
>>>>> On Sun, 14/08/2016 at 11.00 +0200, Dominick Grift wrote:
>>>>>> On 08/13/2016 11:15 PM, Guido Trentalancia wrote:
>>>>>>> Update for the dbus module so that it can start.
>>>>>>
>>>>>> What binary are you referring to?
>>>>>
>>>>> Apparently it tries to execute /bin/false. If it fails, it refuses to
>>>>> start.
>>>>>
>>>>
>>>> Oh sorry i overlooked this reply. I can't reproduce this. Please
>>>> reproduce and enclose the avc denial. This shouldnt be needed in my
>>>> experience.
>>>
>>> type=AVC msg=audit(1471048594.845:72): avc: denied { execute } for
>>> pid=2075
>>> comm="dbus-daemon-lau" name="false" dev="dm-2" ino=1583337
>>> scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
>>> tcontext=system_u:object_r:bin_t:s0 tclass=file permissive=0
>>> type=SYSCALL msg=audit(1471048594.845:72): arch=c000003e syscall=59
>>> success=no
>>> exit=-13 a0=15c6eb0 a1=15c6740 a2=15c6010 a3=95 items=0 ppid=2074 pid=2075
>>> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
>>> tty=(none) ses=4294967295 comm="dbus-daemon-lau"
>>> exe="/usr/libexec/dbus-daemon-launch-helper"
>>> subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null)
>>>
>>> I am not happy to add the permission, but unfortunately, if it refuses to
>>> start,
>>> I can't see other choices.
>>>
>>
>> I can, but it is not pretty.
>>
>> We should target /usr/libexec/dbus-daemon-launch-helper
>>
>> You see if you now allow system_dbus_t then we get into issues later
>> because dbus can be used to start daemons. So we risk daemons ending up
>> trying to run in the system_dbus_t domain, and if we arent paying
>> attention that might lead us to associate permisisons to system_dbus_t
>> that arent actually needed by dbus but instead are needed for some
>> daemon started by dbus
>
> Do you want to propose an alternative patch ?
Yes /usr/libexec/dbus-daemon-launch-helper should be targeted in a
separate domain, probably a init_system_domain() assuming that its
started by init.
>
>>>>>>> Signed-off-by: Guido Trentalancia <[email protected]>
>>>>>>> ---
>>>>>>> policy/modules/contrib/dbus.te | 1 +
>>>>>>> 1 file changed, 1 insertion(+)
>>>>>>>
>>>>>>> --- refpolicy-git-06082016-orig/policy/modules/contrib/dbus.te
>>>>>>> 2016-08-06
>>>>>>> 21:27:11.344094223 +0200
>>>>>>> +++ refpolicy-git-06082016/policy/modules/contrib/dbus.te 20
>>>>>>> 16-08-13
>>>>>>> 13:20:54.013168684 +0200
>>>>>>> @@ -91,6 +91,7 @@ kernel_read_kernel_sysctls(system_dbusd_
>>>>>>> corecmd_list_bin(system_dbusd_t)
>>>>>>> corecmd_read_bin_pipes(system_dbusd_t)
>>>>>>> corecmd_read_bin_sockets(system_dbusd_t)
>>>>>>> +corecmd_exec_bin(system_dbusd_t)
>>>>>>> corecmd_exec_shell(system_dbusd_t)
>>>>>>>
>>>>>>> dev_read_urand(system_dbusd_t)
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160814/cc292b3d/attachment-0001.bin
On 08/14/2016 10:28 PM, Dominick Grift wrote:
> On 08/14/2016 10:21 PM, Guido Trentalancia wrote:
>> Hello Dominick !
>>
>>> On the 14th of August 2016 at 22.10 Dominick Grift <[email protected]>
>>> wrote:
>>>
>>>
>>> On 08/14/2016 10:05 PM, Guido Trentalancia wrote:
>>>> Hello Dominick.
>>>>
>>>>> On the 14th August 2016 at 21.40 Dominick Grift <[email protected]>
>>>>> wrote:
>>>>>
>>>>>
>>>>> On 08/14/2016 09:37 PM, Guido Trentalancia wrote:
>>>>>> On Sun, 14/08/2016 at 11.00 +0200, Dominick Grift wrote:
>>>>>>> On 08/13/2016 11:15 PM, Guido Trentalancia wrote:
>>>>>>>> Update for the dbus module so that it can start.
>>>>>>>
>>>>>>> What binary are you referring to?
>>>>>>
>>>>>> Apparently it tries to execute /bin/false. If it fails, it refuses to
>>>>>> start.
>>>>>>
>>>>>
>>>>> Oh sorry i overlooked this reply. I can't reproduce this. Please
>>>>> reproduce and enclose the avc denial. This shouldnt be needed in my
>>>>> experience.
>>>>
>>>> type=AVC msg=audit(1471048594.845:72): avc: denied { execute } for
>>>> pid=2075
>>>> comm="dbus-daemon-lau" name="false" dev="dm-2" ino=1583337
>>>> scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
>>>> tcontext=system_u:object_r:bin_t:s0 tclass=file permissive=0
>>>> type=SYSCALL msg=audit(1471048594.845:72): arch=c000003e syscall=59
>>>> success=no
>>>> exit=-13 a0=15c6eb0 a1=15c6740 a2=15c6010 a3=95 items=0 ppid=2074 pid=2075
>>>> auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
>>>> tty=(none) ses=4294967295 comm="dbus-daemon-lau"
>>>> exe="/usr/libexec/dbus-daemon-launch-helper"
>>>> subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null)
>>>>
>>>> I am not happy to add the permission, but unfortunately, if it refuses to
>>>> start,
>>>> I can't see other choices.
>>>>
>>>
>>> I can, but it is not pretty.
>>>
>>> We should target /usr/libexec/dbus-daemon-launch-helper
>>>
>>> You see if you now allow system_dbus_t then we get into issues later
>>> because dbus can be used to start daemons. So we risk daemons ending up
>>> trying to run in the system_dbus_t domain, and if we arent paying
>>> attention that might lead us to associate permisisons to system_dbus_t
>>> that arent actually needed by dbus but instead are needed for some
>>> daemon started by dbus
>>
>> Do you want to propose an alternative patch ?
>
> Yes /usr/libexec/dbus-daemon-launch-helper should be targeted in a
> separate domain, probably a init_system_domain() assuming that its
> started by init.
>
By the way. I know that it must test your patience as well. I think I
know how you might feel (I've been there as well). Submitting revision
following revision etc.
Just know that these reviews/rewrites will eventually pay off. It will
make you better, and that will make writing good policy easier.
It is appreciated!
I will not be able to write a solid policy for
/usr/libexec/dbus-daemon-launch-helper because my system does not use
it. so i will not be able to easily produce it.
>>
>>>>>>>> Signed-off-by: Guido Trentalancia <[email protected]>
>>>>>>>> ---
>>>>>>>> policy/modules/contrib/dbus.te | 1 +
>>>>>>>> 1 file changed, 1 insertion(+)
>>>>>>>>
>>>>>>>> --- refpolicy-git-06082016-orig/policy/modules/contrib/dbus.te
>>>>>>>> 2016-08-06
>>>>>>>> 21:27:11.344094223 +0200
>>>>>>>> +++ refpolicy-git-06082016/policy/modules/contrib/dbus.te 20
>>>>>>>> 16-08-13
>>>>>>>> 13:20:54.013168684 +0200
>>>>>>>> @@ -91,6 +91,7 @@ kernel_read_kernel_sysctls(system_dbusd_
>>>>>>>> corecmd_list_bin(system_dbusd_t)
>>>>>>>> corecmd_read_bin_pipes(system_dbusd_t)
>>>>>>>> corecmd_read_bin_sockets(system_dbusd_t)
>>>>>>>> +corecmd_exec_bin(system_dbusd_t)
>>>>>>>> corecmd_exec_shell(system_dbusd_t)
>>>>>>>>
>>>>>>>> dev_read_urand(system_dbusd_t)
>
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20160814/651d1f22/attachment.bin
Hello Dominick (and cc Christoper).
I am dropping this patch as it currently is, because it exposes the
system to security risks.
On Sun, 14/08/2016 at 22.28 +0200, Dominick Grift wrote:
> On 08/14/2016 10:21 PM, Guido Trentalancia wrote:
> > Hello Dominick !
> >
> > > On the 14th of August 2016 at 22.10 Dominick Grift <dac.override@
> > > gmail.com>
> > > wrote:
> > >
> > >
> > > On 08/14/2016 10:05 PM, Guido Trentalancia wrote:
> > > > Hello Dominick.
> > > >
> > > > > On the 14th August 2016 at 21.40 Dominick Grift <dac.override
> > > > > @gmail.com>
> > > > > wrote:
> > > > >
> > > > >
> > > > > On 08/14/2016 09:37 PM, Guido Trentalancia wrote:
> > > > > > On Sun, 14/08/2016 at 11.00 +0200, Dominick Grift wrote:
> > > > > > > On 08/13/2016 11:15 PM, Guido Trentalancia wrote:
> > > > > > > > Update for the dbus module so that it can start.
> > > > > > >
> > > > > > > What binary are you referring to?
> > > > > >
> > > > > > Apparently it tries to execute /bin/false. If it fails, it
> > > > > > refuses to
> > > > > > start.
> > > > > >
> > > > >
> > > > > Oh sorry i overlooked this reply. I can't reproduce this.
> > > > > Please
> > > > > reproduce and enclose the avc denial. This shouldnt be needed
> > > > > in my
> > > > > experience.
It originates in the Exec field of the service files (/usr/share/dbus-
1/system-services/*.service).
It is extremely easy to reproduce, just create an empty service file
and add an Exec=/bin/false statement or whatever other binary you want
to execute, then upon starting up dbus, the dbus-daemon-launch-helper
tries to execute that !
The strange thing is that now, after testing it again, it does not
prevent the system from starting up. Maybe there was something else
preventing that...
You see, some services that are executed through systemd are shipped
with service files that bring the Exec field set to /bin/false, most
probably because the Exec field is mandatory for dbus service files...
I am now dropping this dbus patch, because corecmd_exec_bin() executes
bin_t executable files BUT the resulting process runs in the
system_dbusd_t ! Exactly as you forecasted, I think !
> > > > type=AVC msg=audit(1471048594.845:72): avc:??denied??{ execute
> > > > } for
> > > > ?pid=2075
> > > > comm="dbus-daemon-lau" name="false" dev="dm-2" ino=1583337
> > > > scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
> > > > tcontext=system_u:object_r:bin_t:s0 tclass=file permissive=0
> > > > type=SYSCALL msg=audit(1471048594.845:72): arch=c000003e
> > > > syscall=59
> > > > success=no
> > > > exit=-13 a0=15c6eb0 a1=15c6740 a2=15c6010 a3=95 items=0
> > > > ppid=2074 pid=2075
> > > > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
> > > > fsgid=0
> > > > tty=(none) ses=4294967295 comm="dbus-daemon-lau"
> > > > exe="/usr/libexec/dbus-daemon-launch-helper"
> > > > subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null)
> > > >
> > > > I am not happy to add the permission, but unfortunately, if it
> > > > refuses to
> > > > start,
> > > > I can't see other choices.
> > > >
> > >
> > > I can, but it is not pretty.
> > >
> > > We should target /usr/libexec/dbus-daemon-launch-helper
> > >
> > > You see if you now allow system_dbus_t then we get into issues
> > > later
> > > because dbus can be used to start daemons. So we risk daemons
> > > ending up
> > > trying to run in the system_dbus_t domain, and if we arent paying
> > > attention that might lead us to associate permisisons to
> > > system_dbus_t
> > > that arent actually needed by dbus but instead are needed for
> > > some
> > > daemon started by dbus
Yes, I agree, it's very risky and it should be avoided at all cost.
Thanks very much for spotting this problem !
> > Do you want to propose an alternative patch ?
>
> Yes /usr/libexec/dbus-daemon-launch-helper should be targeted in a
> separate domain, probably a init_system_domain() assuming that its
> started by init.
I'll see what I can do with some more time. It's not an urgent
matter...
> >
> > > > > > > > Signed-off-by: Guido Trentalancia <[email protected]
> > > > > > > > et>
> > > > > > > > ---
> > > > > > > > ?policy/modules/contrib/dbus.te |????1 +
> > > > > > > > ?1 file changed, 1 insertion(+)
> > > > > > > >
> > > > > > > > --- refpolicy-git-06082016-
> > > > > > > > orig/policy/modules/contrib/dbus.te
> > > > > > > > 2016-08-06
> > > > > > > > 21:27:11.344094223 +0200
> > > > > > > > +++ refpolicy-git-
> > > > > > > > 06082016/policy/modules/contrib/dbus.te 20
> > > > > > > > 16-08-13
> > > > > > > > 13:20:54.013168684 +0200
> > > > > > > > @@ -91,6 +91,7 @@
> > > > > > > > kernel_read_kernel_sysctls(system_dbusd_
> > > > > > > > ?corecmd_list_bin(system_dbusd_t)
> > > > > > > > ?corecmd_read_bin_pipes(system_dbusd_t)
> > > > > > > > ?corecmd_read_bin_sockets(system_dbusd_t)
> > > > > > > > +corecmd_exec_bin(system_dbusd_t)
> > > > > > > > ?corecmd_exec_shell(system_dbusd_t)
> > > > > > > > ?
> > > > > > > > ?dev_read_urand(system_dbusd_t)
Best regards,
Guido