Loadable Modules and RPM

Loadable Modules and RPM

[Daniel J Walsh]

Jeremy and I were talking yesterday about how we could/should package 
the new loadable policy.  
He restated again that policy should be with the RPM package.  So apache 
should contain it's own policy.  

Two problems have always existed with this:
First it eliminates the possibility of having different policies for 
different policy types.  IE it makes it harder to have a apache_targeted 
policy or apache_mls policy.  In practice this is not such a big thing 
since the "Targeted" or server based
policies are mostly common across the currently defined policies.  We 
have one apache policy for Targeted, Strict and MLS with minor tweaks.  
The new policy language has the ability to divine optional sections to 
take care of these differences.

The Second problem involves file context.  Basically the kernel has to 
know the file_context before rpm lays the files down on disk.  Because 
it verifies that system_u:object_r:httpd_exec_t exists.  So applications 
need to install/reload policy before the files get put on disk.  What 
would happen if we changed the kernel to allow certain privileged 
applications to write security context onto disk, which the kernel does 
not understand.  The kernel could just treat these files as 
unlabeled_t.  Then the RPM package could contain the file_context to 
place on disk, install the files with the correct context.  In the post 
install script it could add its policy  and load it into the kernel.  At 
which point the kernel would understand the file context.  

Having policy with the package would then allow us to just update 
individual packages rather then the entire policy package.

Thoughts?

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: Loadable Modules and RPM

[Stephen Smalley]

On Fri, 2005-10-07 at 15:58 -0400, Daniel J Walsh wrote:
> Two problems have always existed with this:
> First it eliminates the possibility of having different policies for 
> different policy types.  IE it makes it harder to have a apache_targeted 
> policy or apache_mls policy.  In practice this is not such a big thing 
> since the "Targeted" or server based
> policies are mostly common across the currently defined policies.  We 
> have one apache policy for Targeted, Strict and MLS with minor tweaks.  
> The new policy language has the ability to divine optional sections to 
> take care of these differences.

What about introducing a level of indirection by having apache (httpd)
depend on a separate httpd-policy package, and likewise for other
packages that have associated policy modules?  I think Hardened Gentoo
did something along those lines.

> The Second problem involves file context.  Basically the kernel has to 
> know the file_context before rpm lays the files down on disk.  Because 
> it verifies that system_u:object_r:httpd_exec_t exists.  So applications 
> need to install/reload policy before the files get put on disk.  What 
> would happen if we changed the kernel to allow certain privileged 
> applications to write security context onto disk, which the kernel does 
> not understand.  The kernel could just treat these files as 
> unlabeled_t.  Then the RPM package could contain the file_context to 
> place on disk, install the files with the correct context.  In the post 
> install script it could add its policy  and load it into the kernel.  At 
> which point the kernel would understand the file context.

That makes it more difficult to ever confine rpm in any way.  It also is
problematic on the kernel side even if we wanted this behavior; the
kernel doesn't presently recheck the security contexts of already incore
inodes upon a policy reload.  If they have a SID that is invalidated by
the policy load, then they will subsequently be treated as unlabeled,
but if they start as unlabeled and then you add the type via a policy
reload, the incore inode label won't be reset until they are evicted
from memory and re-acquired by a lookup.

I think you need to reload policy first, and it will be easier to do so
if you separate out the policy into its own package, just one per
application package, ala httpd-policy.  Ideally, you'd allow a way for
httpd-policy to be provided by multiple packages, so we could have
httpd-mls-policy, httpd-targeted-policy, httpd-strict-policy.  I'm not
sure that the module ifopt support is going to be enough for those kinds
of differences.

-- 
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: Loadable Modules and RPM

[Stephen Smalley]

On Fri, 2005-10-07 at 17:51 -0400, Jeremy Katz wrote:
> And then you end up with separate packages with the policy for every
> package shipped in the distribution.  Which is just absurd.  The
> problems with keeping things in sync get massively more complicated in
> addition to the cost of adding lots of packages

Hmmm...I thought someone had mentioned that a similar system is used for
translation strings, but possibly not (or possibly you don't want to
make it worse).

> When you put it like that, it sounds more and more like a bug which
> should be fixed.  If you load a new policy, then I'd think that anything
> which was unlabeled should definitely be re-evaluated.  Otherwise, you
> have a large potential for problems if you boot with a "wrong" policy
> and try to fix without a reboot.

You can still fix from userspace by relabeling the affected files
(although in the past, userspace has gotten confused about what the
actual label is on the file, but James' recent patch queued up for
2.6.15 addresses that issue).  Having the kernel walk the incore inode
lists on every policy reload seems fairly painful for what is
essentially a policy mistake.

-- 
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: Loadable Modules and RPM

[Joshua Brindle]

Jeremy Katz wrote:
> On Fri, 2005-10-07 at 17:30 -0400, Stephen Smalley wrote:
> 
>>On Fri, 2005-10-07 at 15:58 -0400, Daniel J Walsh wrote:
>>
>>>Two problems have always existed with this:
>>>First it eliminates the possibility of having different policies for 
>>>different policy types.  IE it makes it harder to have a apache_targeted 
>>>policy or apache_mls policy.  In practice this is not such a big thing 
>>>since the "Targeted" or server based
>>>policies are mostly common across the currently defined policies.  We 
>>>have one apache policy for Targeted, Strict and MLS with minor tweaks.  
>>>The new policy language has the ability to divine optional sections to 
>>>take care of these differences.
>>
>>What about introducing a level of indirection by having apache (httpd)
>>depend on a separate httpd-policy package, and likewise for other
>>packages that have associated policy modules?  I think Hardened Gentoo
>>did something along those lines.
> 
> 
> And then you end up with separate packages with the policy for every
> package shipped in the distribution.  Which is just absurd.  The
> problems with keeping things in sync get massively more complicated in
> addition to the cost of adding lots of packages
> 
you mean potentially for every target, which is around 100 at this 
point, but maybe less than that, from what dan has shown us he only has 
around 30 policy modules building as loadable modules, this will no 
doubt increase.
> 
>>>The Second problem involves file context.  Basically the kernel has to 
>>>know the file_context before rpm lays the files down on disk.  Because 
>>>it verifies that system_u:object_r:httpd_exec_t exists.  So applications 
>>>need to install/reload policy before the files get put on disk.  What 
>>>would happen if we changed the kernel to allow certain privileged 
>>>applications to write security context onto disk, which the kernel does 
>>>not understand.  The kernel could just treat these files as 
>>>unlabeled_t.  Then the RPM package could contain the file_context to 
>>>place on disk, install the files with the correct context.  In the post 
>>>install script it could add its policy  and load it into the kernel.  At 
>>>which point the kernel would understand the file context.
>>
>>That makes it more difficult to ever confine rpm in any way.  
> 
> 
> FWIW, I think there are cases where this behavior is desirable for
> things other than just rpm.  Think about diskless systems which may be
> booting a different kernel with a different policy and range of types
> than their server -- this makes it so you can't set the context when
> creating a chroot for them.
> 

Right now rpm isn't confined but surely that is desirable in the future, 
  but like Steve said, allowing apps to set unknown security attributes 
on files makes it essentially unconfinable.

> 
>>It also is
>>problematic on the kernel side even if we wanted this behavior; the
>>kernel doesn't presently recheck the security contexts of already incore
>>inodes upon a policy reload.  If they have a SID that is invalidated by
>>the policy load, then they will subsequently be treated as unlabeled,
>>but if they start as unlabeled and then you add the type via a policy
>>reload, the incore inode label won't be reset until they are evicted
>>from memory and re-acquired by a lookup.
> 
> 
> When you put it like that, it sounds more and more like a bug which
> should be fixed.  If you load a new policy, then I'd think that anything
> which was unlabeled should definitely be re-evaluated.  Otherwise, you
> have a large potential for problems if you boot with a "wrong" policy
> and try to fix without a reboot.
> 

this is problematic anyway, it is difficult to start with the wrong 
policy and then fix every processes type (not just files are affected by 
this) without a reboot.

IMO having policy packages has many more advantages, having to reinstall 
  apache for a policy change doesn't seem desirable, and having 
disparate policies will make it difficult to package them with the 
application.

Further, switching policies altogether is very difficult if you package 
the policies with the applications, consider switching from targeted to 
strict. For now (we don't know how this we play out) assert that there 
will be a different loadable module for apache for strict and targeted. 
To switch from targeted to strict you'd have to switch the base module, 
and then switch each target to the strict version.

Basically what would happen is that every target would have to be 
removed, the strict base would have to be installed, and then each 
application would have to be reinstalled, rebuilding and reloading the 
policy each time. However, if the policy modules were seperate packages 
you could install them all ahead of time, start a transaction where you 
remove all targeted modules (including base), and then install the 
strict base and all associated modules. This provides a single, 
transactional policy switch.

Joshua

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