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

Joshua Brindle method at manicmethod.com
Fri Aug 28 14:24:14 UTC 2009


Panu Matilainen wrote:
> On Wed, 26 Aug 2009, Stephen Lawrence wrote:
>
<snip>

>> 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.
>
> Doesn't loading the policies always affect the "parent" system too as
> the policies gets loaded into the kernel? How do you plan to deal with
> that?
>

Yes, that is why we would not reload policy if in a chroot, only build it.

>>> 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.
>
> Mm... I'm not too extatic about having two code paths to do the same
> thing, especially when they drag in a pile of new dependencies to rpm
> itself :-/ But the bigger worry here:
>

It is very important to us that we be able to break rpm privileges up into 
smaller chunks. A design that requires RPM have full power over the policy 
unconditionally isn't very helpful to that goal. We want the fallback for the 
corner cases such as chroot and cross-installs but the primary mechanism should 
be exec'ing tools privileged to rebuild and reload policy.

> On Tue, 7 Jul 2009, Joshua Brindle wrote:
>> 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.
>
> If libsemanage requires exec()'ing anything at all to load policies, it
> will not work in the case of initial install into chroot because there's
> absolutely nothing there to exec() at the time when policy loading is
> supposed to happen.
>

Well we can fix this, it is our codebase, and now that we know it is an issue it 
will be on the map going forward.

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



More information about the Rpm-maint mailing list