Bug#685992: /usr/sbin/update-flashplugin-nonfree: Please restore selinux context after installing files
Let's not compare init scripts with dpkg scripts.
The issue at hand here is that dpkg, and dpkg scripts do not install
files with the correct context.
As a Fedora user, i am not very familiar with dpkg, but i can tell you
that rpm, and the rpm script mechanism are SELinux aware.
They use the matchpathcon(), and setfscreatecon() libselinux functions
to query what the security contexts of a to be installed object should
be, and to install objects with the security contexts returned by
matchpathcon() using setfscreatecon() or similar libselinux functions.
For inspiration, i would suggest one studies the SELinux commits in the
rpm repository.
If dpkg cannot, because it uses a different mechanism for dpkg script
than rpm does for rpm scripts, deal with those scripts in a similar way
then a other solution should be thought of.
For example create a hook that gets called in dpkg scripts if it is
determined that SElinux is enabled on the target system that runs
restoreon.
The idea is that policy defines/maintains a list with file context
specifications, restorecon and matchpathcon commands query hat list to
determine what a specified location should be labeled. Restorecon
additionally resets the context of a specified location according to
what is specified system wide in the file context specifications.
So its a one, or two step procedure:
prefered (not racy) (see libselinux:
http://selinuxproject.org/page/LibselinuxAPISummary )
matchpathcon() "object": determine what a specified "object" should be
labeled by querying the system wide file context specifications define
by security policy, and or admin
setfscreatecon() "object" (see man setfscreatecon): create the specified
object with the context that was returned by the matchpathcon()
function.
alternate (racy):
use the restorecon/setfiles "object" commands to reset the context of a
specified object to what is specified system wide in the file context
specifications define by policy, and admin
I would suggest one takes a good look at how rpm deals with this, and
apply their solution where applicable, because rpm has been doing this
for quite a while and so we can imagine that they have learned a lot and
adjusted to the optimal way of going things.
Reply to: