[Rpm-maint] [PATCH 1/2] Extending rpm plugin interface, part 1
elena.reshetova at intel.com
Fri Nov 9 12:27:09 UTC 2012
>> Oh and one other thing I noticed just now that'll need further thought:
>> currently the script setup hook only runs for external scripts, but
>> not the
> embedded Lua-scripts. Which are getting more and more common...
>> They'll obviously need to be handled quite differently as they run
> the rpm process itself, ie fork() + exec() does not occur.
> Yes, I don't currently have a very good idea how this case should be
> handled. The idea of script hook is that it sets the needed security
> context, but we obviously can't do this for lua case unless we want to
> drop the whole rpm security context.
> As a temporal and draconic measure we can compile rpm without lua
> support to close this hole, but it is no-go in the future since it is
> getting more and more usage. I guess this is one of the things that I
> need to think more about.
>In case of SELinux, AFAICS a process can change its own context back and
forth, IF permitted by the policy. So at least in theory it should possible
to switch to a different context while executing a scriptlet and then switch
back to the original context.
It isn't so easy for Smack for example (and for a good reason) and I believe
SELinux won't use this functionality for this kind of purpose. A process can
change its security context in Smack, if it has CAP_MAC_ADMIN, so rpm (a
trusted process) can have this cap and then drop the credentials when
running lua script from untrusted package. However, we also want to drop
CAP_MAC_ADMIN (and all the rest of sensitive caps) for such lua script
(otherwise it can setup whatever context it wants for itself), and after
such drop, and after lua script execution is done, rpm can't get its own
security context back (because CAP_MAC_ADMIN is lost). This actually makes
sense since once you run untrusted code in the same process space you can't
really guarantee that you can safely come back and run (in the same process)
a trusted code with high privileges. Same logic would apply if we don't
speak about LSMs, but traditional Linux DAC. Rpm usually runs as root with
all POSIX caps, but suppose we want to drop the sensitive caps while running
untrusted lua scripts or even simply run them under different uid/gid. How
do we do this with lua scripts currently?
>Perhaps the script hook should just follow the common pre/post-hook pattern
of the other hooks afterall: pre-hook would just replace the current setup
hook, and post-hook would run after the script got executed. If we add an
extra argument to notify the hooks whether it's an internal or external
script >(or a more generic "flags" argument to allow passing more such bits
later), the plugin(s) should be able to figure out what to do about it.
This would be good, if we can indeed manipulate the context freely, but
because of above we really can't.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7220 bytes
Desc: not available
More information about the Rpm-maint