[RFC] Install SELinux policies from rpm package header

[RFC] Install SELinux policies from rpm package header

[Chad Sellers]

RPM currently has support for security policies to be stored in an rpm
header but it doesn't currently do anything with the policies. Instead,
SELinux policy is usually installed through %post scripts. We're planning to
work with the RPM community to get integrated support for SELinux policy,
and we'd like to get some feedback on our plans from the SELinux community.

First, a bit of background. SELinux policy is currently installed through
%post scripts. This presents several problems. First, this means that policy
for a given application may not be loaded at the time the files are written
to disk, preventing those files from being labeled properly, because the
symbols used to label files need to be in the policy loaded into the kernel.
Secondly, this means that if multiple packages install policy, each of their
%post scripts will reload the policy, which is a very expensive operation.
Consequently, policy is generally kept in a single package to avoid this,
despite containing many application specific policy modules that might be
more suited to be included in their application package. There are many
other problems with the current RPM support which I'd be happy to get into
as well, but I'll leave them out for now to prevent this email from getting
too long.

So, what we would like to do is to start including SELinux policy as part of
the rpm and have rpm install all policies together before files start to hit
the disk. To do this, we would like to use the already supported %policy
directive, which stores the policy in the RPM archive header.

We would then install the policy very early (before pretrans). This policy
load would involve gathering all the policies to be installed from all
packages, writing them to a temporary location, and calling out to semodule
to install the SELinux policy modules.

This new support will enable application packages to include their policy
within their package (e.g. bind includes the bind policy module in the bind
rpm), which would make it much easier to ensure that the appropriate policy
version is installed for a given application version. Note that while it is
possible to include policy within application packages, it is not necessary.
This new support would still allow a single policy RPM to contain many
policy modules as we have today. Those policy modules could then be slowly
split out to be included with the applications they confine as it makes
sense.

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. You can see a proof of concept patch that begins this
implementation, as well as some of our conversation with the RPM community
here:

http://lists.rpm.org/pipermail/rpm-maint/2009-July/002452.html

Thanks,
Chad Sellers


--
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: [RFC] Install SELinux policies from rpm package header

[Paul Howarth]

On Thu, 09 Jul 2009 11:03:05 -0400
Chad Sellers <csellers@tresys.com> wrote:

> RPM currently has support for security policies to be stored in an rpm
> header but it doesn't currently do anything with the policies.
> Instead, SELinux policy is usually installed through %post scripts.
> We're planning to work with the RPM community to get integrated
> support for SELinux policy, and we'd like to get some feedback on our
> plans from the SELinux community.
> 
> First, a bit of background. SELinux policy is currently installed
> through %post scripts. This presents several problems. First, this
> means that policy for a given application may not be loaded at the
> time the files are written to disk, preventing those files from being
> labeled properly, because the symbols used to label files need to be
> in the policy loaded into the kernel. Secondly, this means that if
> multiple packages install policy, each of their %post scripts will
> reload the policy, which is a very expensive operation. Consequently,
> policy is generally kept in a single package to avoid this, despite
> containing many application specific policy modules that might be
> more suited to be included in their application package. There are
> many other problems with the current RPM support which I'd be happy
> to get into as well, but I'll leave them out for now to prevent this
> email from getting too long.
> 
> So, what we would like to do is to start including SELinux policy as
> part of the rpm and have rpm install all policies together before
> files start to hit the disk. To do this, we would like to use the
> already supported %policy directive, which stores the policy in the
> RPM archive header.
> 
> We would then install the policy very early (before pretrans). This
> policy load would involve gathering all the policies to be installed
> from all packages, writing them to a temporary location, and calling
> out to semodule to install the SELinux policy modules.
> 
> This new support will enable application packages to include their
> policy within their package (e.g. bind includes the bind policy
> module in the bind rpm), which would make it much easier to ensure
> that the appropriate policy version is installed for a given
> application version. Note that while it is possible to include policy
> within application packages, it is not necessary. This new support
> would still allow a single policy RPM to contain many policy modules
> as we have today. Those policy modules could then be slowly split out
> to be included with the applications they confine as it makes sense.
> 
> 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. You can see a proof of concept patch that
> begins this implementation, as well as some of our conversation with
> the RPM community here:
> 
> http://lists.rpm.org/pipermail/rpm-maint/2009-July/002452.html

In addition to the discussion on the RPM list, some accumulated wisdom
on integrating policy modules with existing RPM infrastructure can be
found on the Fedora wiki:

https://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft

A few things spring to mind straight away:

1. Package Removal

At package removal time, it's important that policy stays around until
files have been removed *and* in the case of packages for daemons,
processes killed. Removing policy underneath a running process can
result in unlabeled processes that are unkillable.

2. Dependencies

Policy modules include interfaces, and call the interfaces of other
modules. In order to ensure that all required interfaces are present,
packages will have to grow another set of dependencies on the packages
that provide these interfaces. Since policy is generally written to
encompass everything that an application *might* need to be able to do,
it follows that more packages will be pulled in as dependencies as a
result of policy than would have been pulled in in the absence of the
bundled policy. A way around this might be to package the policy in
subpackages rather than the main packages, and the likely result of
this is having vast swathes of policy subpackages installed but not the
main packages that go with them because they're not actually needed,
which is not too far away from where we are today except that all of
those policy modules are in a single package today - and I rather
suspect that would be more efficient in terms of metadata/disk space
etc.

It's also important to realise that policy module dependencies would
have to be versioned, with a version bump when there's an interface
change as per shared libraries.

3. I've encountered problems in the past when installing RPMs
containing SELinux policy when either:
(a) the policy module package was built against a newer version of base
policy - hence the versioning requirement in packaging draft above, or
(b) a policy module I've developed locally is merged to or otherwise
conflicts with the main selinux-policy package
This can result in policy not loading. I know how to resolve issues
like these manually but if policy is going to be spread more widely
between packages, issues like these need to be resolved in a better
(automagic?) way.

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: [RFC] Install SELinux policies from rpm package header

[Daniel J Walsh]

On 07/09/2009 04:10 PM, Paul Howarth wrote:
> On Thu, 09 Jul 2009 11:03:05 -0400
> Chad Sellers <csellers@tresys.com> wrote:
> 
>> RPM currently has support for security policies to be stored in an rpm
>> header but it doesn't currently do anything with the policies.
>> Instead, SELinux policy is usually installed through %post scripts.
>> We're planning to work with the RPM community to get integrated
>> support for SELinux policy, and we'd like to get some feedback on our
>> plans from the SELinux community.
>>
>> First, a bit of background. SELinux policy is currently installed
>> through %post scripts. This presents several problems. First, this
>> means that policy for a given application may not be loaded at the
>> time the files are written to disk, preventing those files from being
>> labeled properly, because the symbols used to label files need to be
>> in the policy loaded into the kernel. Secondly, this means that if
>> multiple packages install policy, each of their %post scripts will
>> reload the policy, which is a very expensive operation. Consequently,
>> policy is generally kept in a single package to avoid this, despite
>> containing many application specific policy modules that might be
>> more suited to be included in their application package. There are
>> many other problems with the current RPM support which I'd be happy
>> to get into as well, but I'll leave them out for now to prevent this
>> email from getting too long.
>>
>> So, what we would like to do is to start including SELinux policy as
>> part of the rpm and have rpm install all policies together before
>> files start to hit the disk. To do this, we would like to use the
>> already supported %policy directive, which stores the policy in the
>> RPM archive header.
>>
>> We would then install the policy very early (before pretrans). This
>> policy load would involve gathering all the policies to be installed
>> from all packages, writing them to a temporary location, and calling
>> out to semodule to install the SELinux policy modules.
>>
>> This new support will enable application packages to include their
>> policy within their package (e.g. bind includes the bind policy
>> module in the bind rpm), which would make it much easier to ensure
>> that the appropriate policy version is installed for a given
>> application version. Note that while it is possible to include policy
>> within application packages, it is not necessary. This new support
>> would still allow a single policy RPM to contain many policy modules
>> as we have today. Those policy modules could then be slowly split out
>> to be included with the applications they confine as it makes sense.
>>
>> 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. You can see a proof of concept patch that
>> begins this implementation, as well as some of our conversation with
>> the RPM community here:
>>
>> http://lists.rpm.org/pipermail/rpm-maint/2009-July/002452.html
> 
> In addition to the discussion on the RPM list, some accumulated wisdom
> on integrating policy modules with existing RPM infrastructure can be
> found on the Fedora wiki:
> 
> https://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft
> 
> A few things spring to mind straight away:
> 
> 1. Package Removal
> 
> At package removal time, it's important that policy stays around until
> files have been removed *and* in the case of packages for daemons,
> processes killed. Removing policy underneath a running process can
> result in unlabeled processes that are unkillable.
> 
> 2. Dependencies
> 
> Policy modules include interfaces, and call the interfaces of other
> modules. In order to ensure that all required interfaces are present,
> packages will have to grow another set of dependencies on the packages
> that provide these interfaces. Since policy is generally written to
> encompass everything that an application *might* need to be able to do,
> it follows that more packages will be pulled in as dependencies as a
> result of policy than would have been pulled in in the absence of the
> bundled policy. A way around this might be to package the policy in
> subpackages rather than the main packages, and the likely result of
> this is having vast swathes of policy subpackages installed but not the
> main packages that go with them because they're not actually needed,
> which is not too far away from where we are today except that all of
> those policy modules are in a single package today - and I rather
> suspect that would be more efficient in terms of metadata/disk space
> etc.
> 
> It's also important to realise that policy module dependencies would
> have to be versioned, with a version bump when there's an interface
> change as per shared libraries.
> 
> 3. I've encountered problems in the past when installing RPMs
> containing SELinux policy when either:
> (a) the policy module package was built against a newer version of base
> policy - hence the versioning requirement in packaging draft above, or
> (b) a policy module I've developed locally is merged to or otherwise
> conflicts with the main selinux-policy package
> This can result in policy not loading. I know how to resolve issues
> like these manually but if policy is going to be spread more widely
> between packages, issues like these need to be resolved in a better
> (automagic?) way.
> 
> 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.
A couple of other problems with including policy with each rpm.  How do you handle different packaging.  MLS, Targeted, minimal.

If every package includes policy then we need to rely on the package maintainer to write good secure policy.  You have to realize that the goal of a package maintainer is to make the tool run, not necessarily to make sure it is secure or that other componants of the OS integrate well.  

ftp sometimes need to read any file on the OS, so I will add files_read_all(ftp_t)

Now getting the few packages that ship their own policy to work better and the selinux-policy package to work better would be great.  

How about fixing things like semanage command

semanage fcontext ....
semanage ports ....
restorecon ...


Removal of policy packages is a huge problem in that once a type is removed you end up with mislabeled files that can not be indentified.

You do not know where these files are and you need to relabel the entire machine to make sure there are no longer any mislabeled files around.

When you update policy you need to run a diff between the old file context and the new and run a recusive restorecon on the diff.  fixfiles -C PREVIOUS_FILECONTEXT relabel does this for you, but every rpm transaction that does a policy modules update needs to run this at the completion of the transaction.  As well as squirrel away the previous file context before the transaction.

--
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: [RFC] Install SELinux policies from rpm package header

[Chad Sellers]

On 7/9/09 4:10 PM, "Paul Howarth" <paul@city-fan.org> wrote:

> On Thu, 09 Jul 2009 11:03:05 -0400
> Chad Sellers <csellers@tresys.com> wrote:
> 
>> RPM currently has support for security policies to be stored in an rpm
>> header but it doesn't currently do anything with the policies.
>> Instead, SELinux policy is usually installed through %post scripts.
>> We're planning to work with the RPM community to get integrated
>> support for SELinux policy, and we'd like to get some feedback on our
>> plans from the SELinux community.
>> 
>> First, a bit of background. SELinux policy is currently installed
>> through %post scripts. This presents several problems. First, this
>> means that policy for a given application may not be loaded at the
>> time the files are written to disk, preventing those files from being
>> labeled properly, because the symbols used to label files need to be
>> in the policy loaded into the kernel. Secondly, this means that if
>> multiple packages install policy, each of their %post scripts will
>> reload the policy, which is a very expensive operation. Consequently,
>> policy is generally kept in a single package to avoid this, despite
>> containing many application specific policy modules that might be
>> more suited to be included in their application package. There are
>> many other problems with the current RPM support which I'd be happy
>> to get into as well, but I'll leave them out for now to prevent this
>> email from getting too long.
>> 
>> So, what we would like to do is to start including SELinux policy as
>> part of the rpm and have rpm install all policies together before
>> files start to hit the disk. To do this, we would like to use the
>> already supported %policy directive, which stores the policy in the
>> RPM archive header.
>> 
>> We would then install the policy very early (before pretrans). This
>> policy load would involve gathering all the policies to be installed
>> from all packages, writing them to a temporary location, and calling
>> out to semodule to install the SELinux policy modules.
>> 
>> This new support will enable application packages to include their
>> policy within their package (e.g. bind includes the bind policy
>> module in the bind rpm), which would make it much easier to ensure
>> that the appropriate policy version is installed for a given
>> application version. Note that while it is possible to include policy
>> within application packages, it is not necessary. This new support
>> would still allow a single policy RPM to contain many policy modules
>> as we have today. Those policy modules could then be slowly split out
>> to be included with the applications they confine as it makes sense.
>> 
>> 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. You can see a proof of concept patch that
>> begins this implementation, as well as some of our conversation with
>> the RPM community here:
>> 
>> http://lists.rpm.org/pipermail/rpm-maint/2009-July/002452.html
> 
> In addition to the discussion on the RPM list, some accumulated wisdom
> on integrating policy modules with existing RPM infrastructure can be
> found on the Fedora wiki:
> 
> https://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft
> 
> A few things spring to mind straight away:
> 
> 1. Package Removal
> 
> At package removal time, it's important that policy stays around until
> files have been removed *and* in the case of packages for daemons,
> processes killed. Removing policy underneath a running process can
> result in unlabeled processes that are unkillable.
> 
That's a good point. We were planning to remove policy at the end, but I'm
not sure how that would interact with running daemons. It appears that this
scenario should be handled with care and requires specific knowledge of the
particular policy (to flip a boolean). So, I don't think we could handle
this automatically. Perhaps we should include a fallback mechanism to allow
package authors to turn off automatic removal and revert to a %postun
script. Thoughts?

> 2. Dependencies
> 
> Policy modules include interfaces, and call the interfaces of other
> modules. In order to ensure that all required interfaces are present,
> packages will have to grow another set of dependencies on the packages
> that provide these interfaces. Since policy is generally written to
> encompass everything that an application *might* need to be able to do,
> it follows that more packages will be pulled in as dependencies as a
> result of policy than would have been pulled in in the absence of the
> bundled policy. A way around this might be to package the policy in
> subpackages rather than the main packages, and the likely result of
> this is having vast swathes of policy subpackages installed but not the
> main packages that go with them because they're not actually needed,
> which is not too far away from where we are today except that all of
> those policy modules are in a single package today - and I rather
> suspect that would be more efficient in terms of metadata/disk space
> etc.
> 
Our goal here is to provide a better mechanism for installing policy that
can be used with policy in the application package or in a subpackage. As
the Fedora wiki points out, there are reasons to choose either of these, and
we want to support both choices.

Also, note that policy is written to encompass everything an application
might need to be able to do, but much of this policy utilizes optional
blocks. This means these bits of policy don't depend on other policy
modules, but instead will utilize them if they're around. This limits the
explosion of dependencies in the non-subpackage case.

> It's also important to realise that policy module dependencies would
> have to be versioned, with a version bump when there's an interface
> change as per shared libraries.
> 
Agreed.

> 3. I've encountered problems in the past when installing RPMs
> containing SELinux policy when either:
> (a) the policy module package was built against a newer version of base
> policy - hence the versioning requirement in packaging draft above, or

This is a deficiency of the current policy language that we're working on
fixing (in a separate project concurrently). We really want to get to the
point where more is resolved at install time and less is resolved at build
time. In the mean time, your correct that version requirements will be more
extensive.

> (b) a policy module I've developed locally is merged to or otherwise
> conflicts with the main selinux-policy package
> This can result in policy not loading. I know how to resolve issues
> like these manually but if policy is going to be spread more widely
> between packages, issues like these need to be resolved in a better
> (automagic?) way.
> 
Should a conflict occur, we'll of course provide a (hopefully) useful error
message and bail on the transaction. I'm not sure what automagic resolution
we would be able to offer. We'll provide a way to install an rpm without its
policy should a conflict arise that the user cannot resolve, but I can't
begin to imagine how to do automagic resolution of conflicts with the
current policy language.

Thanks very much for the feedback. It is much appreciated.

Chad


--
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: [RFC] Install SELinux policies from rpm package header

[Chad Sellers]

On 7/9/09 4:48 PM, "Daniel J Walsh" <dwalsh@redhat.com> wrote:
<snip>
> A couple of other problems with including policy with each rpm.  How do you
> handle different packaging.  MLS, Targeted, minimal.
> 
That is a problem we'll have to solve, but I don't think it will be too
difficult. We could easily provide an option to the %policy directive that
could direct rpm to use a particular policy store.

> If every package includes policy then we need to rely on the package
> maintainer to write good secure policy.  You have to realize that the goal of
> a package maintainer is to make the tool run, not necessarily to make sure it
> is secure or that other componants of the OS integrate well.
> 
> ftp sometimes need to read any file on the OS, so I will add
> files_read_all(ftp_t)
> 
> Now getting the few packages that ship their own policy to work better and the
> selinux-policy package to work better would be great.
> 
That's our initial goal. We want better infrastructure for the packages that
exist today. Policy can transition into other application packages if and
when it makes sense. If a package maintainer has no business touching
policy, then they will not be forced to do so.

> How about fixing things like semanage command
> 
> semanage fcontext ....
> semanage ports ....
> restorecon ...
> 
> 
> Removal of policy packages is a huge problem in that once a type is removed
> you end up with mislabeled files that can not be indentified.
> 
Agreed, and we've talked about some potential solutions to this problem that
do not involve automatic relabeling. This is a likely next step for this
work after the initial RPM integration.

> You do not know where these files are and you need to relabel the entire
> machine to make sure there are no longer any mislabeled files around.
> 
> When you update policy you need to run a diff between the old file context and
> the new and run a recusive restorecon on the diff.  fixfiles -C
> PREVIOUS_FILECONTEXT relabel does this for you, but every rpm transaction that
> does a policy modules update needs to run this at the completion of the
> transaction.  As well as squirrel away the previous file context before the
> transaction.

Running fixfiles -C after any rpm transaction that modifies policy seems
reasonable (as long as there's an option to disable this behavior for those
that don't like automatic relabeling).

Thanks very much,
Chad


--
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: [RFC] Install SELinux policies from rpm package header

[Joshua Brindle]

Chad Sellers wrote:
> On 7/9/09 4:48 PM, "Daniel J Walsh"<dwalsh@redhat.com>  wrote:
> <snip>
>> A couple of other problems with including policy with each rpm.  How do you
>> handle different packaging.  MLS, Targeted, minimal.
>>
> That is a problem we'll have to solve, but I don't think it will be too
> difficult. We could easily provide an option to the %policy directive that
> could direct rpm to use a particular policy store.
>
>> If every package includes policy then we need to rely on the package
>> maintainer to write good secure policy.  You have to realize that the goal of
>> a package maintainer is to make the tool run, not necessarily to make sure it
>> is secure or that other componants of the OS integrate well.
>>
>> ftp sometimes need to read any file on the OS, so I will add
>> files_read_all(ftp_t)
>>
>> Now getting the few packages that ship their own policy to work better and the
>> selinux-policy package to work better would be great.
>>
> That's our initial goal. We want better infrastructure for the packages that
> exist today. Policy can transition into other application packages if and
> when it makes sense. If a package maintainer has no business touching
> policy, then they will not be forced to do so.
>
>> How about fixing things like semanage command
>>
>> semanage fcontext ....
>> semanage ports ....
>> restorecon ...
>>
>>
>> Removal of policy packages is a huge problem in that once a type is removed
>> you end up with mislabeled files that can not be indentified.
>>
> Agreed, and we've talked about some potential solutions to this problem that
> do not involve automatic relabeling. This is a likely next step for this
> work after the initial RPM integration.
>

The more I think about this the less I like the idea of uninstalling policy. 
Even if we retain the labels (eg., save the namespace, ditch the rules) the 
files are inaccessible. Leaving the policy ensures that admins/backup 
apps/whatever can do whatever they could do before with the files, even if the 
associated app is gone.

>> You do not know where these files are and you need to relabel the entire
>> machine to make sure there are no longer any mislabeled files around.
>>
>> When you update policy you need to run a diff between the old file context and
>> the new and run a recusive restorecon on the diff.  fixfiles -C
>> PREVIOUS_FILECONTEXT relabel does this for you, but every rpm transaction that
>> does a policy modules update needs to run this at the completion of the
>> transaction.  As well as squirrel away the previous file context before the
>> transaction.
>
> Running fixfiles -C after any rpm transaction that modifies policy seems
> reasonable (as long as there's an option to disable this behavior for those
> that don't like automatic relabeling).
>

Its alot worse than that. What about files on backup drives? Offline drives? 
transient files that will get relabeled to something inappropriate? I'm not 
confortable relabeling databases with potentially sensitive data to var_lib_t 
because mysql was uninstalled.

--
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: [RFC] Install SELinux policies from rpm package header

[James Carter]

On Fri, 2009-07-10 at 10:55 -0400, Joshua Brindle wrote:
> Chad Sellers wrote:
> > On 7/9/09 4:48 PM, "Daniel J Walsh"<dwalsh@redhat.com>  wrote:
> > <snip>
> >> A couple of other problems with including policy with each rpm.  How do you
> >> handle different packaging.  MLS, Targeted, minimal.
> >>
> > That is a problem we'll have to solve, but I don't think it will be too
> > difficult. We could easily provide an option to the %policy directive that
> > could direct rpm to use a particular policy store.
> >
> >> If every package includes policy then we need to rely on the package
> >> maintainer to write good secure policy.  You have to realize that the goal of
> >> a package maintainer is to make the tool run, not necessarily to make sure it
> >> is secure or that other componants of the OS integrate well.
> >>
> >> ftp sometimes need to read any file on the OS, so I will add
> >> files_read_all(ftp_t)
> >>
> >> Now getting the few packages that ship their own policy to work better and the
> >> selinux-policy package to work better would be great.
> >>
> > That's our initial goal. We want better infrastructure for the packages that
> > exist today. Policy can transition into other application packages if and
> > when it makes sense. If a package maintainer has no business touching
> > policy, then they will not be forced to do so.
> >
> >> How about fixing things like semanage command
> >>
> >> semanage fcontext ....
> >> semanage ports ....
> >> restorecon ...
> >>
> >>
> >> Removal of policy packages is a huge problem in that once a type is removed
> >> you end up with mislabeled files that can not be indentified.
> >>
> > Agreed, and we've talked about some potential solutions to this problem that
> > do not involve automatic relabeling. This is a likely next step for this
> > work after the initial RPM integration.
> >
> 
> The more I think about this the less I like the idea of uninstalling policy. 
> Even if we retain the labels (eg., save the namespace, ditch the rules) the 
> files are inaccessible. Leaving the policy ensures that admins/backup 
> apps/whatever can do whatever they could do before with the files, even if the 
> associated app is gone.
> 
The same potential problems exist whenever policy modules (specifically
types) are removed.

Policy packages would be different from the current usage in two ways:
1) Policy modules would be removed when their associated application is
not installed, whereas currently policy modules are probably never
removed.
2) The removal would be automatic and right away, whereas currently an
admin could take other actions before manually removing the policy
module.

So policy packages would be more likely to expose the problems that
currently exist.

> >> You do not know where these files are and you need to relabel the entire
> >> machine to make sure there are no longer any mislabeled files around.
> >>
> >> When you update policy you need to run a diff between the old file context and
> >> the new and run a recusive restorecon on the diff.  fixfiles -C
> >> PREVIOUS_FILECONTEXT relabel does this for you, but every rpm transaction that
> >> does a policy modules update needs to run this at the completion of the
> >> transaction.  As well as squirrel away the previous file context before the
> >> transaction.
> >
> > Running fixfiles -C after any rpm transaction that modifies policy seems
> > reasonable (as long as there's an option to disable this behavior for those
> > that don't like automatic relabeling).
> >
> 
> Its alot worse than that. What about files on backup drives? Offline drives? 
> transient files that will get relabeled to something inappropriate? I'm not 
> confortable relabeling databases with potentially sensitive data to var_lib_t 
> because mysql was uninstalled.
> 

The argument seems to be for removing the ability to remove modules.
It would be the roach motel style of policy management.

> --
> 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.
-- 
James Carter <jwcart2@tycho.nsa.gov>
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: [RFC] Install SELinux policies from rpm package header

[Joshua Brindle]

> From: James Carter [mailto:jwcart2@tycho.nsa.gov] 
> 
> > Its alot worse than that. What about files on backup 
> drives? Offline drives? 
> > transient files that will get relabeled to something inappropriate? 
> > I'm not confortable relabeling databases with potentially sensitive 
> > data to var_lib_t because mysql was uninstalled.
> > 
> 
> The argument seems to be for removing the ability to remove modules.
> It would be the roach motel style of policy management.
> 

I like it, policies check in but don't check out. I haven't heard an
argument about 1) how I'm crazy and wrong or 2) how to keep systems
running as expected otherwise though.


--
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: [RFC] Install SELinux policies from rpm package header

[max bianco]

On Fri, Jul 10, 2009 at 11:58 AM, James Carter<jwcart2@tycho.nsa.gov> wrote:
> On Fri, 2009-07-10 at 10:55 -0400, Joshua Brindle wrote:
>> Chad Sellers wrote:
>> > On 7/9/09 4:48 PM, "Daniel J Walsh"<dwalsh@redhat.com>  wrote:
>> > <snip>
>> >> A couple of other problems with including policy with each rpm.  How do you
>> >> handle different packaging.  MLS, Targeted, minimal.
>> >>
>> > That is a problem we'll have to solve, but I don't think it will be too
>> > difficult. We could easily provide an option to the %policy directive that
>> > could direct rpm to use a particular policy store.
>> >
>> >> If every package includes policy then we need to rely on the package
>> >> maintainer to write good secure policy.  You have to realize that the goal of
>> >> a package maintainer is to make the tool run, not necessarily to make sure it
>> >> is secure or that other componants of the OS integrate well.
>> >>
>> >> ftp sometimes need to read any file on the OS, so I will add
>> >> files_read_all(ftp_t)
>> >>
>> >> Now getting the few packages that ship their own policy to work better and the
>> >> selinux-policy package to work better would be great.
>> >>
>> > That's our initial goal. We want better infrastructure for the packages that
>> > exist today. Policy can transition into other application packages if and
>> > when it makes sense. If a package maintainer has no business touching
>> > policy, then they will not be forced to do so.
>> >
>> >> How about fixing things like semanage command
>> >>
>> >> semanage fcontext ....
>> >> semanage ports ....
>> >> restorecon ...
>> >>
>> >>
>> >> Removal of policy packages is a huge problem in that once a type is removed
>> >> you end up with mislabeled files that can not be indentified.
>> >>
>> > Agreed, and we've talked about some potential solutions to this problem that
>> > do not involve automatic relabeling. This is a likely next step for this
>> > work after the initial RPM integration.
>> >
>>
>> The more I think about this the less I like the idea of uninstalling policy.
>> Even if we retain the labels (eg., save the namespace, ditch the rules) the
>> files are inaccessible. Leaving the policy ensures that admins/backup
>> apps/whatever can do whatever they could do before with the files, even if the
>> associated app is gone.
>>
> The same potential problems exist whenever policy modules (specifically
> types) are removed.
>
> Policy packages would be different from the current usage in two ways:
> 1) Policy modules would be removed when their associated application is
> not installed, whereas currently policy modules are probably never
> removed.
> 2) The removal would be automatic and right away, whereas currently an
> admin could take other actions before manually removing the policy
> module.
>
> So policy packages would be more likely to expose the problems that
> currently exist.
>
>> >> You do not know where these files are and you need to relabel the entire
>> >> machine to make sure there are no longer any mislabeled files around.
>> >>
>> >> When you update policy you need to run a diff between the old file context and
>> >> the new and run a recusive restorecon on the diff.  fixfiles -C
>> >> PREVIOUS_FILECONTEXT relabel does this for you, but every rpm transaction that
>> >> does a policy modules update needs to run this at the completion of the
>> >> transaction.  As well as squirrel away the previous file context before the
>> >> transaction.
>> >
>> > Running fixfiles -C after any rpm transaction that modifies policy seems
>> > reasonable (as long as there's an option to disable this behavior for those
>> > that don't like automatic relabeling).
>> >
>>
>> Its alot worse than that. What about files on backup drives? Offline drives?
>> transient files that will get relabeled to something inappropriate? I'm not
>> confortable relabeling databases with potentially sensitive data to var_lib_t
>> because mysql was uninstalled.
>>
>
> The argument seems to be for removing the ability to remove modules.
> It would be the roach motel style of policy management.
>
 Personally I am glad that this is in the works, I have really been
wanting some more control over what policy is installed, really I'd
rather not install packages without a policy. Nobody wants to leave it
up to the user and I don't blame them but trying to do this without
bugging the user is just begging for trouble. I could see a menu under
Authorizations (on Fedora) like this :

SELinux Policy Management

1. Install only signed policy (by signed I mean it was either
developed by the maintainers of refpolicy or reviewed by someone on
the distributions security team to ensure least privilege)

2. Prompt user for action : install signed policy, install policy
included with package, let me install my own policy or just run in the
user context

3. Let the app run unconfined or in a permissive domain - good for
tools like kismet that are sometimes a pain the ass to use in
conjunction with SELinux

4. Run the app in a generic sandbox

5. Install all policy regardless of source (discouraged)

Maybe authorizations isn't the place but that leaves  install time,
not a problem for me but many users will just swear in annoyance.

As to the ability to remove modules and potentially cause problems
like the database example, well that's a pickle and no mistake. I
would say give the files a separate unique context(created on the fly
if possible) that is only accessible by root, providing appropriate
warnings to the user about what they are doing and how to get access
to their files, as root then they can relabel it as they see fit. Just
a few thoughts, thanks for all your hard work. I sleep slightly better
with SELinux in enforcing mode :^)

--

Want to make an omelet? Start breaking eggs!!


--
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: [RFC] Install SELinux policies from rpm package header

[Paul Moore]

On Thursday 09 July 2009 05:13:20 pm Chad Sellers wrote:
> On 7/9/09 4:48 PM, "Daniel J Walsh" <dwalsh@redhat.com> wrote:
> <snip>
>
> > A couple of other problems with including policy with each rpm.  How do
> > you handle different packaging.  MLS, Targeted, minimal.
>
> That is a problem we'll have to solve, but I don't think it will be too
> difficult. We could easily provide an option to the %policy directive that
> could direct rpm to use a particular policy store.

Would that mean we could end up in a situation where a RPM only installs 
policy modules for a particular policy type, e.g. apache only installs a 
targeted policy module?  That seems like it could lead to real problems down 
the line as individual RPMs get this wrong.  Also, what happens at the unknown 
point in the future when we change from targeted as the de-facto default to 
some other name?

I like what you are trying to do here, it just scares me a little bit thinking 
about all the details (and I'm sure I'm only thinking about a small number of 
them too).

-- 
paul moore
linux @ hp


--
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: [RFC] Install SELinux policies from rpm package header

[Joshua Brindle]

Paul Moore wrote:
> On Thursday 09 July 2009 05:13:20 pm Chad Sellers wrote:
>> On 7/9/09 4:48 PM, "Daniel J Walsh"<dwalsh@redhat.com>  wrote:
>> <snip>
>>
>>> A couple of other problems with including policy with each rpm.  How do
>>> you handle different packaging.  MLS, Targeted, minimal.
>> That is a problem we'll have to solve, but I don't think it will be too
>> difficult. We could easily provide an option to the %policy directive that
>> could direct rpm to use a particular policy store.
>
> Would that mean we could end up in a situation where a RPM only installs
> policy modules for a particular policy type, e.g. apache only installs a
> targeted policy module?  That seems like it could lead to real problems down
> the line as individual RPMs get this wrong.  Also, what happens at the unknown
> point in the future when we change from targeted as the de-facto default to
> some other name?
>

I think if you don't list a store name explicitly it goes to default, I suspect 
that will be used in most cases. Regardless of this work we need some standard 
store names because otherwise instructions and blog entries and wherever else 
people get information about installing minimal or mls policies will be wrong.

> I like what you are trying to do here, it just scares me a little bit thinking
> about all the details (and I'm sure I'm only thinking about a small number of
> them too).
>

There are devils in the details for sure, we are just talking first steps for now.

--
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: [RFC] Install SELinux policies from rpm package header

[James Carter]

On Fri, 2009-07-10 at 16:26 -0400, Joshua Brindle wrote:
> > From: James Carter [mailto:jwcart2@tycho.nsa.gov] 
> > 
> > > Its alot worse than that. What about files on backup 
> > drives? Offline drives? 
> > > transient files that will get relabeled to something inappropriate? 
> > > I'm not confortable relabeling databases with potentially sensitive 
> > > data to var_lib_t because mysql was uninstalled.
> > > 
> > 
> > The argument seems to be for removing the ability to remove modules.
> > It would be the roach motel style of policy management.
> > 
> 
> I like it, policies check in but don't check out. I haven't heard an
> argument about 1) how I'm crazy and wrong or 2) how to keep systems
> running as expected otherwise though.
> 
1)
I'll let your co-workers comment on your insanity or lack thereof.

You're not wrong.

The general problem here is how two systems using different policies
interoperate.  For one of the systems to access a resource labeled under
the second system's policy, the request must be translated in a way that
is consistent with the overall security goals of the two systems.  There
is no way to automatically do this for arbitrary policies.

Anytime the system policy is changed (loading or unloading modules,
updating policy, etc) we have two systems (past and present) using
different policies.  The labels of the old policy must be translated so
that the overall security goals are met with the new policy.  

Often the reason for the change is that the old policy was found to be
more restrictive than the overall security goals, so the new policy is
more permissive and no labels are required to be changed.  No
translation is usually necessary in this case, just load the new
policy.  

When making more radical changes, more elaborate translation steps are
needed.  As an example, to remove the unconfined module one needs to
switch the system to permissive mode, set the system up to relabel on
the next reboot, remove the unconfined module, and reboot.  In this
example, the translation between the two policies is done by rebooting
the system and relabeling the filesystem.  This example also shows that
temporary policy changes (setting permissive mode) might be necessary
during the period of translation.

2)
So to keep systems running, there needs to be a way to do the steps
required to translate between the two policies.  That could require
loading additional policy, switching the system to permissive mode,
setting the system up to relabel the filesystem, and requesting that the
user reboots the system.

Again, this is not a problem specific to policy packages.

-- 
James Carter <jwcart2@tycho.nsa.gov>
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: [RFC] Install SELinux policies from rpm package header

[James Carter]

On Mon, 2009-07-13 at 10:55 -0400, James Carter wrote:
> 
> 2)
> So to keep systems running, there needs to be a way to do the steps
> required to translate between the two policies.  That could require
> loading additional policy, switching the system to permissive mode,
> setting the system up to relabel the filesystem, and requesting that the
> user reboots the system.

Or there needs to be a way to specify when RPM isn't capable of doing
the necessary translation, so the admin can be informed of what did and
did not happen and (ideally) what he needs to do.

-- 
James Carter <jwcart2@tycho.nsa.gov>
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: [RFC] Install SELinux policies from rpm package header

[Chad Sellers]

On 7/10/09 4:26 PM, "Joshua Brindle" <jbrindle@tresys.com> wrote:

>> From: James Carter [mailto:jwcart2@tycho.nsa.gov]
>> 
>>> Its alot worse than that. What about files on backup
>> drives? Offline drives?
>>> transient files that will get relabeled to something inappropriate?
>>> I'm not confortable relabeling databases with potentially sensitive
>>> data to var_lib_t because mysql was uninstalled.
>>> 
>> 
>> The argument seems to be for removing the ability to remove modules.
>> It would be the roach motel style of policy management.
>> 
> 
> I like it, policies check in but don't check out. I haven't heard an
> argument about 1) how I'm crazy and wrong or 2) how to keep systems
> running as expected otherwise though.

There's certainly a case for leaving all policy installed. Policy is
configuration data, which RPM also leaves installed when removing packages.
We could easily treat policy the same.

Chad


--
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: [RFC] Install SELinux policies from rpm package header

[Joe Nall]

On Jul 13, 2009, at 11:15 AM, Chad Sellers wrote:

> On 7/10/09 4:26 PM, "Joshua Brindle" <jbrindle@tresys.com> wrote:
>
>>> From: James Carter [mailto:jwcart2@tycho.nsa.gov]
>>>
>>>> Its alot worse than that. What about files on backup
>>> drives? Offline drives?
>>>> transient files that will get relabeled to something inappropriate?
>>>> I'm not confortable relabeling databases with potentially sensitive
>>>> data to var_lib_t because mysql was uninstalled.
>>>>
>>>
>>> The argument seems to be for removing the ability to remove modules.
>>> It would be the roach motel style of policy management.
>>>
>>
>> I like it, policies check in but don't check out. I haven't heard an
>> argument about 1) how I'm crazy and wrong or 2) how to keep systems
>> running as expected otherwise though.
>
> There's certainly a case for leaving all policy installed. Policy is
> configuration data, which RPM also leaves installed when removing  
> packages.
> We could easily treat policy the same.

Our app has 140 rpms that install policy. They install in the %post  
and do a restorecon of the relevant installed files and /etc/selinux/ 
mls/modules. Daemons are stopped in the %preun. Policy is removed in  
the %postun and more restorecon occurs. The biggest annoyance with  
this approach is the 140 individual transactions are ssllooww.

I would really like to see policy batched up and installed early in  
the transaction. I think blindly leaving the policy behind on  
uninstall is configuration management insanity. When an rpm is  
removed, all of the unmodified installation should be removed with it.  
Files should be relabeled to match the post installation policy. That  
way a subsequent install behaves the way you would intuitively expect.

If the app developer is concerned about the post-uninstall type  
enforcement on application created files, a separate policy rpm solves  
the problem.

joe



--
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: [RFC] Install SELinux policies from rpm package header

[Joshua Brindle]

Joe Nall wrote:
>
> On Jul 13, 2009, at 11:15 AM, Chad Sellers wrote:
>
>> On 7/10/09 4:26 PM, "Joshua Brindle" <jbrindle@tresys.com> wrote:
>>
>>>> From: James Carter [mailto:jwcart2@tycho.nsa.gov]
>>>>
>>>>> Its alot worse than that. What about files on backup
>>>> drives? Offline drives?
>>>>> transient files that will get relabeled to something inappropriate?
>>>>> I'm not confortable relabeling databases with potentially sensitive
>>>>> data to var_lib_t because mysql was uninstalled.
>>>>>
>>>>
>>>> The argument seems to be for removing the ability to remove modules.
>>>> It would be the roach motel style of policy management.
>>>>
>>>
>>> I like it, policies check in but don't check out. I haven't heard an
>>> argument about 1) how I'm crazy and wrong or 2) how to keep systems
>>> running as expected otherwise though.
>>
>> There's certainly a case for leaving all policy installed. Policy is
>> configuration data, which RPM also leaves installed when removing
>> packages.
>> We could easily treat policy the same.
>
> Our app has 140 rpms that install policy. They install in the %post and
> do a restorecon of the relevant installed files and
> /etc/selinux/mls/modules. Daemons are stopped in the %preun. Policy is
> removed in the %postun and more restorecon occurs. The biggest annoyance
> with this approach is the 140 individual transactions are ssllooww.
>

Yes, if you want to test out the patch sent to the rpm list and report results 
with lots of policy packages that would be awesome :)

> I would really like to see policy batched up and installed early in the
> transaction. I think blindly leaving the policy behind on uninstall is
> configuration management insanity. When an rpm is removed, all of the
> unmodified installation should be removed with it. Files should be
> relabeled to match the post installation policy. That way a subsequent
> install behaves the way you would intuitively expect.
>

I see the claim but I don't see the argument. A subsequent install will either 
replace the old module or do nothing (if its the same) and all the old files 
will already be labeled properly, in fact this is the main reason I want to 
leave old policies around. Note that users will always be able to remove 
policies themselves, I just don't think we can make rpm smart enough to know the 
users intentions (perhaps if it was written in python we could just import 
psychic :) )

> If the app developer is concerned about the post-uninstall type
> enforcement on application created files, a separate policy rpm solves
> the problem.
>

This isn't practical. Sure some app developer may write an uninstall module but 
those aren't going to exist for all the policies in refpolicy.

A kind-of-like-this idea I came up with was to have an "uninstall template" that 
would take the old module, find the file types and fill in the uninstall 
template policy with that, that way files would keep their types and the 
uninstall template could give admins/backup apps/etc continuing access. I feel 
like this would be far too fragile and easy to mess up though.

--
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: [RFC] Install SELinux policies from rpm package header

[Joe Nall]

On Jul 13, 2009, at 12:40 PM, Joshua Brindle wrote:

> Joe Nall wrote:
>>
>> On Jul 13, 2009, at 11:15 AM, Chad Sellers wrote:
>>
>>> On 7/10/09 4:26 PM, "Joshua Brindle" <jbrindle@tresys.com> wrote:
>>>
>>>>> From: James Carter [mailto:jwcart2@tycho.nsa.gov]
>>>>>
>>>>>> Its alot worse than that. What about files on backup
>>>>> drives? Offline drives?
>>>>>> transient files that will get relabeled to something  
>>>>>> inappropriate?
>>>>>> I'm not confortable relabeling databases with potentially  
>>>>>> sensitive
>>>>>> data to var_lib_t because mysql was uninstalled.
>>>>>>
>>>>>
>>>>> The argument seems to be for removing the ability to remove  
>>>>> modules.
>>>>> It would be the roach motel style of policy management.
>>>>>
>>>>
>>>> I like it, policies check in but don't check out. I haven't heard  
>>>> an
>>>> argument about 1) how I'm crazy and wrong or 2) how to keep systems
>>>> running as expected otherwise though.
>>>
>>> There's certainly a case for leaving all policy installed. Policy is
>>> configuration data, which RPM also leaves installed when removing
>>> packages.
>>> We could easily treat policy the same.
>>
>> Our app has 140 rpms that install policy. They install in the %post  
>> and
>> do a restorecon of the relevant installed files and
>> /etc/selinux/mls/modules. Daemons are stopped in the %preun. Policy  
>> is
>> removed in the %postun and more restorecon occurs. The biggest  
>> annoyance
>> with this approach is the 140 individual transactions are ssllooww.
>>
>
> Yes, if you want to test out the patch sent to the rpm list and  
> report results with lots of policy packages that would be awesome :)
>
>> I would really like to see policy batched up and installed early in  
>> the
>> transaction. I think blindly leaving the policy behind on uninstall  
>> is
>> configuration management insanity. When an rpm is removed, all of the
>> unmodified installation should be removed with it. Files should be
>> relabeled to match the post installation policy. That way a  
>> subsequent
>> install behaves the way you would intuitively expect.
>>
>
> I see the claim but I don't see the argument. A subsequent install  
> will either replace the old module or do nothing (if its the same)  
> and all the old files will already be labeled properly, in fact this  
> is the main reason I want to leave old policies around. Note that  
> users will always be able to remove policies themselves, I just  
> don't think we can make rpm smart enough to know the users  
> intentions (perhaps if it was written in python we could just import  
> psychic :) )

We are going to have to disagree on what is proper. Based on our  
experience with multiple policies, I think you are going to get into  
trouble with policy upgrades when type declarations move or multiple  
rpms declare the same type in policy. You have to think about how  
policies and rpms evolve over time.

joe

>> If the app developer is concerned about the post-uninstall type
>> enforcement on application created files, a separate policy rpm  
>> solves
>> the problem.
>>
>
> This isn't practical. Sure some app developer may write an uninstall  
> module but those aren't going to exist for all the policies in  
> refpolicy.
>
> A kind-of-like-this idea I came up with was to have an "uninstall  
> template" that would take the old module, find the file types and  
> fill in the uninstall template policy with that, that way files  
> would keep their types and the uninstall template could give admins/ 
> backup apps/etc continuing access. I feel like this would be far too  
> fragile and easy to mess up though.
>
> --
> 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.


--
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: [RFC] Install SELinux policies from rpm package header

[Joshua Brindle]

> From: Joe Nall [mailto:joe@nall.com] 
> 
> On Jul 13, 2009, at 12:40 PM, Joshua Brindle wrote:
> 
> > Joe Nall wrote:
> >>
> >> On Jul 13, 2009, at 11:15 AM, Chad Sellers wrote:
> >>
> >>> On 7/10/09 4:26 PM, "Joshua Brindle" <jbrindle@tresys.com> wrote:
> >>>
> >>>>> From: James Carter [mailto:jwcart2@tycho.nsa.gov]
> >>>>>
> >>>>>> Its alot worse than that. What about files on backup
> >>>>> drives? Offline drives?
> >>>>>> transient files that will get relabeled to something 
> >>>>>> inappropriate?
> >>>>>> I'm not confortable relabeling databases with potentially 
> >>>>>> sensitive data to var_lib_t because mysql was uninstalled.
> >>>>>>
> >>>>>
> >>>>> The argument seems to be for removing the ability to remove 
> >>>>> modules.
> >>>>> It would be the roach motel style of policy management.
> >>>>>
> >>>>
> >>>> I like it, policies check in but don't check out. I 
> haven't heard 
> >>>> an argument about 1) how I'm crazy and wrong or 2) how to keep 
> >>>> systems running as expected otherwise though.
> >>>
> >>> There's certainly a case for leaving all policy 
> installed. Policy is 
> >>> configuration data, which RPM also leaves installed when removing 
> >>> packages.
> >>> We could easily treat policy the same.
> >>
> >> Our app has 140 rpms that install policy. They install in 
> the %post 
> >> and do a restorecon of the relevant installed files and 
> >> /etc/selinux/mls/modules. Daemons are stopped in the 
> %preun. Policy 
> >> is removed in the %postun and more restorecon occurs. The biggest 
> >> annoyance with this approach is the 140 individual 
> transactions are 
> >> ssllooww.
> >>
> >
> > Yes, if you want to test out the patch sent to the rpm list 
> and report 
> > results with lots of policy packages that would be awesome :)
> >
> >> I would really like to see policy batched up and installed 
> early in 
> >> the transaction. I think blindly leaving the policy behind on 
> >> uninstall is configuration management insanity. When an rpm is 
> >> removed, all of the unmodified installation should be removed with 
> >> it. Files should be relabeled to match the post 
> installation policy. 
> >> That way a subsequent install behaves the way you would 
> intuitively 
> >> expect.
> >>
> >
> > I see the claim but I don't see the argument. A subsequent install 
> > will either replace the old module or do nothing (if its 
> the same) and 
> > all the old files will already be labeled properly, in fact this is 
> > the main reason I want to leave old policies around. Note 
> that users 
> > will always be able to remove policies themselves, I just 
> don't think 
> > we can make rpm smart enough to know the users intentions 
> (perhaps if 
> > it was written in python we could just import psychic :) )
> 
> We are going to have to disagree on what is proper. Based on 
> our experience with multiple policies, I think you are going 
> to get into trouble with policy upgrades when type 
> declarations move or multiple rpms declare the same type in 
> policy. You have to think about how policies and rpms evolve 
> over time.
> 

So renames are a different issue that we are thinking about. Eg., if a
module claims to replace a module meaning it provides the same
type-space and behavior then we need some facility for telling rpm so it
can remove the old and add the new during the same transaction, this is
already a work in progress.

Removing a policy entirely is what the above thread was about, and I
still maintain that automated removal of policies is a bad idea,
violates the principle of least surprise and has the potential of
leaking sensitive data or leaving the system inconsisten or
non-functional.


--
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: [RFC] Install SELinux policies from rpm package header

[Chad Sellers]

On 7/10/09 5:11 PM, "max bianco" <maximilianbianco@gmail.com> wrote:
>  Personally I am glad that this is in the works, I have really been
> wanting some more control over what policy is installed, really I'd
> rather not install packages without a policy. Nobody wants to leave it
> up to the user and I don't blame them but trying to do this without
> bugging the user is just begging for trouble. I could see a menu under
> Authorizations (on Fedora) like this :
> 
> SELinux Policy Management
> 
> 1. Install only signed policy (by signed I mean it was either
> developed by the maintainers of refpolicy or reviewed by someone on
> the distributions security team to ensure least privilege)
> 
> 2. Prompt user for action : install signed policy, install policy
> included with package, let me install my own policy or just run in the
> user context
> 
> 3. Let the app run unconfined or in a permissive domain - good for
> tools like kismet that are sometimes a pain the ass to use in
> conjunction with SELinux
> 
> 4. Run the app in a generic sandbox
> 
> 5. Install all policy regardless of source (discouraged)
> 
We've actually thought of some of those same features. Our goal right now is
to start by getting support for installing policy into RPM, and then move
into looking at ways to give the user more control over what policy gets
installed.

Chad


--
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: [RFC] Install SELinux policies from rpm package header

[Daniel J Walsh]

On 07/13/2009 02:52 PM, Joshua Brindle wrote:
>> From: Joe Nall [mailto:joe@nall.com]
>>
>> On Jul 13, 2009, at 12:40 PM, Joshua Brindle wrote:
>>
>>> Joe Nall wrote:
>>>> On Jul 13, 2009, at 11:15 AM, Chad Sellers wrote:
>>>>
>>>>> On 7/10/09 4:26 PM, "Joshua Brindle"<jbrindle@tresys.com>  wrote:
>>>>>
>>>>>>> From: James Carter [mailto:jwcart2@tycho.nsa.gov]
>>>>>>>
>>>>>>>> Its alot worse than that. What about files on backup
>>>>>>> drives? Offline drives?
>>>>>>>> transient files that will get relabeled to something
>>>>>>>> inappropriate?
>>>>>>>> I'm not confortable relabeling databases with potentially
>>>>>>>> sensitive data to var_lib_t because mysql was uninstalled.
>>>>>>>>
>>>>>>> The argument seems to be for removing the ability to remove
>>>>>>> modules.
>>>>>>> It would be the roach motel style of policy management.
>>>>>>>
>>>>>> I like it, policies check in but don't check out. I
>> haven't heard
>>>>>> an argument about 1) how I'm crazy and wrong or 2) how to keep
>>>>>> systems running as expected otherwise though.
>>>>> There's certainly a case for leaving all policy
>> installed. Policy is
>>>>> configuration data, which RPM also leaves installed when removing
>>>>> packages.
>>>>> We could easily treat policy the same.
>>>> Our app has 140 rpms that install policy. They install in
>> the %post
>>>> and do a restorecon of the relevant installed files and
>>>> /etc/selinux/mls/modules. Daemons are stopped in the
>> %preun. Policy
>>>> is removed in the %postun and more restorecon occurs. The biggest
>>>> annoyance with this approach is the 140 individual
>> transactions are
>>>> ssllooww.
>>>>
>>> Yes, if you want to test out the patch sent to the rpm list
>> and report
>>> results with lots of policy packages that would be awesome :)
>>>
>>>> I would really like to see policy batched up and installed
>> early in
>>>> the transaction. I think blindly leaving the policy behind on
>>>> uninstall is configuration management insanity. When an rpm is
>>>> removed, all of the unmodified installation should be removed with
>>>> it. Files should be relabeled to match the post
>> installation policy.
>>>> That way a subsequent install behaves the way you would
>> intuitively
>>>> expect.
>>>>
>>> I see the claim but I don't see the argument. A subsequent install
>>> will either replace the old module or do nothing (if its
>> the same) and
>>> all the old files will already be labeled properly, in fact this is
>>> the main reason I want to leave old policies around. Note
>> that users
>>> will always be able to remove policies themselves, I just
>> don't think
>>> we can make rpm smart enough to know the users intentions
>> (perhaps if
>>> it was written in python we could just import psychic :) )
>> We are going to have to disagree on what is proper. Based on
>> our experience with multiple policies, I think you are going
>> to get into trouble with policy upgrades when type
>> declarations move or multiple rpms declare the same type in
>> policy. You have to think about how policies and rpms evolve
>> over time.
>>
>
> So renames are a different issue that we are thinking about. Eg., if a
> module claims to replace a module meaning it provides the same
> type-space and behavior then we need some facility for telling rpm so it
> can remove the old and add the new during the same transaction, this is
> already a work in progress.
>
> Removing a policy entirely is what the above thread was about, and I
> still maintain that automated removal of policies is a bad idea,
> violates the principle of least surprise and has the potential of
> leaking sensitive data or leaving the system inconsisten or
> non-functional.
One Idea I had was to have two policies.  One for install and one for 
uninstall, the uninstall policy takes all of the types defined in the 
install and typealias them to some base name.

httpd_exec_t == bin_t
httpd_var_run_t == var_run_t

...



--
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: [RFC] Install SELinux policies from rpm package header

[Joshua Brindle]

> From: Daniel J Walsh [mailto:dwalsh@redhat.com] 
> 
> On 07/13/2009 02:52 PM, Joshua Brindle wrote:
> >> From: Joe Nall [mailto:joe@nall.com]
> >>
> >> On Jul 13, 2009, at 12:40 PM, Joshua Brindle wrote:
> >>
> >>> Joe Nall wrote:
> >>>> On Jul 13, 2009, at 11:15 AM, Chad Sellers wrote:
> >>>>
> >>>>> On 7/10/09 4:26 PM, "Joshua 
> Brindle"<jbrindle@tresys.com>  wrote:
> >>>>>
> >>>>>>> From: James Carter [mailto:jwcart2@tycho.nsa.gov]
> >>>>>>>
> >>>>>>>> Its alot worse than that. What about files on backup
> >>>>>>> drives? Offline drives?
> >>>>>>>> transient files that will get relabeled to something 
> >>>>>>>> inappropriate?
> >>>>>>>> I'm not confortable relabeling databases with potentially 
> >>>>>>>> sensitive data to var_lib_t because mysql was uninstalled.
> >>>>>>>>
> >>>>>>> The argument seems to be for removing the ability to remove 
> >>>>>>> modules.
> >>>>>>> It would be the roach motel style of policy management.
> >>>>>>>
> >>>>>> I like it, policies check in but don't check out. I
> >> haven't heard
> >>>>>> an argument about 1) how I'm crazy and wrong or 2) how to keep 
> >>>>>> systems running as expected otherwise though.
> >>>>> There's certainly a case for leaving all policy
> >> installed. Policy is
> >>>>> configuration data, which RPM also leaves installed 
> when removing 
> >>>>> packages.
> >>>>> We could easily treat policy the same.
> >>>> Our app has 140 rpms that install policy. They install in
> >> the %post
> >>>> and do a restorecon of the relevant installed files and 
> >>>> /etc/selinux/mls/modules. Daemons are stopped in the
> >> %preun. Policy
> >>>> is removed in the %postun and more restorecon occurs. 
> The biggest 
> >>>> annoyance with this approach is the 140 individual
> >> transactions are
> >>>> ssllooww.
> >>>>
> >>> Yes, if you want to test out the patch sent to the rpm list
> >> and report
> >>> results with lots of policy packages that would be awesome :)
> >>>
> >>>> I would really like to see policy batched up and installed
> >> early in
> >>>> the transaction. I think blindly leaving the policy behind on 
> >>>> uninstall is configuration management insanity. When an rpm is 
> >>>> removed, all of the unmodified installation should be 
> removed with 
> >>>> it. Files should be relabeled to match the post
> >> installation policy.
> >>>> That way a subsequent install behaves the way you would
> >> intuitively
> >>>> expect.
> >>>>
> >>> I see the claim but I don't see the argument. A 
> subsequent install 
> >>> will either replace the old module or do nothing (if its
> >> the same) and
> >>> all the old files will already be labeled properly, in 
> fact this is 
> >>> the main reason I want to leave old policies around. Note
> >> that users
> >>> will always be able to remove policies themselves, I just
> >> don't think
> >>> we can make rpm smart enough to know the users intentions
> >> (perhaps if
> >>> it was written in python we could just import psychic :) )
> >> We are going to have to disagree on what is proper. Based on our 
> >> experience with multiple policies, I think you are going 
> to get into 
> >> trouble with policy upgrades when type declarations move 
> or multiple 
> >> rpms declare the same type in policy. You have to think about how 
> >> policies and rpms evolve over time.
> >>
> >
> > So renames are a different issue that we are thinking 
> about. Eg., if a 
> > module claims to replace a module meaning it provides the same 
> > type-space and behavior then we need some facility for 
> telling rpm so 
> > it can remove the old and add the new during the same transaction, 
> > this is already a work in progress.
> >
> > Removing a policy entirely is what the above thread was 
> about, and I 
> > still maintain that automated removal of policies is a bad idea, 
> > violates the principle of least surprise and has the potential of 
> > leaking sensitive data or leaving the system inconsisten or 
> > non-functional.
> One Idea I had was to have two policies.  One for install and 
> one for uninstall, the uninstall policy takes all of the 
> types defined in the install and typealias them to some base name.
> 
> httpd_exec_t == bin_t
> httpd_var_run_t == var_run_t
> 

Yes, that is an option. Karl talked about using the type hierarchy to
gracefully degrade types automatically in the past, I doubt this is
practical though since the type hierarchy used for security dominance is
unlikely to also represent some functional degradation of types. Further
I suspect that bin_t, for example, isn't currently a superset of all
exec types.

This is sort of like my uninstall template idea except that I was
thinking the types would stick around and allow rules that allowed
admins and backup programs to continue the access would be put in place.
If someone was willing to do uninstall sections of all the policies I
suppose this idea could work. This may be worth considering for the new
intermediate language work.


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