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

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

[Daniel J Walsh]

I had more meetings with the install and RPM team at Red Hat about 
splitting out policy into individual packages for RHEL5/FC6.  We had 
many discussions about possible ways of doing this including breaking 
out policy into separate packages, ie http_policy.rpm but this was 
discounted as it was seen as a policy explosion.  Also we discussed only 
doing the semodule as the last in the transaction but this ability is 
being de-emphasized in the installer, so it was thought to keep it 
simple and install the policy within each RPM that ships with policy, 
sort of the ldconfig model.

We need the ability for RPM to be able to write a file context on disk 
without the kernel verifying it.  The kernel should treat this as an 
unlabeled_t file. the same way it would if I ran

semodule -i XYZ.pp
restorecon /usr/bin/XYZ
semoduel -e XYZ

I don't think this is an unreasonable request to allow rpm_t to have the 
privilege of writing the "invalid" context to disk.

Secondly the rpm team would like to be able to execute the equivalent of 
matchpathcon(XYZ.pp)  IE be able to extract the FC file mapping from the 
policy package and combine it with the on disk representation to 
determine the file context to associate with the new files being put on 
disk.

At the end of the rpm install, postinstall would do an semodule -i XYZ.pp.

We want to start out with just a couple of packages shipping policy to 
prove the technology and then to allow third parties to ship using this 
method.

Dan







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

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

[Joshua Brindle]

Daniel J Walsh wrote:
> I had more meetings with the install and RPM team at Red Hat about 
> splitting out policy into individual packages for RHEL5/FC6.  We had 
> many discussions about possible ways of doing this including breaking 
> out policy into separate packages, ie http_policy.rpm but this was 
> discounted as it was seen as a policy explosion.  Also
How is it a policy explosion? What does that mean exactly?

> we discussed only doing the semodule as the last in the transaction 
> but this ability is being de-emphasized in the installer, so it was 
> thought to keep it simple and install the policy within each RPM that 
> ships with policy, sort of the ldconfig model.
>
de-emphasized by the installer?  Not sure I follow, rebuilding the 
policy every time is expensive and may get worse (policy server 
enforcement).

> We need the ability for RPM to be able to write a file context on disk 
> without the kernel verifying it.  The kernel should treat this as an 
> unlabeled_t file. the same way it would if I ran
>
> semodule -i XYZ.pp
> restorecon /usr/bin/XYZ
> semoduel -e XYZ
>
> I don't think this is an unreasonable request to allow rpm_t to have 
> the privilege of writing the "invalid" context to disk.
>
hrm, there was a previous conversation about this, which I can't find in 
the archives for some reason. I'm at a loss as to why this needs to be 
done. The policy package should be installed before the application and 
the labels will become valid before they are used to install/label the 
package files.
> Secondly the rpm team would like to be able to execute the equivalent 
> of matchpathcon(XYZ.pp)  IE be able to extract the FC file mapping 
> from the policy package and combine it with the on disk representation 
> to determine the file context to associate with the new files being 
> put on disk.
>
hrm, this is unreliable unless you are combining file contexts from all 
possible modules being installed. Any given RPM transaction can easily 
have multiple policy packages and this needs to be addressed.
> At the end of the rpm install, postinstall would do an semodule -i 
> XYZ.pp.
The ideal order is to install all the policy packages first (shouldn't 
be too hard to move them to the beginning of the ordered list) and after 
they are installed do a single transaction to install them all (you have 
to do something like this regardless due to mutual dependencies) and 
then proceed to regular packages. This seems much cleaner than the sort 
of hackery being described here.
>
> We want to start out with just a couple of packages shipping policy to 
> prove the technology and then to allow third parties to ship using 
> this method.
This is a good thing.


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

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

[Jeremy Katz]

On Tue, 2006-05-02 at 11:01 -0400, Joshua Brindle wrote:
> Daniel J Walsh wrote:
> > I had more meetings with the install and RPM team at Red Hat about 
> > splitting out policy into individual packages for RHEL5/FC6.  We had 
> > many discussions about possible ways of doing this including breaking 
> > out policy into separate packages, ie http_policy.rpm but this was 
> > discounted as it was seen as a policy explosion.  Also
> How is it a policy explosion? What does that mean exactly?

Package explosion. For every package in the "universe", there is more
metadata to be downloaded and more memory to be used.  Having to have a
separate subpackage for *every* package containing policy is madness.

> > we discussed only doing the semodule as the last in the transaction 
> > but this ability is being de-emphasized in the installer, so it was 
> > thought to keep it simple and install the policy within each RPM that 
> > ships with policy, sort of the ldconfig model.
> >
> de-emphasized by the installer?  Not sure I follow, rebuilding the 
> policy every time is expensive and may get worse (policy server 
> enforcement).

There's movement underway to split transactions into minimal closed
sets.  Which means that you're going to end up running semodule about as
many times as there are policy packages.  If this takes absurd amounts
of time, then people further get the impression that SELinux is an
impediment more than a help :(

> > Secondly the rpm team would like to be able to execute the equivalent 
> > of matchpathcon(XYZ.pp)  IE be able to extract the FC file mapping 
> > from the policy package and combine it with the on disk representation 
> > to determine the file context to associate with the new files being 
> > put on disk.
> >
> hrm, this is unreliable unless you are combining file contexts from all 
> possible modules being installed. Any given RPM transaction can easily 
> have multiple policy packages and this needs to be addressed.

The policy for a given package needs to be able to be contained to that
package.  Otherwise, it's pretty much impossible to sanely handle policy
in anything other than the huge blob that there is now[1].  Saying
otherwise is like saying that the uid/gid that owns a file should be
able to be specified by combining things from multiple packages.

> > At the end of the rpm install, postinstall would do an semodule -i 
> > XYZ.pp.
> The ideal order is to install all the policy packages first (shouldn't 
> be too hard to move them to the beginning of the ordered list) and after 
> they are installed do a single transaction to install them all (you have 
> to do something like this regardless due to mutual dependencies) and 
> then proceed to regular packages. This seems much cleaner than the sort 
> of hackery being described here.

If policy packages require running a tool for the policy to be active,
then they fundamentally cannot be at the beginning of a transaction as
the package containing, eg, semodule will need to be installed too.  And
the dep tree cascades down from there.  Plus, special casing policy
packages to be different from every other piece of software shipped is
more hack-ish, not less.

Jeremy

[1] And while it's a huge blob, there will continue to be little to no
movement on actually ensuring that developers develop and maintain their
own policy as a manner of course.  It'll just be that thing that some
other person does.  Which, frankly, doesn't scale any better than it did
2.5 years ago when I said it doesn't work at all.

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

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

[Joshua Brindle]

Jeremy Katz wrote:
> On Tue, 2006-05-02 at 11:01 -0400, Joshua Brindle wrote:
>   
>> Daniel J Walsh wrote:
>>     
>>> I had more meetings with the install and RPM team at Red Hat about 
>>> splitting out policy into individual packages for RHEL5/FC6.  We had 
>>> many discussions about possible ways of doing this including breaking 
>>> out policy into separate packages, ie http_policy.rpm but this was 
>>> discounted as it was seen as a policy explosion.  Also
>>>       
>> How is it a policy explosion? What does that mean exactly?
>>     
>
> Package explosion. For every package in the "universe", there is more
> metadata to be downloaded and more memory to be used.  Having to have a
> separate subpackage for *every* package containing policy is madness.
>
>   
The vast majority of packages do not need policies. I know we've 
mentioned this before and I don't know where you got the impression that 
every package would need a corresponding policy package.
>>> we discussed only doing the semodule as the last in the transaction 
>>> but this ability is being de-emphasized in the installer, so it was 
>>> thought to keep it simple and install the policy within each RPM that 
>>> ships with policy, sort of the ldconfig model.
>>>
>>>       
>> de-emphasized by the installer?  Not sure I follow, rebuilding the 
>> policy every time is expensive and may get worse (policy server 
>> enforcement).
>>     
>
> There's movement underway to split transactions into minimal closed
> sets.  Which means that you're going to end up running semodule about as
> many times as there are policy packages.  If this takes absurd amounts
> of time, then people further get the impression that SELinux is an
> impediment more than a help :(
>
>   
What is the problem with enclosing the policy packages within a single 
transaction?
>>> Secondly the rpm team would like to be able to execute the equivalent 
>>> of matchpathcon(XYZ.pp)  IE be able to extract the FC file mapping 
>>> from the policy package and combine it with the on disk representation 
>>> to determine the file context to associate with the new files being 
>>> put on disk.
>>>
>>>       
>> hrm, this is unreliable unless you are combining file contexts from all 
>> possible modules being installed. Any given RPM transaction can easily 
>> have multiple policy packages and this needs to be addressed.
>>     
>
> The policy for a given package needs to be able to be contained to that
> package.  Otherwise, it's pretty much impossible to sanely handle policy
> in anything other than the huge blob that there is now[1].  Saying
> otherwise is like saying that the uid/gid that owns a file should be
> able to be specified by combining things from multiple packages.
>
>   
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.
>>> At the end of the rpm install, postinstall would do an semodule -i 
>>> XYZ.pp.
>>>       
>> The ideal order is to install all the policy packages first (shouldn't 
>> be too hard to move them to the beginning of the ordered list) and after 
>> they are installed do a single transaction to install them all (you have 
>> to do something like this regardless due to mutual dependencies) and 
>> then proceed to regular packages. This seems much cleaner than the sort 
>> of hackery being described here.
>>     
>
> If policy packages require running a tool for the policy to be active,
> then they fundamentally cannot be at the beginning of a transaction as
> the package containing, eg, semodule will need to be installed too.  And
> the dep tree cascades down from there.  Plus, special casing policy
> packages to be different from every other piece of software shipped is
> more hack-ish, not less.
>
>   
How so? Granted that semodule, libsemanage, etc must come before policy 
packages but why can't policy packages be depended on in a way that 
forces them to the front (behind their own dependencies of course). What 
you are saying is that you want to support selinux modules but not 
really. Further, stating that something is more hacky because it falls 
on RPM to implement the special case rather than implementing the 
special case in the kernel, the selinux libraries, policy and enduring 
some amount of inconsistency in the kernel, the filesystem and policy 
seems pretty short sighted.


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

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

[Jeremy Katz]

On Tue, 2006-05-02 at 11:33 -0400, Joshua Brindle wrote:
> Jeremy Katz wrote:
> > On Tue, 2006-05-02 at 11:01 -0400, Joshua Brindle wrote:
> >> Daniel J Walsh wrote:
> >>> I had more meetings with the install and RPM team at Red Hat about 
> >>> splitting out policy into individual packages for RHEL5/FC6.  We had 
> >>> many discussions about possible ways of doing this including breaking 
> >>> out policy into separate packages, ie http_policy.rpm but this was 
> >>> discounted as it was seen as a policy explosion.  Also
> >>>       
> >> How is it a policy explosion? What does that mean exactly?
> >
> > Package explosion. For every package in the "universe", there is more
> > metadata to be downloaded and more memory to be used.  Having to have a
> > separate subpackage for *every* package containing policy is madness.
> >   
> The vast majority of packages do not need policies. I know we've 
> mentioned this before and I don't know where you got the impression that 
> every package would need a corresponding policy package.

Not every package, but a lot will.  And if SELinux is successful, that
number should grow, not shrink.  In the policy tarball I happen to have
already sitting on my box, there are 161 .te files.  The vast majority
of those _should_ be maintained by the package maintainer with the
package.  So we're talking a significant number of packages

> >>> we discussed only doing the semodule as the last in the transaction 
> >>> but this ability is being de-emphasized in the installer, so it was 
> >>> thought to keep it simple and install the policy within each RPM that 
> >>> ships with policy, sort of the ldconfig model.
> >>>       
> >> de-emphasized by the installer?  Not sure I follow, rebuilding the 
> >> policy every time is expensive and may get worse (policy server 
> >> enforcement).
> >
> > There's movement underway to split transactions into minimal closed
> > sets.  Which means that you're going to end up running semodule about as
> > many times as there are policy packages.  If this takes absurd amounts
> > of time, then people further get the impression that SELinux is an
> > impediment more than a help :(
> >   
> What is the problem with enclosing the policy packages within a single 
> transaction?

If you actually try to split along functional lines, things like the
base system should be on one set of CDs (and thus one transaction) while
desktop stuff is elsewhere, the LAMP stack is elsewhere, etc.  Having to
include the policy for everything that someone might possibly want to
install on the base set of CDs doesn't work if you're trying to allow
arbitrary CD sets.

> >>> Secondly the rpm team would like to be able to execute the equivalent 
> >>> of matchpathcon(XYZ.pp)  IE be able to extract the FC file mapping 
> >>> from the policy package and combine it with the on disk representation 
> >>> to determine the file context to associate with the new files being 
> >>> put on disk.
> >>>       
> >> hrm, this is unreliable unless you are combining file contexts from all 
> >> possible modules being installed. Any given RPM transaction can easily 
> >> have multiple policy packages and this needs to be addressed.
> >
> > The policy for a given package needs to be able to be contained to that
> > package.  Otherwise, it's pretty much impossible to sanely handle policy
> > in anything other than the huge blob that there is now[1].  Saying
> > otherwise is like saying that the uid/gid that owns a file should be
> > able to be specified by combining things from multiple packages.
> >   
> 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.

> >>> At the end of the rpm install, postinstall would do an semodule -i 
> >>> XYZ.pp.
> >>>       
> >> The ideal order is to install all the policy packages first (shouldn't 
> >> be too hard to move them to the beginning of the ordered list) and after 
> >> they are installed do a single transaction to install them all (you have 
> >> to do something like this regardless due to mutual dependencies) and 
> >> then proceed to regular packages. This seems much cleaner than the sort 
> >> of hackery being described here.
> >
> > If policy packages require running a tool for the policy to be active,
> > then they fundamentally cannot be at the beginning of a transaction as
> > the package containing, eg, semodule will need to be installed too.  And
> > the dep tree cascades down from there.  Plus, special casing policy
> > packages to be different from every other piece of software shipped is
> > more hack-ish, not less.
> >   
> How so? Granted that semodule, libsemanage, etc must come before policy 
> packages but why can't policy packages be depended on in a way that 
> forces them to the front (behind their own dependencies of course). 

Because the dep trees aren't small.  So you're ending up at some
midpoint of the transaction.  At which point you have to do some sort of
break and run some other tool directly from the package manager rather
than having the packages properly contain the script information on what
they need.

Jeremy

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

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

[Karl MacMillan]

On Tue, 2006-05-02 at 11:48 -0400, Jeremy Katz wrote:
> On Tue, 2006-05-02 at 11:33 -0400, Joshua Brindle wrote:
> > Jeremy Katz wrote:
> > > On Tue, 2006-05-02 at 11:01 -0400, Joshua Brindle wrote:

<snip>

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

Karl

-- 
Karl MacMillan
kmacmillan@tresys.com
http://www.tresys.com

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

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

[Joshua Brindle]

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.

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

[Jeremy Katz]

On Wed, 2006-05-03 at 15:02 -0400, Joshua Brindle wrote:
> 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).

But the only contexts which should be stored in the package are the ones
relevant to the package-specific policy.  Otherwise, we fall back to the
current behavior of doing matchpathcon() with the currently loaded
policy and setting the label appropriately.

Jeremy


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

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

[Karl MacMillan]

On Wed, 2006-05-03 at 15:02 -0400, Joshua Brindle wrote:
> 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).
> 

Sure, but the common case is that the application specific file contexts
can be combined with only the base policy file contexts to create the
full labeling policy for that application.

Karl


-- 
Karl MacMillan
kmacmillan@tresys.com
http://www.tresys.com

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

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

[Joshua Brindle]

Karl MacMillan wrote:
> On Wed, 2006-05-03 at 15:02 -0400, Joshua Brindle wrote:
>   
>> 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).
>>
>>     
>
> Sure, but the common case is that the application specific file contexts
> can be combined with only the base policy file contexts to create the
> full labeling policy for that application.
>   
This doesn't work every time though. For example, if you are installing 
sendmail and thus installing the mta and sendmail policies the sendmail 
binary _will not_ get labeled correctly just by looking at the sendmail 
policy and the base policy. The sendmail binary is labeled via mta.fc. I 
expect mutually dependent modules like this to increase over time, not 
go away.

I still haven't heard why it is a problem to explicitly combine policy 
packages within the same rpm transaction (since you are trying to 
minimize transaction size) and do a rebuild/commit after that (and 
before installing the apps). This seems pretty clear to me to be the 
best solution but noone seems to be considering it at all.

And noone has addressed the fact that libselinux does not sort the 
file_contexts the same way that libsemanage does when it writes it. This 
leads to matchpathcon(foo.pp) producing different results than would be 
produced if foo.pp were installed and matchpathcon() run.

I am baffled why the advocates of this believe making kernel tolerant of 
inconsistent filesystem labels and allowing strange policy interactions 
for the sake of bandaiding an inadequacy in RPM is better.. .*shrug*


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

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

[Thomas Bleher]

[-- Attachment #1: Type: text/plain, Size: 1726 bytes --]

* Joshua Brindle <method@gentoo.org> [2006-05-03 23:24]:
[Discussion about allowing rpm to write security labels to disk which
are not in the policy] 
> I am baffled why the advocates of this believe making kernel tolerant of 
> inconsistent filesystem labels and allowing strange policy interactions 
> for the sake of bandaiding an inadequacy in RPM is better.. .*shrug*

For the record, I'm also opposed to this change. It can be handled
entirely in userspace, which IMHO is the proper place.

I still think that separate policy packages would be the best solution.
They're the standard way of doing what you want, people understand them,
and they provide an easy way to look at policy for analysis. Another
important point: They make it easy for people to supply alternative
policy. Want to use strict instead of targeted? No need to replace every
package containing policy, just create a new repository with policy
packages in them, and give this repository a higher priority.

If you really don't want to use separate packages you could implement
something like dpkg triggers[1]. Basically you could add a trigger
"Reload SELinux policy", which would be run between preinst and actual
installation if any policy was changed. Then you could add an option to
semodule: "Store module and install it on next policy rebuild".
I think that would solve your problems within the current framework,
without requiring kernel changes.
Another advantage: If a policy module is bad (symbol clashes, ...) you
notice before installation.

Thomas

[1]: See http://www.netsplit.com/blog/tech/debian/dpkg/where_next_for_dpkg_.html
I don't think it has been implemented yet but the idea sounds very nice.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

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

[Thomas Bleher]

[-- Attachment #1: Type: text/plain, Size: 2759 bytes --]

* Thomas Bleher <bleher@informatik.uni-muenchen.de> [2006-05-04 11:15]:
> * Joshua Brindle <method@gentoo.org> [2006-05-03 23:24]:
> [Discussion about allowing rpm to write security labels to disk which
> are not in the policy] 
> > I am baffled why the advocates of this believe making kernel tolerant of 
> > inconsistent filesystem labels and allowing strange policy interactions 
> > for the sake of bandaiding an inadequacy in RPM is better.. .*shrug*
> 
> For the record, I'm also opposed to this change. It can be handled
> entirely in userspace, which IMHO is the proper place.
> 
> I still think that separate policy packages would be the best solution.
> They're the standard way of doing what you want, people understand them,
> and they provide an easy way to look at policy for analysis. Another
> important point: They make it easy for people to supply alternative
> policy. Want to use strict instead of targeted? No need to replace every
> package containing policy, just create a new repository with policy
> packages in them, and give this repository a higher priority.
> 
> If you really don't want to use separate packages you could implement
> something like dpkg triggers[1]. Basically you could add a trigger
> "Reload SELinux policy", which would be run between preinst and actual
> installation if any policy was changed. Then you could add an option to
> semodule: "Store module and install it on next policy rebuild".
> I think that would solve your problems within the current framework,
> without requiring kernel changes.
> Another advantage: If a policy module is bad (symbol clashes, ...) you
> notice before installation.

I got a reply from Jeremy indicating that my message was not as clear as
I thought.

So to clear up any confusion, here's how package installation could
work:
1. rpm is given a list of packages to be installed.
2. It runs all preinstall scripts of the to-be-installed packages
3. Every package which has its own policy asks semodule to instll its
   policy package on the next policy rebuild; it also sets a flag (or
   trigger, whatever you want to call it): "I need policy reloaded before
   I'm installed"
4. After all preinstall scripts have been run, rpm reloads the policy
5. Now everything is set up so packages can be installed normally.

*HOW* you store the policy in the package is not so important (you can
also store it in a special section in the package so that the package
does not need to have an install script). The important point is that
first all policies are extracted from the packages, then policy is
reloaded, and after that packages are installed.

I think this does everything you want, just without kernel changes.

Thomas

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

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

[Stephen Smalley]

On Tue, 2006-05-02 at 10:24 -0400, Daniel J Walsh wrote:
> I had more meetings with the install and RPM team at Red Hat about 
> splitting out policy into individual packages for RHEL5/FC6.  We had 
> many discussions about possible ways of doing this including breaking 
> out policy into separate packages, ie http_policy.rpm but this was 
> discounted as it was seen as a policy explosion.

Not every package requires policy.

>   Also we discussed only 
> doing the semodule as the last in the transaction but this ability is 
> being de-emphasized in the installer, so it was thought to keep it 
> simple and install the policy within each RPM that ships with policy, 
> sort of the ldconfig model.
> 
> We need the ability for RPM to be able to write a file context on disk 
> without the kernel verifying it.  The kernel should treat this as an 
> unlabeled_t file. the same way it would if I ran
> 
> semodule -i XYZ.pp
> restorecon /usr/bin/XYZ
> semoduel -e XYZ
> 
> I don't think this is an unreasonable request to allow rpm_t to have the 
> privilege of writing the "invalid" context to disk.

To restate my concerns with this approach:
- It means that rpm (and any other program in the future to which we
extend the same privilege, which will be increasingly tempting for a
whole range of functionality) can never be effectively confined in any
way, as they can set down arbitrary contexts (remember too that we'd
ultimately like rpm or a helper that does the real work to run in
different domains depending on the trustworthiness of the package),
- It means that the kernel needs a mechanism for revalidating/updating
the incore inode SIDs upon a policy reload, i.e. a policy reload would
then need to trigger a traversal of the inode lists (including suitable
locking of those lists) to fix up the incore inode SIDs for files that
previously had invalid attributes.  Or that rpm has to go around fixing
them up from userspace after loading the policy.

This kind of scheme works fine for file owner and mode information
because there you have an all-or-nothing privilege model already, and
the kernel isn't really interpreting the metadata; all uid and mode
values are effectively "valid" as far as it is concerned, and they don't
need to be mapped to an internal representation.  It doesn't work so
well for labels.

> Secondly the rpm team would like to be able to execute the equivalent of 
> matchpathcon(XYZ.pp)  IE be able to extract the FC file mapping from the 
> policy package and combine it with the on disk representation to 
> determine the file context to associate with the new files being put on 
> disk.

This shouldn't be difficult to implement, but it is only necessary if
you don't install the .pp file prior to labeling the files, which is
really counter to the whole design.  You _can_ install the .pp file
without immediately loading the new kernel policy (semodule -n -i x.pp),
thereby rebuilding file_contexts, but that will still be a heavyweight
operation, so you still want to batch them up.

-- 
Stephen Smalley
National Security Agency


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

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

[Jeremy Katz]

On Tue, 2006-05-02 at 11:12 -0400, Stephen Smalley wrote:
> On Tue, 2006-05-02 at 10:24 -0400, Daniel J Walsh wrote:
> > I had more meetings with the install and RPM team at Red Hat about 
> > splitting out policy into individual packages for RHEL5/FC6.  We had 
> > many discussions about possible ways of doing this including breaking 
> > out policy into separate packages, ie http_policy.rpm but this was 
> > discounted as it was seen as a policy explosion.
> 
> Not every package requires policy.

Lots do.  On the order of as many packages as require users at least.
And I'd expect more over time (especially given policy around dbus and
the increasing reliance on dbus through the distribution).  Imagine a
world where every user you wanted to add had to have a separate package
to create the user first. 

> >   Also we discussed only 
> > doing the semodule as the last in the transaction but this ability is 
> > being de-emphasized in the installer, so it was thought to keep it 
> > simple and install the policy within each RPM that ships with policy, 
> > sort of the ldconfig model.
> > 
> > We need the ability for RPM to be able to write a file context on disk 
> > without the kernel verifying it.  The kernel should treat this as an 
> > unlabeled_t file. the same way it would if I ran
> > 
> > semodule -i XYZ.pp
> > restorecon /usr/bin/XYZ
> > semoduel -e XYZ
> > 
> > I don't think this is an unreasonable request to allow rpm_t to have the 
> > privilege of writing the "invalid" context to disk.
> 
> To restate my concerns with this approach:
> - It means that rpm (and any other program in the future to which we
> extend the same privilege, which will be increasingly tempting for a
> whole range of functionality) can never be effectively confined in any
> way, as they can set down arbitrary contexts (remember too that we'd
> ultimately like rpm or a helper that does the real work to run in
> different domains depending on the trustworthiness of the package),
> - It means that the kernel needs a mechanism for revalidating/updating
> the incore inode SIDs upon a policy reload, i.e. a policy reload would
> then need to trigger a traversal of the inode lists (including suitable
> locking of those lists) to fix up the incore inode SIDs for files that
> previously had invalid attributes.  Or that rpm has to go around fixing
> them up from userspace after loading the policy.

You _already_ have to handle this case.  Think about the case where I
load a policy with some file context.  Then, I create files labeled as
such.  Then I remove the policy.   Use the files.  Then load policy
again.  

And to be fully up-front about it, if there is continued opposition to
being able to set things like this, then what's going to end up having
to happen is that we're going to have to generate some dummy policy
mapping new file contexts to unlabeled_t (or some such) and load it
before the files get put down and then load the real policy afterwards.
And you've now doubled the amount of time spent on policy loads[1] and
gaining nothing beyond having the kernel do the right thing.

Jeremy

[1] Which has already been stated to be expensive and getting _more_ so
instead of less

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

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

[Stephen Smalley]

On Tue, 2006-05-02 at 11:27 -0400, Jeremy Katz wrote:
> Lots do.  On the order of as many packages as require users at least.
> And I'd expect more over time (especially given policy around dbus and
> the increasing reliance on dbus through the distribution).  Imagine a
> world where every user you wanted to add had to have a separate package
> to create the user first. 

I'm not sure these all require separate policy.  Ideally, we'd like to
see greater use of the equivalence class concepts to limit the explosion
in policy and not require per-application/per-package policy in so many
cases.  There is a tradeoff here in least privilege vs. manageability.

> You _already_ have to handle this case.  Think about the case where I
> load a policy with some file context.  Then, I create files labeled as
> such.  Then I remove the policy.   Use the files.  Then load policy
> again.  

If you didn't remove the files when you removed the policy, and you
didn't bother to relabel them, then they truly have become unlabeled.
Arguing that they should auto-magically be converted back to the
original types when those types re-appear in the policy (regardless of
what they may mean) is not a clear cut case.  Consider an analogy:
Admin creates some user accounts, those users create some files, admin
deletes the user accounts but some files owned by those uids are left
around the system, later the admin creates some other user accounts but
reuses the same uids.  Now those leftover files will be accessible to
the new users, but it is debatable as to whether that is a good thing.

> And to be fully up-front about it, if there is continued opposition to
> being able to set things like this, then what's going to end up having
> to happen is that we're going to have to generate some dummy policy
> mapping new file contexts to unlabeled_t (or some such) and load it
> before the files get put down and then load the real policy afterwards.
> And you've now doubled the amount of time spent on policy loads[1] and
> gaining nothing beyond having the kernel do the right thing.

Ok, let's assume that we implement kernel mechanism for
revalidating/updating the incore inode SIDs upon policy reload.  But
where does this leave us with regard to being able to meaningfully
confine rpm in the future, e.g. by moving the real processing into a
helper and running it in different domains based on package
trustworthiness and purpose?  If rpm (and potentially other programs, as
this becomes a tempting way to deal with e.g. dump/restore) can set down
arbitrary values as file contexts, then can they be meaningfully
restricted in any way?  To me that is the larger concern.

-- 
Stephen Smalley
National Security Agency


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

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

[Paul Nasrat]

On Tue, 2006-05-02 at 12:26 -0400, Stephen Smalley wrote:
> On Tue, 2006-05-02 at 11:27 -0400, Jeremy Katz wrote:

> Ok, let's assume that we implement kernel mechanism for
> revalidating/updating the incore inode SIDs upon policy reload.  But
> where does this leave us with regard to being able to meaningfully
> confine rpm in the future, e.g. by moving the real processing into a
> helper and running it in different domains based on package
> trustworthiness and purpose?  

Do you have any patches or information about this helper model in RPM.
If we are looking at moving to a helper anyway should we not be looking
at how to implement modular policy with the helper?  

How is the helper is going to be able to access the pp file before it is
on disk, how does it load policy, how do we ensure that transactions
with scriptlets/triggers on a policy module update that all contexts are
"correct" at time of running.

Paul  

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

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

[Stephen Smalley]

On Tue, 2006-05-02 at 12:29 -0400, Paul Nasrat wrote:
> On Tue, 2006-05-02 at 12:26 -0400, Stephen Smalley wrote:
> > On Tue, 2006-05-02 at 11:27 -0400, Jeremy Katz wrote:
> 
> > Ok, let's assume that we implement kernel mechanism for
> > revalidating/updating the incore inode SIDs upon policy reload.  But
> > where does this leave us with regard to being able to meaningfully
> > confine rpm in the future, e.g. by moving the real processing into a
> > helper and running it in different domains based on package
> > trustworthiness and purpose?  
> 
> Do you have any patches or information about this helper model in RPM.

I just mean separating rpm into a front-end program that determines the
right domain in which to run a back-end helper, and the back-end helper
that does most of the real processing, including loading any policy,
installing the files, running the scriptlets, etc.  Then you can have
different domains for the helper based on the trustworthiness and
purpose of the package being installed, and policy can ensure that e.g.
package foo cannot do arbitrary things on your system.

> If we are looking at moving to a helper anyway should we not be looking
> at how to implement modular policy with the helper?  
> 
> How is the helper is going to be able to access the pp file before it is
> on disk, how does it load policy, how do we ensure that transactions
> with scriptlets/triggers on a policy module update that all contexts are
> "correct" at time of running.

I don't think the helper fundamentally changes the issue.  If you want
to allow rpm (whether via helper or not) to set arbitrary file contexts
so that you do not have to load policy prior to setting down the files,
then how can we ever confine it in policy?  That's the question.  It
changes the model from one where no process is fully trusted to
completely subvert the model and everything must be explicitly allowed
by policy to one where certain processes have discretion to arbitrarily
subvert the policy and no amount of analysis of the policy is going to
tell you what can actually happen on the system.

-- 
Stephen Smalley
National Security Agency


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

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

[Stephen Smalley]

On Tue, 2006-05-02 at 12:26 -0400, Stephen Smalley wrote:
> Ok, let's assume that we implement kernel mechanism for
> revalidating/updating the incore inode SIDs upon policy reload.  But
> where does this leave us with regard to being able to meaningfully
> confine rpm in the future, e.g. by moving the real processing into a
> helper and running it in different domains based on package
> trustworthiness and purpose?  If rpm (and potentially other programs, as
> this becomes a tempting way to deal with e.g. dump/restore) can set down
> arbitrary values as file contexts, then can they be meaningfully
> restricted in any way?  To me that is the larger concern.

Ok, it has been pointed out to me that rpm and friends can still be
meaningfully restricted if:
a) we still apply the usual checking on setxattr() when the context is
valid under the policy (thereby preventing rpm from setting to a context
that is known but not accessible to it under the policy), and just use
unlabeled_t as the target context when the context is not known under
the policy and the process has some new privilege for setting unknown
contexts (so the privilege no longer confers completely arbitrary
values),
b) we apply fine-grained access control over the policy modules being
loaded by rpm so that it cannot add types with arbitrary permissions to
the policy (so that it cannot gain access to something it should not via
the previously unknown types it is introducing), which is necessary
anyway for confinement of rpm and should be addressed via the policy
server.

In which case I have a couple of other questions:
1) Are there any implications of having these files exist temporarily
with the unlabeled_t type, as that type is generally inaccessible except
to privileged domains?  Seems like we could end up with spurious denials
on running processes, e.g. upon glibc upgrade or similar.
2) What kind of error checking will rpm do to deal with the fact that
the kernel won't know that the context is invalid at setxattr() time, so
if rpm feeds it one that ends up being invalid even under the new
policy, that won't be known until the policy load occurs?  I suppose rpm
could call lgetxattr()/lgetfilecon() on the files after the policy load
and recheck that they have the expected values.  But does that fit with
your proposed approach?

-- 
Stephen Smalley
National Security Agency


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

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

[Jeremy Katz]

On Tue, 2006-05-02 at 13:42 -0400, Stephen Smalley wrote:
> On Tue, 2006-05-02 at 12:26 -0400, Stephen Smalley wrote:
> > Ok, let's assume that we implement kernel mechanism for
> > revalidating/updating the incore inode SIDs upon policy reload.  But
> > where does this leave us with regard to being able to meaningfully
> > confine rpm in the future, e.g. by moving the real processing into a
> > helper and running it in different domains based on package
> > trustworthiness and purpose?  If rpm (and potentially other programs, as
> > this becomes a tempting way to deal with e.g. dump/restore) can set down
> > arbitrary values as file contexts, then can they be meaningfully
> > restricted in any way?  To me that is the larger concern.
> 
> Ok, it has been pointed out to me that rpm and friends can still be
> meaningfully restricted if:

Whoever pointed it out, thank them for making the point I was trying to
make :-)

> In which case I have a couple of other questions:
> 1) Are there any implications of having these files exist temporarily
> with the unlabeled_t type, as that type is generally inaccessible except
> to privileged domains?  Seems like we could end up with spurious denials
> on running processes, e.g. upon glibc upgrade or similar.

Well, on an upgrade one would hope that the type is already known.  So
it should only be an issue in the case of:
a) Fresh installation of a package with associated policy -- hence,
there won't be things running for it while the files are being put down
and the first thing done in the scriptlets should be loading the policy 
b) Adding new policy for a package but I would expect the running
process would keep running unconfined as previously, then in the
post-install, the (new) policy gets loaded and the service gets
restarted

So I can't really forsee problems with these cases

> 2) What kind of error checking will rpm do to deal with the fact that
> the kernel won't know that the context is invalid at setxattr() time, so
> if rpm feeds it one that ends up being invalid even under the new
> policy, that won't be known until the policy load occurs?  I suppose rpm
> could call lgetxattr()/lgetfilecon() on the files after the policy load
> and recheck that they have the expected values.  But does that fit with
> your proposed approach?

The plan is that rpmbuild would only be setting a context in the header
if it's set in the policy module at build time.  So you could only
really end up here if you have a package built via a bad rpmbuild.  And
realistically, once you get there, you're going to have other things to
worry about (hence why signature checking of packages is important to
know that a package is from a trusted(tm) source). 

So while checking could be done after the package install, I'm not sure
how much it buys us.  Especially as a policy change could (potentially,
though this would want to be avoided by ensuring that policy is broken
down into the right "chunks") invalidate contexts for files from other
packages.  rpm --verify should certainly check for this case.

Jeremy


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

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

[Karl MacMillan]

On Tue, 2006-05-02 at 12:26 -0400, Stephen Smalley wrote:
> On Tue, 2006-05-02 at 11:27 -0400, Jeremy Katz wrote:
> > Lots do.  On the order of as many packages as require users at least.
> > And I'd expect more over time (especially given policy around dbus and
> > the increasing reliance on dbus through the distribution).  Imagine a
> > world where every user you wanted to add had to have a separate package
> > to create the user first. 
> 
> I'm not sure these all require separate policy.  Ideally, we'd like to
> see greater use of the equivalence class concepts to limit the explosion
> in policy and not require per-application/per-package policy in so many
> cases.  There is a tradeoff here in least privilege vs. manageability.
> 

The other issue that I'm concerned with is how multiple policy types
will be supported including custom third-part policies. I know that Dan
has been pushing the concept that policies should be portable across
base policies, but I think that there is a limit to how far that can go.
Separate policy packages seem to handle this situation elegantly. So,
how is the MLS policy going to be handled?

Karl

-- 
Karl MacMillan
kmacmillan@tresys.com
http://www.tresys.com

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

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

[Daniel J Walsh]

Karl MacMillan wrote:
> On Tue, 2006-05-02 at 12:26 -0400, Stephen Smalley wrote:
>   
>> On Tue, 2006-05-02 at 11:27 -0400, Jeremy Katz wrote:
>>     
>>> Lots do.  On the order of as many packages as require users at least.
>>> And I'd expect more over time (especially given policy around dbus and
>>> the increasing reliance on dbus through the distribution).  Imagine a
>>> world where every user you wanted to add had to have a separate package
>>> to create the user first. 
>>>       
>> I'm not sure these all require separate policy.  Ideally, we'd like to
>> see greater use of the equivalence class concepts to limit the explosion
>> in policy and not require per-application/per-package policy in so many
>> cases.  There is a tradeoff here in least privilege vs. manageability.
>>
>>     
>
> The other issue that I'm concerned with is how multiple policy types
> will be supported including custom third-part policies. I know that Dan
> has been pushing the concept that policies should be portable across
> base policies, but I think that there is a limit to how far that can go.
> Separate policy packages seem to handle this situation elegantly. So,
> how is the MLS policy going to be handled?
>
> Karl
>
>   
Could we do a requires/provides for this type of thing?

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

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

[Karl MacMillan]

On Wed, 2006-05-03 at 11:33 -0400, Daniel J Walsh wrote:
> Karl MacMillan wrote:
> > On Tue, 2006-05-02 at 12:26 -0400, Stephen Smalley wrote:
> >   
> >> On Tue, 2006-05-02 at 11:27 -0400, Jeremy Katz wrote:
> >>     
> >>> Lots do.  On the order of as many packages as require users at least.
> >>> And I'd expect more over time (especially given policy around dbus and
> >>> the increasing reliance on dbus through the distribution).  Imagine a
> >>> world where every user you wanted to add had to have a separate package
> >>> to create the user first. 
> >>>       
> >> I'm not sure these all require separate policy.  Ideally, we'd like to
> >> see greater use of the equivalence class concepts to limit the explosion
> >> in policy and not require per-application/per-package policy in so many
> >> cases.  There is a tradeoff here in least privilege vs. manageability.
> >>
> >>     
> >
> > The other issue that I'm concerned with is how multiple policy types
> > will be supported including custom third-part policies. I know that Dan
> > has been pushing the concept that policies should be portable across
> > base policies, but I think that there is a limit to how far that can go.
> > Separate policy packages seem to handle this situation elegantly. So,
> > how is the MLS policy going to be handled?
> >
> > Karl
> >
> >   
> Could we do a requires/provides for this type of thing?

That would work well with separate policy packages (and we have
discussed it in the past), but how would it work if the policy is in the
application rpm?

Karl

-- 
Karl MacMillan
kmacmillan@tresys.com
http://www.tresys.com

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

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

[Paul Nasrat]

On Tue, 2006-05-02 at 11:12 -0400, Stephen Smalley wrote:

> > Secondly the rpm team would like to be able to execute the equivalent of 
> > matchpathcon(XYZ.pp)  IE be able to extract the FC file mapping from the 
> > policy package and combine it with the on disk representation to 
> > determine the file context to associate with the new files being put on 
> > disk.
> 
> This shouldn't be difficult to implement, but it is only necessary if
> you don't install the .pp file prior to labeling the files, which is
> really counter to the whole design.  You _can_ install the .pp file
> without immediately loading the new kernel policy (semodule -n -i x.pp),
> thereby rebuilding file_contexts, but that will still be a heavyweight
> operation, so you still want to batch them up.

The point here is to capture the file contexts at build time, not at
install time - as a packager with policy I may not have the ability to
install policy on my build host.

The implementation in RPM currently supports querying file contexts in
headers, via matchpathcon and what is actually on the filesystem.  The
point here was to enable us to correctly set the header contexts, as
when we are laying files on disk we might not have put the pp file down
yet.  Changing RPM to extract specific file types from each package at
transaction run is not a desirable change, we already can look up
contexts - on FC5 where policy was in the build roots you can do:

rpm --qf '[%{filenames} %{filecontexts}\n]' -q rpm

If we had
%install
install -m 600 foo.pp $RPM_BUILD_ROOT/%{policy_dir}/foo.pp

%policy %{policy_dir}/foo.pp

Then the context header population in the RPM header could use the pp
file for that information via matchpathcon or equivalent.

Paul

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

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

[Richard Hally]

Daniel J Walsh wrote:
<snip>

> 
> We need the ability for RPM to be able to write a file context on disk 
> without the kernel verifying it.  The kernel should treat this as an 
> unlabeled_t file. the same way it would if I ran
> 
> semodule -i XYZ.pp
> restorecon /usr/bin/XYZ
> semoduel -e XYZ
> 
> I don't think this is an unreasonable request to allow rpm_t to have the 
> privilege of writing the "invalid" context to disk.
> 
> Secondly the rpm team would like to be able to execute the equivalent of 
> matchpathcon(XYZ.pp)  IE be able to extract the FC file mapping from the 
> policy package and combine it with the on disk representation to 
> determine the file context to associate with the new files being put on 
> disk.
> 
> At the end of the rpm install, postinstall would do an semodule -i XYZ.pp.
> 
> We want to start out with just a couple of packages shipping policy to 
> prove the technology and then to allow third parties to ship using this 
> method.
> 
> Dan


What if the files being installed were already labeled with the context?
I.e after the files are built but before being packaged into the rpm, 
the context is applied to the file.

Richard


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