[Rpm-maint] [RFC PATCH] install selinux policies from package header

Mark Hatle mark.hatle at windriver.com
Wed Aug 26 20:26:18 UTC 2009

This is related to the early install.  Cross-install is simple a variant of the 
regular installer use-case... only you can't actually run software within the 

How would you do this if you were doing a cross install.  I.e. installing a 
Power system from an Intel based system?  (You can't run software in the chroot, 
because the chroot contains software that is incompatible with the CPU you are 
installing from.)  You will need to run the "semodule" program on the host, but 
ensure all of the data structures and such are configured for the target 


Steve Lawrence wrote:
> On Wed, 2009-08-26 at 10:55 +0300, Panu Matilainen wrote:
>> Finally getting back to this after vacations and all, apologies for the 
>> lenghty delay...
>> On Tue, 7 Jul 2009, Joshua Brindle wrote:
>>> Panu Matilainen wrote:
>>>> Hi,
>>>> On Mon, 6 Jul 2009, Stephen Lawrence wrote:
>>> <snip>
>>>>> Obviously I'm glossing over many implementation details that would need
>>>>> to be worked out. The point of this email is strictly to get feedback on
>>>>> our approach. Below is a patch that implements the beginnings of what I
>>>>> describe above. Any and all feedback is appreciated.
>>>> Loading the policies at pre-trans stage is how it needs to be done, but
>>>> calling out to semodule is a no-go. It'd work for upgrades more or less,
>>>> but on initial installation (to an empty chroot) the pre-trans stage
>>>> happens in a complete void, there's just nothing there, not even /bin/sh.
>>>> It needs to be done through API calls, no way around it. On the surface
>>>> it doesn't look that bad, skipping over details like error handling,
>>>> rpmtsLoadPolicy() might be something like:
>>> We wanted to fork/exec semodule because there would be a domain transition 
>>> and we could give semodule permission to update the policy without giving rpm 
>>> that permission. This feeds in to our ultimate desire to break RPM in to less 
>>> privileged pieces.
>>> FWIW the library executes apps as well, for example setfiles is run to 
>>> validate the file contexts files when new policy is loaded. This is how we 
>>> break out functionality in SELinux to let pieces be less privileged. I don't 
>>> think we can attain our end goals if fork/exec is never allowed.
>> It's not so much a matter of allowing or not, but what's possible. 
>> Chroot'ed operation (initial install and otherwise) is not an oddball 
>> corner case but one of the most important use-cases for rpm, and needs to 
>> be taken into account as such everywhere.
>> But ok... looking that little bit closer: unlike %pretrans scriptlets, the 
>> policy load happens *outside* any chroot using the hosts 
>> /usr/sbin/semodule always. This changes the landscape considerably and 
>> mostly eliminates my "early bootstrap" concerns, sorry for missing that 
>> previously.
> Although we don't do it currently, when the --root option is given, we
> do plan to chroot(2). This is necessary to ensure that the policy that
> is changed is the one in the chroot rather than the one in the parent
> system. So your 'early bootstrap' example is still an issue. That said,
> we do have an idea as to how we can solve this.
>> Some odds and ends that come to mind:
>> - What to do in various failure cases, such as to-be-installed packages
>>    containing loadable policies but /usr/sbin/semodule doesn't exist on the
>>    host and --nopolicy was not specified? Aborting the transaction in
>>    while already in rpmtsRun() seems rather unfriendly when the situation
>>    is detectable earlier. Dynamic rpmlib() dependency might be one option.
> In the cases where semodule does not exist (e.g. initial install or
> install into an empty chroot), we will automatically fall back to using
> libsemanage. We believe this is a good compromise between added
> separation with semodule in the common case (normal rpm installations)
> and allowing empty chroot/initial installations to still work.
>> - The /usr/sbin/semodule path should be macroized (a no-brainer)
> Agreed.
>> - Is there some particular reason why installPolicy() is in the PSM?
>>    It seems like an unnecessary complication to me, as AFAICT the operation
>>    doesn't need any of the other PSM machinery (unlike %pretrans
>>    which uses PSM to do chroot in+out + executing scriptlets from headers)
> Agreed. This was done when we were fairly unfamiliar with the rpm code.
> We realized the over complication and have changed it to a more
> reasonable method. This change, as well as the semodule macro and
> libsemanage fallback, will be in our next patchset.
> Thanks,
> - Steve
> _______________________________________________
> Rpm-maint mailing list
> Rpm-maint at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-maint

More information about the Rpm-maint mailing list