: fix packagekit file context (standard location for the daemon)
PATCH 1/1 : fix packagekit file context (standard location for the daemon)
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:
policy/modules/contrib/rpm.fc +6 -0
@@ -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:
policy/modules/contrib/rpm.fc +2 -1
@@ -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)
PATCH v2 1/1 : fix packagekit file context (standard location for the daemon)
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:
policy/modules/contrib/rpm.fc +3 -1
@@ -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).
Quoted 42 lines · Guido Trentalancia
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/libexecand 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:
policy/modules/contrib/rpm.fc +6
-0@@ -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:
policy/modules/contrib/rpm.fc +2
-1@@ -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)
PATCH v2 1/1 : fix packagekit file context (standard location for the daemon)
Quoted 5 lines · Guido Trentalancia
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.
Quoted 84 lines
policy/modules/contrib/rpm.fc +3
-1@@ -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).
Quoted 33 lines · Guido Trentalancia
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/libexecand 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:
policy/modules/contrib/rpm.fc +6
-0@@ -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:
policy/modules/contrib/rpm.fc line 20
Quoted 9 lines
policy/modules/contrib/rpm.fc +2
-1@@ -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
Signature · 3 lines
Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com
PATCH v2 1/1 : fix packagekit file context (standard location for the daemon)
Quoted 15 lines · Christopher J. PeBenito
Quoted 5 lines · Guido Trentalancia
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.
Quoted 6 lines
policy/modules/contrib/rpm.fc +0
-0@@ -7,13 +7,13 @@ /usr/bin/yum -- gen_context(system_u:object_r:rpm_exec_t,s0)
Quoted 8 lines
policy/modules/contrib/rpm.fc line 16
Quoted 8 lines
policy/modules/contrib/rpm.fc +1
-1+/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/
PATCH v2 1/1 : fix packagekit file context (standard location for the daemon)
Quoted 19 lines · Dominick Grift
Quoted 18 lines · Christopher J. PeBenito
Quoted 5 lines · Guido Trentalancia
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.
Quoted 9 lines
policy/modules/contrib/rpm.fc +1
-0@@ -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)
Quoted 8 lines
Quoted 5 lines
policy/modules/contrib/rpm.fc line 16
Quoted 5 lines
policy/modules/contrib/rpm.fc +0
-1/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.
Signature · 3 lines
Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com
PATCH v2 1/1 : fix packagekit file context (standard location for the daemon)
Quoted 20 lines · Christopher J. PeBenito
Quoted 19 lines · Dominick Grift
Quoted 18 lines · Christopher J. PeBenito
Quoted 5 lines · Guido Trentalancia
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.
Quoted 9 lines
policy/modules/contrib/rpm.fc +1
-0@@ -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)
Quoted 8 lines
Quoted 8 lines
Quoted 5 lines
policy/modules/contrib/rpm.fc line 16
Quoted 5 lines
policy/modules/contrib/rpm.fc +0
-1/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.
Quoted 1 line
Right. I've restored the line.
See above.
Regards,
Guido
PATCH v2 1/1 : fix packagekit file context (standard location for the daemon)
Quoted 3 lines · Guido Trentalancia
Backward-compatibility should only be considered if it can coexist with compatibility with recent versions.
It can coexist.
Quoted 8 lines
Quoted 1 line
Right. I've restored the line.
See above.
Regards,
Guido
PATCH v2 1/1 : fix packagekit file context (standard location for the daemon)
Hello again.
Quoted 7 lines · Dominick Grift
Quoted 3 lines · Guido Trentalancia
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.
Quoted 1 line
Quoted 1 line
Quoted 1 line
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).
Quoted 1 line
Quoted 1 line
See above.
Regards,
Guido
PATCH v2 1/1 : fix packagekit file context (standard location for the daemon)
Quoted 4 lines · Guido Trentalancia
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
PATCH v2 1/1 : fix packagekit file context (standard location for the daemon)
Hello again Dominick.
Quoted 8 lines · Dominick Grift
Quoted 4 lines · Guido Trentalancia
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).
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 9 lines
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
PATCH v2 1/1 : fix packagekit file context (standard location for the daemon)
In reply to Christopher J. PeBenitoOn Tue, 2012-06-26 at 10:06 -0400, Christopher J. PeBenito wrote:
[cut]
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
policy/modules/contrib/rpm.fc +1
-0@@ -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)
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
policy/modules/contrib/rpm.fc line 16
Quoted 3 lines
policy/modules/contrib/rpm.fc +0
-1/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