Re: [RFC][PATCH] selinux: introduce support for deferred mapping of inode security contexts

[Joshua Brindle <method@gentoo.org>]

Stephen Smalley wrote:
> On Thu, 2006-05-18 at 20:14 +0200, Thomas Bleher wrote:
>   
>> Thank you for your explanation.
>> I see that these are very difficult issues, but I must admit that I
>> still feel very uneasy about the proposed changes.
>>
>> So let me suggest one more possibility:
>> rpm installs the package, puts the labels on disk and afterwards
>> installs the policy (like Dan proposed originally). 
>> EXCEPT: Whenever rpm finds that the label it wants to put on disk is not
>> valid in the current policy, it labels the file as unlabeled_t (or some
>> other special label). After rpm has installed the policy, it relabels
>> the guilty files. This adds no overhead - rpm already knows the paths and
>> the labels, and it would have had to visit the files anyway to verify
>> their labels -, looks exactly the same from the outside, doesn't require
>> kernel changes and makes it possible to later restrict rpm.
>>
>> Now, you can't decline such an offer, can you? ;-)
>>
>> Or am I missing something fundamental here?
>>     
> In the labelpriv model, rpm doesn't have to visit the individual files
> afterward in the common case; it just calls security_check_context(3) on
> each distinct context stored in the rpm header (once per context, not
> per file) after the module insertion phase, and if any of them are still
> invalid (the uncommon case), rpm then takes corrective action (whether
> that means relabeling files that had those invalid labels to truly be
> unlabeled_t, removing those files, or reverting the install altogether -
> the latter seems cleanest to me).  If we can't get a guarantee that rpm
> will perform such checking and take corrective action, then I'd agree
> that the kernel change is a no-go.
>   
Or just use matchpathcon() to label it. The installed file contexts are 
implicitly trusted anyway, I don't see how it could hurt to revert to 
defaults. Then again, an unlabeled file after the reload could indicate 
an error in the package, policy, etc. On this note, how do you expect 
this helper to work? I don't think that rpm maintains a list of files 
per-transaction and since the post-script order can't be guaranteed you 
never know when a particular policy has been reloaded (mutual dependency 
problem, mta policy declares sendmail_t but sendmail package puts down 
the file). There are probably other cases where this is problematic.

> With regard to restricting rpm, under both models, rpm is being allowed
> to set down unlabeled_t files and to insert policy modules.  Restricting
> rpm meaningfully under either model requires fine-grained mediation of
> what those policy modules may contain, which requires the use of the
> policy management server as the libsemanage back end to enforce such
> mediation.  Restricting rpm meaningfully under either model also
> requires decomposition of rpm, so that not all of rpm has to run with
> the same rights and the core rpm processing can run with different
> rights depending on the package characteristics.  Given such mediation
> and decomposition, having a small rpm helper in its own domain that
> verifies that the header contexts are valid after module insertion,
> taking corrective action if necessary, would address the linkage between
> the header contexts and the module contents.
>   
Right, unfortunately it looks like rpm will have this capability long 
before the policy management server is ready to be dropped in. We also 
haven't solved the hierarchal -policy-in-refpolicy problem which is 
necessary for any meaningful policy enforcement.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.