Re: We are attempting once again to split policy out into individual RPMS.

[Joshua Brindle <method@gentoo.org>]

Karl MacMillan wrote:
>>> The comparison to uid/gid is bogus, uid/gid are unambiguous, file 
>>> contexts are ordered by specificity because multiple regexes can match 
>>> any given filename. The file_contexts *must* be combined and ordered 
>>> prior to labeling, and if multiple policy packages are being installed 
>>> within a set those must all be included as well. matchpathcon does not 
>>> currently have the sorting mechanism that libsemanage does to properly 
>>> combine policy package file contexts.
>>>       
>> By moving the policy to being maintained by the package maintainer, it's
>> moving towards having the file context be unambiguous as well.
>> Otherwise, the packager really has no control.
>>
>>     
>
> Both of these seem like positive changes, particularly having the
> package maintainers take responsibility for the SELinux policy
> associated with their package.
>
> Also, how ambiguous are the application file contexts now anyway? Josh,
> you are claiming that the labeling requires all of the file contexts to
> be combined, but for most applications that come with policy the file
> contexts are already a) specific and b) cover the majority of the files
> provided by that application. The more general file contexts are most
> useful for applications without policy.
>   
Having unambiguous contexts for every package would not be scalable. 
Most apps have some sort of fallback now (eg., mysql installs libraries 
but doesn't label them, and shouldn't, the base library labeling should 
take care of them). I imagine there are very few packages that have 
entirely self contained file contexts files. Anything that installs 
libraries, man pages, info pages, binaries without unique labels 
(mysqladmin doesn't need its own label, only the daemon binary), etc.

Not only does adding specific entries for every file in every package 
not scale but it breaks encapsulation (why should a policy need to know 
that /bin is bin_t, we intentionally abstracted that away in policy, why 
regress in file contexts).


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