[Rpm-maint] [PATCH 1/2] Extending rpm plugin interface, part 1

[Panu Matilainen]

On 11/09/2012 02:27 PM, Reshetova, Elena wrote:
>>> 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
>>> within
>> 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.

Note "in theory" in the above :) libselinux has an API for it, I dont 
know if there's anything that's actually allowed to flip the context 
back and forth:

/* Set the current security context to con.
    Note that use of this function requires that the entire application
    be trusted to maintain any desired separation between the old and new
    security contexts, unlike exec-based transitions performed via 
setexeccon.
    When possible, decompose your application and use setexeccon()+execve()
    instead. Note that the application may lose access to its open 
descriptors
    as a result of a setcon() unless policy allows it to use descriptors 
opened
    by the old context. */
extern int setcon(const security_context_t con);
extern int setcon_raw(const security_context_t con);

> 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?

Scripts run with all the powers that rpm itself has, and there's not a 
whole lot that can be done about it: scriptlets expect to, and often 
need to, do all sorts of crazy things.

The differences from regular exec()'ed scripts and Lua-ones are basically:
- As Lua scripts run in the rpm process space, some extra protection is 
needed, like saving + restoring current working directory, umask and 
preventing Lua scriptlet from exec()'ing or exit()'ing the process.
- There are no context switches for Lua scripts in SELinux world 
currently: Lua scripts run with rpm_exec_t context, "regular" scripts 
run with rpm_script_t. But both are practically omnipotent contexts, 
because they have to be.

>> 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.

Oh, I meant the common pre- and post-hook pattern seems like it would 
make sense for scripts too in any case, regardless of whether it helps 
solving the context issue. It *might* in the SELinux case, but a 
post-hook could have some other entirely different uses, and it'd make 
the whole thing a bit more symmetric :)

	- Panu -