[RFC] Checking the loaded policy against a policy on disk

[RFC] Checking the loaded policy against a policy on disk

[Stephen Smalley]

Hi,

For the LSPP work, it has been requested that we provide a way to
perform a consistency check between the policy in memory and the policy
on disk.  We could change the SELinux module to compute a checksum over
the binary policy image when it is loaded and to export that checksum
via a new selinuxfs node.  One complicating factor is that at
present, /sbin/init and load_policy mutate the binary policy image in
memory prior to loading it in order to customize the vendor-shipped
policy with local boolean settings and user definitions, so the
checksums would not match at present for the on-disk file and the
in-memory image unless the verification tool applies the same transforms
prior to computing the checksums.  Tresys has previously suggested
shifting to a model where we regenerate the on-disk policy file for each
change to any local setting, with the generated policy file to be loaded
into the kernel stored separately from the policy file managed by rpm to
avoid creating problems for updates, which would eliminate that problem
altogether.

Any comments on this request?  Any particular preference as to the
particular checksum algorithm?  Does the algorithm need to be
configurable?

A related idea would be to also extend the binary policy format to
include a field for an arbitrary text string label that could be set
when the policy is generated, and have the kernel save that string and
export it via another new selinuxfs node.  This would allow an
identifier string to be associated with the policy image, such as the
policy package's name and version (e.g.
selinux-policy-targeted-1.17.25-3), and extracted later by userspace to
determine which particular policy the one in memory is supposed to
match.  This wouldn't replace the need for the checksum, but would
provide additional information that might be helpful to userspace.
However, this change would require a change in binary policy format,
unlike the first change.  

Any comments on this related idea?
  
-- 
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: [RFC] Checking the loaded policy against a policy on disk

[Joshua Brindle]

Stephen Smalley wrote:

>Hi,
>
>For the LSPP work, it has been requested that we provide a way to
>perform a consistency check between the policy in memory and the policy
>on disk.  We could change the SELinux module to compute a checksum over
>the binary policy image when it is loaded and to export that checksum
>via a new selinuxfs node.  One complicating factor is that at
>present, /sbin/init and load_policy mutate the binary policy image in
>memory prior to loading it in order to customize the vendor-shipped
>policy with local boolean settings and user definitions, so the
>checksums would not match at present for the on-disk file and the
>in-memory image unless the verification tool applies the same transforms
>prior to computing the checksums.  Tresys has previously suggested
>shifting to a model where we regenerate the on-disk policy file for each
>change to any local setting, with the generated policy file to be loaded
>into the kernel stored separately from the policy file managed by rpm to
>avoid creating problems for updates, which would eliminate that problem
>altogether.
>
>  
>
I'd definitely prefer the latter. With policy modules, rpm should not 
even install a kernel binary. The policy rpm packages would contain the 
policy module for the respective package which would then be installed 
into the module store and consequently incorporated into the kernel 
policy. Unfortunatly, if LSPP has a strong requirement for which policy 
is running the module system becomes much less useful.

If something also needs to be done in the non-module case then we 
certainly need to take that into consideration when fixing the 
infrastructure to do modifications on disk, I am under the impression 
that semodule is going to be added into FC5 and some targets would be 
converted to modules, comments Dan?

Further, does LSPP disallow booleans? If not how will the checksum 
account for boolean state changes? (Or will it just ignore them, which 
sounds like a bad idea)

>Any comments on this request?  Any particular preference as to the
>particular checksum algorithm?  Does the algorithm need to be
>configurable?
>
>  
>
anything already included in cryptoapi would be free, right?

>A related idea would be to also extend the binary policy format to
>include a field for an arbitrary text string label that could be set
>when the policy is generated, and have the kernel save that string and
>export it via another new selinuxfs node.  This would allow an
>identifier string to be associated with the policy image, such as the
>policy package's name and version (e.g.
>selinux-policy-targeted-1.17.25-3), and extracted later by userspace to
>determine which particular policy the one in memory is supposed to
>match.  This wouldn't replace the need for the checksum, but would
>provide additional information that might be helpful to userspace.
>However, this change would require a change in binary policy format,
>unlike the first change.  
>
>  
>
I don't know how useful this is. Once the modules are in widespread use 
this name won't mean much, other than possibly the base policies name, 
which won't help much since any number of modules could be loaded on top 
of it. If information about the policy is needed it's probably better to 
ask the policy server or whathaveyou, since you'll have some fine 
grained query means.

>Any comments on this related idea?
>  
>  
>


--
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] Checking the loaded policy against a policy on disk

[Stephen Smalley]

On Fri, 2005-08-19 at 09:33 -0400, Joshua Brindle wrote:
> I'd definitely prefer the latter. With policy modules, rpm should not 
> even install a kernel binary. The policy rpm packages would contain the 
> policy module for the respective package which would then be installed 
> into the module store and consequently incorporated into the kernel 
> policy.

Plus other modifiers to policy beyond modules, such as local boolean
settings, user definitions, net contexts, etc.

I think we need to hash out how this is expected to work and convert
rawhide over to this model as soon as possible.  Might also have
implications for the installer.

>  Unfortunatly, if LSPP has a strong requirement for which policy 
> is running the module system becomes much less useful.

As long as we can verify the policy against some set of managed files, I
think we are ok.  It is simply a matter of being able to reproduce the
transforms that converted the original managed files into the final
generated kernel binary policy file for comparison, and then being able
to check the in-memory policy against that generated policy file.

> If something also needs to be done in the non-module case then we 
> certainly need to take that into consideration when fixing the 
> infrastructure to do modifications on disk, I am under the impression 
> that semodule is going to be added into FC5 and some targets would be 
> converted to modules, comments Dan?

semodule is in rawhide, but no one is using it yet AFAIK.  In any event,
even aside from modules, we need to convert over the current booleans
and users definitions to a model where each change goes through a
toolchain and yields a new generated policy file.

> Further, does LSPP disallow booleans? If not how will the checksum 
> account for boolean state changes? (Or will it just ignore them, which 
> sounds like a bad idea)

The checksum would just verify that the policy in memory matches some
policy file on disk.  As part of verifying consistency, I suppose you
would also query the current boolean settings via selinuxfs and compare
them against legal settings.  Hopefully the booleans won't affect
anything relevant to the MLS support.

> anything already included in cryptoapi would be free, right?

Yes, but the SELinux module still needs some way to select an algorithm,
and userspace needs to know which one it is using and have a
corresponding implementation.  selinuxfs interface for getting and
setting the algorithm, with some initial default?

> I don't know how useful this is. Once the modules are in widespread use 
> this name won't mean much, other than possibly the base policies name, 
> which won't help much since any number of modules could be loaded on top 
> of it. If information about the policy is needed it's probably better to 
> ask the policy server or whathaveyou, since you'll have some fine 
> grained query means.

True.  Note however that even with a policy server, there is going to be
an initial policy load by /sbin/init prior to the startup of the policy
server.  Right?  But init is just going to load the generated policy
file created earlier by the policy server, so the policy server should
be able to provide identifying information about the loaded policy.

-- 
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: [RFC] Checking the loaded policy against a policy on disk

[James Morris]

On Fri, 19 Aug 2005, Stephen Smalley wrote:

> Any comments on this request?

Can you point me to the LSPP requirement which states that we need to do 
this?

> Any particular preference as to the particular checksum algorithm?  

It's difficult to say, given ongoing research in the area, and not really 
knowing what the threat model is.

Given that the OS binaries are checksummed with SHA-1, it may not make any 
sense to try for anything stronger.

> Does the algorithm need to be configurable?

Well, you could just make it dynamic, write the name of the algorithm into 
the node and read back the checksum generated by that algorithm.


- James
-- 
James Morris
<jmorris@namei.org>

--
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] Checking the loaded policy against a policy on disk

[Frank Mayer]

> Can you point me to the LSPP requirement which states that we need to
> do this? 

I was wondering that myself. I don't recall any such requirement. As long as
the policy files are protected against unauthorized access and procedures
for start up/initialization are documented in appropriate manual, we
shouldn't be "required" to have a demonstrable association (thought
something like this might be otherwise useful). I believe the requirements
are for TCB/TSF protection, not periodic guarantee checks (except for
FPT_AMT which explicitly only applies to hardware). Frank



--
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] Checking the loaded policy against a policy on disk

[Stephen Smalley]

On Fri, 2005-08-19 at 14:42 -0400, Frank Mayer wrote:
> > Can you point me to the LSPP requirement which states that we need to
> > do this? 
> 
> I was wondering that myself. I don't recall any such requirement. As long as
> the policy files are protected against unauthorized access and procedures
> for start up/initialization are documented in appropriate manual, we
> shouldn't be "required" to have a demonstrable association (thought
> something like this might be otherwise useful). I believe the requirements
> are for TCB/TSF protection, not periodic guarantee checks (except for
> FPT_AMT which explicitly only applies to hardware). Frank

Ok, it seems that the request for this ability originated based on the
RBACPP rather than the LSPP, and in particular, the TSF Self Test
requirements, including the ability to verify the integrity of TSF data.
Whether or not that truly requires the ability to check the loaded
policy against a policy on disk is not clear, but in any event, it does
seem like a useful capability to provide.

-- 
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: [RFC] Checking the loaded policy against a policy on disk

[George Wilson]

On Fri, 2005-08-19 at 11:13 -0400, James Morris wrote:
> On Fri, 19 Aug 2005, Stephen Smalley wrote:
> 
> > Any comments on this request?
> 
> Can you point me to the LSPP requirement which states that we need to do 
> this?

It's the FPT_TST.1.2 RBACPP functional requirement.  So it's in addition
to LSPP proper.

-- 
George Wilson
IBM Linux Technology Center
<ltcgcw@us.ibm.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: [RFC] Checking the loaded policy against a policy on disk

[Thomas Bleher]

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

* Stephen Smalley <sds@tycho.nsa.gov> [2005-08-19 14:50]:
> A related idea would be to also extend the binary policy format to
> include a field for an arbitrary text string label that could be set
> when the policy is generated, and have the kernel save that string and
> export it via another new selinuxfs node.  This would allow an
> identifier string to be associated with the policy image, such as the
> policy package's name and version (e.g.
> selinux-policy-targeted-1.17.25-3), and extracted later by userspace to
> determine which particular policy the one in memory is supposed to
> match.

I'd really like to see that. When managing many machines it is really
nice to see which policy they have loaded. Just yesterday I hacked the
makefile to insert the current revision of the policy (we manage policy
with tla) as a dummy boolean so it can be inspected at runtime; a proper
textfield would be better IMHO.

Thomas

-- 
http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages
GPG-Fingerprint: BC4F BB16 30D6 F253 E3EA  D09E C562 2BAE B2F4 ABE7

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