It seems that the current refpolicy file contexts are using a wrong (or
at least rather obsolete) location for the PackageKit daemon executable.
It's standard location is in /usr/libexec and not /usr/sbin (FC17 also
apparently uses the latter).
Finally, consider that PackageKit should now ship also with
distributions other than Redhat.
So, either of these two patches, would probably be a good move:
--- refpolicy-04062012/policy/modules/contrib/rpm.fc 2011-09-09 18:29:23.592611047 +0200
+++ refpolicy-04062012-packagekit-fc/policy/modules/contrib/rpm.fc 2012-06-19 19:12:07.420661407 +0200
@@ -13,7 +13,13 @@
/usr/sbin/system-install-packages -- gen_context(system_u:object_r:rpm_exec_t,s0)
/usr/sbin/yum-updatesd -- gen_context(system_u:object_r:rpm_exec_t,s0)
+
+ifndef(`distro_redhat', `
+/usr/libexec/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
+')
+ifdef(`distro_redhat', `
/usr/sbin/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
+')
/usr/share/yumex/yumex-yum-backend -- gen_context(system_u:object_r:rpm_exec_t,s0)
/usr/share/yumex/yum_childtask\.py -- gen_context(system_u:object_r:rpm_exec_t,s0)
Or:
--- refpolicy-04062012/policy/modules/contrib/rpm.fc 2012-06-20 17:47:29.249999920 +0200
+++ refpolicy-04062012-packagekit-fc-standard/policy/modules/contrib/rpm.fc 2012-06-20 17:46:05.436179710 +0200
@@ -13,7 +13,8 @@
/usr/sbin/system-install-packages -- gen_context(system_u:object_r:rpm_exec_t,s0)
/usr/sbin/yum-updatesd -- gen_context(system_u:object_r:rpm_exec_t,s0)
-/usr/sbin/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
+
+/usr/libexec/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
/usr/share/yumex/yumex-yum-backend -- gen_context(system_u:object_r:rpm_exec_t,s0)
/usr/share/yumex/yum_childtask\.py -- gen_context(system_u:object_r:rpm_exec_t,s0)
Hello again.
I also noticed that the working directories that it needs to access as a
minimum condition also seems broken, according to the latest version
available:
--- refpolicy-04062012/policy/modules/contrib/rpm.fc 2012-06-21 01:58:45.505739558 +0200
+++ refpolicy-04062012-packagekit-fc-standard/policy/modules/contrib/rpm.fc 2012-06-21 02:06:21.475277343 +0200
@@ -7,13 +7,13 @@
/usr/bin/yum -- gen_context(system_u:object_r:rpm_exec_t,s0)
+/usr/libexec/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
/usr/libexec/yumDBUSBackend.py -- gen_context(system_u:object_r:rpm_exec_t,s0)
/usr/sbin/yum-complete-transaction -- gen_context(system_u:object_r:rpm_exec_t,s0)
/usr/sbin/system-install-packages -- gen_context(system_u:object_r:rpm_exec_t,s0)
/usr/sbin/yum-updatesd -- gen_context(system_u:object_r:rpm_exec_t,s0)
-/usr/sbin/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
/usr/share/yumex/yumex-yum-backend -- gen_context(system_u:object_r:rpm_exec_t,s0)
/usr/share/yumex/yum_childtask\.py -- gen_context(system_u:object_r:rpm_exec_t,s0)
@@ -27,9 +27,11 @@ ifdef(`distro_redhat', `
/usr/sbin/up2date -- gen_context(system_u:object_r:rpm_exec_t,s0)
')
+/var/cache/PackageKit(/.*)? gen_context(system_u:object_r:rpm_var_cache_t,s0)
/var/cache/yum(/.*)? gen_context(system_u:object_r:rpm_var_cache_t,s0)
/var/lib/alternatives(/.*)? gen_context(system_u:object_r:rpm_var_lib_t,s0)
+/var/lib/PackageKit(/.*)? gen_context(system_u:object_r:rpm_var_lib_t,s0)
/var/lib/rpm(/.*)? gen_context(system_u:object_r:rpm_var_lib_t,s0)
/var/lib/yum(/.*)? gen_context(system_u:object_r:rpm_var_lib_t,s0)
Besides that, it might need permissions related to the network, but I
suppose that can be managed on a per-site or per-distribution basis (or
otherwise by using booleans).
On Wed, 2012-06-20 at 17:56 +0200, Guido Trentalancia wrote:
> It seems that the current refpolicy file contexts are using a wrong (or
> at least rather obsolete) location for the PackageKit daemon executable.
>
> It's standard location is in /usr/libexec and not /usr/sbin (FC17 also
> apparently uses the latter).
>
> Finally, consider that PackageKit should now ship also with
> distributions other than Redhat.
>
> So, either of these two patches, would probably be a good move:
>
> --- refpolicy-04062012/policy/modules/contrib/rpm.fc 2011-09-09 18:29:23.592611047 +0200
> +++ refpolicy-04062012-packagekit-fc/policy/modules/contrib/rpm.fc 2012-06-19 19:12:07.420661407 +0200
> @@ -13,7 +13,13 @@
>
> /usr/sbin/system-install-packages -- gen_context(system_u:object_r:rpm_exec_t,s0)
> /usr/sbin/yum-updatesd -- gen_context(system_u:object_r:rpm_exec_t,s0)
> +
> +ifndef(`distro_redhat', `
> +/usr/libexec/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
> +')
> +ifdef(`distro_redhat', `
> /usr/sbin/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
> +')
>
> /usr/share/yumex/yumex-yum-backend -- gen_context(system_u:object_r:rpm_exec_t,s0)
> /usr/share/yumex/yum_childtask\.py -- gen_context(system_u:object_r:rpm_exec_t,s0)
>
> Or:
>
> --- refpolicy-04062012/policy/modules/contrib/rpm.fc 2012-06-20 17:47:29.249999920 +0200
> +++ refpolicy-04062012-packagekit-fc-standard/policy/modules/contrib/rpm.fc 2012-06-20 17:46:05.436179710 +0200
> @@ -13,7 +13,8 @@
>
> /usr/sbin/system-install-packages -- gen_context(system_u:object_r:rpm_exec_t,s0)
> /usr/sbin/yum-updatesd -- gen_context(system_u:object_r:rpm_exec_t,s0)
> -/usr/sbin/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
> +
> +/usr/libexec/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
>
> /usr/share/yumex/yumex-yum-backend -- gen_context(system_u:object_r:rpm_exec_t,s0)
> /usr/share/yumex/yum_childtask\.py -- gen_context(system_u:object_r:rpm_exec_t,s0)
On 06/20/12 21:09, Guido Trentalancia wrote:
> Hello again.
>
> I also noticed that the working directories that it needs to access as a
> minimum condition also seems broken, according to the latest version
> available:
Merged.
> --- refpolicy-04062012/policy/modules/contrib/rpm.fc 2012-06-21 01:58:45.505739558 +0200
> +++ refpolicy-04062012-packagekit-fc-standard/policy/modules/contrib/rpm.fc 2012-06-21 02:06:21.475277343 +0200
> @@ -7,13 +7,13 @@
>
> /usr/bin/yum -- gen_context(system_u:object_r:rpm_exec_t,s0)
>
> +/usr/libexec/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
> /usr/libexec/yumDBUSBackend.py -- gen_context(system_u:object_r:rpm_exec_t,s0)
>
> /usr/sbin/yum-complete-transaction -- gen_context(system_u:object_r:rpm_exec_t,s0)
>
> /usr/sbin/system-install-packages -- gen_context(system_u:object_r:rpm_exec_t,s0)
> /usr/sbin/yum-updatesd -- gen_context(system_u:object_r:rpm_exec_t,s0)
> -/usr/sbin/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
>
> /usr/share/yumex/yumex-yum-backend -- gen_context(system_u:object_r:rpm_exec_t,s0)
> /usr/share/yumex/yum_childtask\.py -- gen_context(system_u:object_r:rpm_exec_t,s0)
> @@ -27,9 +27,11 @@ ifdef(`distro_redhat', `
> /usr/sbin/up2date -- gen_context(system_u:object_r:rpm_exec_t,s0)
> ')
>
> +/var/cache/PackageKit(/.*)? gen_context(system_u:object_r:rpm_var_cache_t,s0)
> /var/cache/yum(/.*)? gen_context(system_u:object_r:rpm_var_cache_t,s0)
>
> /var/lib/alternatives(/.*)? gen_context(system_u:object_r:rpm_var_lib_t,s0)
> +/var/lib/PackageKit(/.*)? gen_context(system_u:object_r:rpm_var_lib_t,s0)
> /var/lib/rpm(/.*)? gen_context(system_u:object_r:rpm_var_lib_t,s0)
> /var/lib/yum(/.*)? gen_context(system_u:object_r:rpm_var_lib_t,s0)
>
> Besides that, it might need permissions related to the network, but I
> suppose that can be managed on a per-site or per-distribution basis (or
> otherwise by using booleans).
>
> On Wed, 2012-06-20 at 17:56 +0200, Guido Trentalancia wrote:
>> It seems that the current refpolicy file contexts are using a wrong (or
>> at least rather obsolete) location for the PackageKit daemon executable.
>>
>> It's standard location is in /usr/libexec and not /usr/sbin (FC17 also
>> apparently uses the latter).
>>
>> Finally, consider that PackageKit should now ship also with
>> distributions other than Redhat.
>>
>> So, either of these two patches, would probably be a good move:
>>
>> --- refpolicy-04062012/policy/modules/contrib/rpm.fc 2011-09-09 18:29:23.592611047 +0200
>> +++ refpolicy-04062012-packagekit-fc/policy/modules/contrib/rpm.fc 2012-06-19 19:12:07.420661407 +0200
>> @@ -13,7 +13,13 @@
>>
>> /usr/sbin/system-install-packages -- gen_context(system_u:object_r:rpm_exec_t,s0)
>> /usr/sbin/yum-updatesd -- gen_context(system_u:object_r:rpm_exec_t,s0)
>> +
>> +ifndef(`distro_redhat', `
>> +/usr/libexec/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
>> +')
>> +ifdef(`distro_redhat', `
>> /usr/sbin/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
>> +')
>>
>> /usr/share/yumex/yumex-yum-backend -- gen_context(system_u:object_r:rpm_exec_t,s0)
>> /usr/share/yumex/yum_childtask\.py -- gen_context(system_u:object_r:rpm_exec_t,s0)
>>
>> Or:
>>
>> --- refpolicy-04062012/policy/modules/contrib/rpm.fc 2012-06-20 17:47:29.249999920 +0200
>> +++ refpolicy-04062012-packagekit-fc-standard/policy/modules/contrib/rpm.fc 2012-06-20 17:46:05.436179710 +0200
>> @@ -13,7 +13,8 @@
>>
>> /usr/sbin/system-install-packages -- gen_context(system_u:object_r:rpm_exec_t,s0)
>> /usr/sbin/yum-updatesd -- gen_context(system_u:object_r:rpm_exec_t,s0)
>> -/usr/sbin/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
>> +
>> +/usr/libexec/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
>>
>> /usr/share/yumex/yumex-yum-backend -- gen_context(system_u:object_r:rpm_exec_t,s0)
>> /usr/share/yumex/yum_childtask\.py -- gen_context(system_u:object_r:rpm_exec_t,s0)
>
>
>
> _______________________________________________
> 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, 2012-06-26 at 09:44 -0400, Christopher J. PeBenito wrote:
> On 06/20/12 21:09, Guido Trentalancia wrote:
> > Hello again.
> >
> > I also noticed that the working directories that it needs to access as a
> > minimum condition also seems broken, according to the latest version
> > available:
>
> Merged.
>
> > --- refpolicy-04062012/policy/modules/contrib/rpm.fc 2012-06-21 01:58:45.505739558 +0200
> > +++ refpolicy-04062012-packagekit-fc-standard/policy/modules/contrib/rpm.fc 2012-06-21 02:06:21.475277343 +0200
> > @@ -7,13 +7,13 @@
> >
> > /usr/bin/yum -- gen_context(system_u:object_r:rpm_exec_t,s0)
> >
> > +/usr/libexec/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
> > /usr/libexec/yumDBUSBackend.py -- gen_context(system_u:object_r:rpm_exec_t,s0)
> >
> > /usr/sbin/yum-complete-transaction -- gen_context(system_u:object_r:rpm_exec_t,s0)
> >
> > /usr/sbin/system-install-packages -- gen_context(system_u:object_r:rpm_exec_t,s0)
> > /usr/sbin/yum-updatesd -- gen_context(system_u:object_r:rpm_exec_t,s0)
> > -/usr/sbin/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
What about backwards compatibility? This will break systems that have
this binary still in /usr/sbin/
On 06/26/12 09:50, Dominick Grift wrote:
> On Tue, 2012-06-26 at 09:44 -0400, Christopher J. PeBenito wrote:
>> On 06/20/12 21:09, Guido Trentalancia wrote:
>>> Hello again.
>>>
>>> I also noticed that the working directories that it needs to access as a
>>> minimum condition also seems broken, according to the latest version
>>> available:
>>
>> Merged.
>>
>>> --- refpolicy-04062012/policy/modules/contrib/rpm.fc 2012-06-21 01:58:45.505739558 +0200
>>> +++ refpolicy-04062012-packagekit-fc-standard/policy/modules/contrib/rpm.fc 2012-06-21 02:06:21.475277343 +0200
>>> @@ -7,13 +7,13 @@
>>>
>>> /usr/bin/yum -- gen_context(system_u:object_r:rpm_exec_t,s0)
>>>
>>> +/usr/libexec/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
>>> /usr/libexec/yumDBUSBackend.py -- gen_context(system_u:object_r:rpm_exec_t,s0)
>>>
>>> /usr/sbin/yum-complete-transaction -- gen_context(system_u:object_r:rpm_exec_t,s0)
>>>
>>> /usr/sbin/system-install-packages -- gen_context(system_u:object_r:rpm_exec_t,s0)
>>> /usr/sbin/yum-updatesd -- gen_context(system_u:object_r:rpm_exec_t,s0)
>>> -/usr/sbin/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
>
> What about backwards compatibility? This will break systems that have
> this binary still in /usr/sbin/
Right. I've restored the line.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Tue, 2012-06-26 at 10:06 -0400, Christopher J. PeBenito wrote:
> On 06/26/12 09:50, Dominick Grift wrote:
> > On Tue, 2012-06-26 at 09:44 -0400, Christopher J. PeBenito wrote:
> >> On 06/20/12 21:09, Guido Trentalancia wrote:
> >>> Hello again.
> >>>
> >>> I also noticed that the working directories that it needs to access as a
> >>> minimum condition also seems broken, according to the latest version
> >>> available:
> >>
> >> Merged.
> >>
> >>> --- refpolicy-04062012/policy/modules/contrib/rpm.fc 2012-06-21 01:58:45.505739558 +0200
> >>> +++ refpolicy-04062012-packagekit-fc-standard/policy/modules/contrib/rpm.fc 2012-06-21 02:06:21.475277343 +0200
> >>> @@ -7,13 +7,13 @@
> >>>
> >>> /usr/bin/yum -- gen_context(system_u:object_r:rpm_exec_t,s0)
> >>>
> >>> +/usr/libexec/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
> >>> /usr/libexec/yumDBUSBackend.py -- gen_context(system_u:object_r:rpm_exec_t,s0)
> >>>
> >>> /usr/sbin/yum-complete-transaction -- gen_context(system_u:object_r:rpm_exec_t,s0)
> >>>
> >>> /usr/sbin/system-install-packages -- gen_context(system_u:object_r:rpm_exec_t,s0)
> >>> /usr/sbin/yum-updatesd -- gen_context(system_u:object_r:rpm_exec_t,s0)
> >>> -/usr/sbin/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
> >
> > What about backwards compatibility? This will break systems that have
> > this binary still in /usr/sbin/
Backward-compatibility should never come at the expense of compatibility
with current situation.
Backward-compatibility should only be considered if it can coexist with
compatibility with recent versions.
> Right. I've restored the line.
See above.
Regards,
Guido
On Tue, 2012-06-26 at 21:39 +0200, Guido Trentalancia wrote:
>
> Backward-compatibility should only be considered if it can coexist with
> compatibility with recent versions.
It can coexist.
> > Right. I've restored the line.
>
> See above.
>
> Regards,
>
> Guido
>
Hello again.
On Tue, 2012-06-26 at 21:45 +0200, Dominick Grift wrote:
> On Tue, 2012-06-26 at 21:39 +0200, Guido Trentalancia wrote:
>
> >
> > Backward-compatibility should only be considered if it can coexist with
> > compatibility with recent versions.
>
> It can coexist.
Needless to say, if both lines coexist without a conditional expression
on the version (not supported at the moment), in the absence of any hash
verification (should fit well as an optional last field in a future
version of the file-contexts definitions), an hijacked copy of
policykitd installed in the other location would be able to run with the
same permissions as the trusted packagekitd without the user noticing
anything.
> > > Right. I've restored the line.
Least but not last, it probably was just a bug, as since version 0.1.0
through 0.7.4, they all install by default in sbindir (which defaults
to /usr/sbin).
> > See above.
Regards,
Guido
On Wed, 2012-06-27 at 18:59 +0200, Guido Trentalancia wrote:
> an hijacked copy of
> policykitd installed in the other location would be able to run with the
> same permissions as the trusted packagekitd without the user noticing
> anything.
It would not have to be installed in the other location for it to be
able to do damage. Same thing could also happen with a single location.
This is why it is important to only install packages from trusted
sources. SELinux is no substitute for that imho.
Think about it, a distro like Fedora has modules for all kinds of
services and applications of which many you may not even have installed:
example:
# semanage fcontext -l | grep unconfined_exec_t
/usr/bin/vncserver regular file
system_u:object_r:unconfined_exec_t:s0
/usr/sbin/xrdp regular file
system_u:object_r:unconfined_exec_t:s0
/usr/sbin/xrdp-sesman regular file
system_u:object_r:unconfined_exec_t:s0
On Tue, 2012-06-26 at 10:06 -0400, Christopher J. PeBenito wrote:
[cut]
> >>> --- refpolicy-04062012/policy/modules/contrib/rpm.fc 2012-06-21 01:58:45.505739558 +0200
> >>> +++ refpolicy-04062012-packagekit-fc-standard/policy/modules/contrib/rpm.fc 2012-06-21 02:06:21.475277343 +0200
> >>> @@ -7,13 +7,13 @@
> >>>
> >>> /usr/bin/yum -- gen_context(system_u:object_r:rpm_exec_t,s0)
> >>>
> >>> +/usr/libexec/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
> >>> /usr/libexec/yumDBUSBackend.py -- gen_context(system_u:object_r:rpm_exec_t,s0)
> >>>
> >>> /usr/sbin/yum-complete-transaction -- gen_context(system_u:object_r:rpm_exec_t,s0)
> >>>
> >>> /usr/sbin/system-install-packages -- gen_context(system_u:object_r:rpm_exec_t,s0)
> >>> /usr/sbin/yum-updatesd -- gen_context(system_u:object_r:rpm_exec_t,s0)
> >>> -/usr/sbin/packagekitd -- gen_context(system_u:object_r:rpm_exec_t,s0)
> >
> > What about backwards compatibility? This will break systems that have
> > this binary still in /usr/sbin/
>
> Right. I've restored the line.
To be precise, it should have changed to libexecdir from sbindir at
0.6.6 but unfortunately at the moment, there is probably nothing such as
a conditional expression
ifdef('`distro_x', version_up_to`
')
So, Dominick is right, there is no other choice at the moment.
Regards,
Guido
Hello again Dominick.
On Wed, 2012-06-27 at 19:13 +0200, Dominick Grift wrote:
> On Wed, 2012-06-27 at 18:59 +0200, Guido Trentalancia wrote:
> > an hijacked copy of
> > policykitd installed in the other location would be able to run with the
> > same permissions as the trusted packagekitd without the user noticing
> > anything.
>
> It would not have to be installed in the other location for it to be
> able to do damage. Same thing could also happen with a single location.
Yes, although it's a little bit more difficult to detect. That's why, I
was suggesting to introduce an optional last field for enforceable
hash-based digest verification (at that point only heuristic run-time
analysis would be missing).
> This is why it is important to only install packages from trusted
> sources. SELinux is no substitute for that imho.
Yes, it's an unsigned package therefore an hijacked version could be
easily be injected while in transit on the network(s) as a substitute
for the authentic version by a man in the middle.
The last thing I can add is that 0.6.x is apparently considered as
stable (it should follow the even/stable odd/unstable rule), therefore
you now have all the information to make an (informed) choice about it.
> Think about it, a distro like Fedora has modules for all kinds of
> services and applications of which many you may not even have installed:
I am not using Fedora.
> example:
>
> # semanage fcontext -l | grep unconfined_exec_t
> /usr/bin/vncserver regular file
> system_u:object_r:unconfined_exec_t:s0
> /usr/sbin/xrdp regular file
> system_u:object_r:unconfined_exec_t:s0
> /usr/sbin/xrdp-sesman regular file
> system_u:object_r:unconfined_exec_t:s0
It should possible to turn off individual modules as long as there is
enough granularity in modules. But, to be honest, I have not tested
whether or not that always behaves as expected.
Regards,
Guido