On 11/20/2012 05:27 PM, Guillem Jover wrote:
Hi!
Some context for the rpm folks. While looking into improving SELinux
support in dpkg, I noticed that dpkg is not setting a new execution
context when running the package maintainer scripts (package scriptlets
in rpm lingo, I think). And when checking how to implement it, it seemed
that reusing something like the current rpm_execcon() would be best,
and Stephen seemed to agree. For more details, see the thread starting
at <http://marc.info/?t=135236358700001&r=1&w=2>.
Having checked the rpm code, and the mailing list, it seems like this
new function would make it easy to be used there too for stuff like
the Lua scriptlets (if desired), and might make it easier also to
switch to the new rpm plugins framework (?).
I've discarded the verified argument for the new function because that
seemed best handled from the rpm side, and in any case seemed unrelated
to the execution context. I'm not entirely convinced about the function
name though, as it could be confused as applying a context to a path on
the filesystem. And I've not marked rpm_execcon() as deprecated because
it might be annoying at the beginning, but would change that if you think
it makes sense.
In any case, here's a patch adding such new function. For dpkg, given
that it has never set a new context up to now, I'd only make use of the
function if it's available in libselinux, as I don't think it's worth it
to ship an embedded copy. For rpm, I guess it could switch to use the
function also if available and fallback to rpm_execcon() otherwise. After
a while the rpm_execcon() function could be removed from libselinux, on
the next ABI break, as I understand was the plan anyway (?).
(The patch might not apply w/o the man page cleanup series.)
So, what do you think?
No objections to replacing and/or axing rpm_execcon(), AFAIR its simply
a convenience-function around setexeccon() and one that rpm will (have
to) cease to use in near future anyway in order to move all the selinux
specifics into a plugin.
I dont have objections for the suggested interface as such either, it'd
be convenient for what rpm will need for regular scriptlets. It wont
help with rpm's embedded Lua-scriptlets as they run in-process though.
Rpm might well start forking their execution, but even then the
transition to another selinux context (or similar security mechanism)
needs to happen without an exec() for the embedded scripts.