Policy backward compatibility

Policy backward compatibility

[Stephen Smalley]

Hi,

I wanted to raise the issue of policy backward compatibility for general
discussion, as this has been coming up in private discussions recently
as new enhancements have been made to SELinux.  When Tresys implemented
the conditional policy extensions (policy version 16), they included
compatibility code in the kernel and checkpolicy so that the kernel
would continue to accept the older policy version and so that
checkpolicy could continue to generate the older policy version.  James
Morris generalized this compatibility support and extended it when he
implemented support for ipv6 node labeling (policy version 17), so that
the kernel and checkpolicy could handle versions 17-15.  

There are at least three other possible enhancements that I know of that
will require further changes to the binary policy format (split netlink
classes, automatic user identity transitions, conditional support for
RBAC rules), plus we need to purge the initial SID and access vector
definitions at some point of obsolete symbols so that they are
consistent with the current implementation, which will likely require
another policy version change as existing initial SID and permission
values will be affected.

The concern is that the backward compatibility code is becoming
increasingly cumbersome, and providing safe behavior for compatibility
isn't always straightforward.  This kind of compatibility code also
seems inconsistent with typical kernel practice.  James has proposed
dropping the backward compatibility support, and requiring that every
installed kernel have a suitable binary policy installed, possibly
encoding the associated kernel release (e.g. output of uname -r) in the
binary policy pathname (and possibly doing likewise for the checkpolicy
program?).  

Thoughts?

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: Policy backward compatibility

[Valdis.Kletnieks]

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

On Thu, 08 Apr 2004 09:21:35 EDT, Stephen Smalley said:

> seems inconsistent with typical kernel practice.  James has proposed
> dropping the backward compatibility support, and requiring that every
> installed kernel have a suitable binary policy installed, possibly
> encoding the associated kernel release (e.g. output of uname -r) in the
> binary policy pathname (and possibly doing likewise for the checkpolicy
> program?).  
> 
> Thoughts?

What would be the upgrade path when installing a new kernel?  Would there be an
option for the policy tools similar to the current mkinitrd, that allows you to
specify the kernel version to use (so you can build an initrd for the kernel
you're about to try to boot)?  The other option is having to boot into some
sort of single-user mode and then do the make reload/relabel before continuing
to multiuser.

What would the scheme be if you had to for some reason boot an older kernel
(for instance, having to drop back to 2.6.5-mm1 because -mm2 is b0rked for
something)?


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

Re: Policy backward compatibility

[Stephen Smalley]

On Thu, 2004-04-08 at 13:04, Valdis.Kletnieks@vt.edu wrote:
> What would be the upgrade path when installing a new kernel?  Would there be an
> option for the policy tools similar to the current mkinitrd, that allows you to
> specify the kernel version to use (so you can build an initrd for the kernel
> you're about to try to boot)?

Yes, I think so.  Might be a front-end wrapper for checkpolicy that
calls the right checkpolicy-{kernelrelease} binary to generate the
policy for that kernel release.

> What would the scheme be if you had to for some reason boot an older kernel
> (for instance, having to drop back to 2.6.5-mm1 because -mm2 is b0rked for
> something)?

If you include the kernel release in the policy pathname (e.g.
/etc/security/selinux/`uname -r`/policy), as with kernel modules
(/lib/modules/`uname -r`), then the old policy should still be there and
should be used by the older kernel if you reboot it.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: Policy backward compatibility

[Valdis.Kletnieks]

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

On Thu, 08 Apr 2004 13:09:32 EDT, Stephen Smalley said:

> Yes, I think so.  Might be a front-end wrapper for checkpolicy that
> calls the right checkpolicy-{kernelrelease} binary to generate the
> policy for that kernel release.

OK.. I can live with that, long as the tool can handle a kernel releasename
like 2.6.8-mm3-mobytweaks ;)

> If you include the kernel release in the policy pathname (e.g.
> /etc/security/selinux/`uname -r`/policy), as with kernel modules
> (/lib/modules/`uname -r`), then the old policy should still be there and
> should be used by the older kernel if you reboot it.

That's workable too - and we probably don't need any modversions-style tweaks
to make sure that the policy and kernel aren't affected by a mismatch (I figure
if you live so far on the edge that anything more granular than 2.6.N-mm?
matters, you're on your own. :)

We just need to make sure that a released kernel doesn't create incompatible
policies based on Kconfig changes...


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

Re: Policy backward compatibility

[Russell Coker]

On Thu, 8 Apr 2004 23:21, Stephen Smalley <sds@epoch.ncsc.mil> wrote:
> dropping the backward compatibility support, and requiring that every
> installed kernel have a suitable binary policy installed, possibly
> encoding the associated kernel release (e.g. output of uname -r) in the
> binary policy pathname (and possibly doing likewise for the checkpolicy
> program?).

I recall that James originally suggested encoding policy version in the value 
that is used for uname -r not the other way around.  Apart from the issue of 
changing the version numbering scheme used for kernels this should be OK.

Having multiple checkpolicy programs will probably be painful.  We want all 
the checkpolicy programs to understand the newest syntax (unless we have a 
policy.conf for each policy version).  This means that the old checkpolicy 
will need to be updated any time there is a syntax change.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: Policy backward compatibility

[Stephen Smalley]

On Mon, 2004-04-12 at 04:34, Russell Coker wrote:
> I recall that James originally suggested encoding policy version in the value 
> that is used for uname -r not the other way around.  Apart from the issue of 
> changing the version numbering scheme used for kernels this should be OK.

I don't think this is what James suggested, but he can clarify.  It
makes more sense to me to encode the kernel release in the policy
pathname, not the policy version in the kernel release.  The analogy is
kernel modules and /lib/modules/`uname -r`.

> Having multiple checkpolicy programs will probably be painful.  We want all 
> the checkpolicy programs to understand the newest syntax (unless we have a 
> policy.conf for each policy version).  This means that the old checkpolicy 
> will need to be updated any time there is a syntax change.

I don't think so.  Think of it as similar to the modutils and supporting
both the old and new module interfaces.  You have a single frontend
checkpolicy script that invokes the right backend checkpolicy-`uname -r`
binary that generates the corresponding policy version.  You never have
to update the older checkpolicy binaries; you just add new checkpolicy
binaries for the newer kernels.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: Policy backward compatibility

[Stephen Smalley]

On Tue, 2004-04-13 at 09:14, Stephen Smalley wrote:
> On Mon, 2004-04-12 at 04:34, Russell Coker wrote:
> > Having multiple checkpolicy programs will probably be painful.  We want all 
> > the checkpolicy programs to understand the newest syntax (unless we have a 
> > policy.conf for each policy version).  This means that the old checkpolicy 
> > will need to be updated any time there is a syntax change.
> 
> I don't think so.  Think of it as similar to the modutils and supporting
> both the old and new module interfaces.  You have a single frontend
> checkpolicy script that invokes the right backend checkpolicy-`uname -r`
> binary that generates the corresponding policy version.  You never have
> to update the older checkpolicy binaries; you just add new checkpolicy
> binaries for the newer kernels.

And, yes, this will require separate policy.conf files for the different
versions, but that is going to be necessary anyway for significant
changes to the policy.  Even for the netlink class partitioning, you
don't want to compile a newer policy.conf that has the fine-grained
netlink classes with an older checkpolicy, as the best it could do would
be to map them all to the old netlink class, possibly opening up
unintended access.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: Policy backward compatibility

[Stephen Smalley]

On Tue, 2004-04-13 at 09:22, Stephen Smalley wrote:
> And, yes, this will require separate policy.conf files for the different
> versions, but that is going to be necessary anyway for significant
> changes to the policy.  Even for the netlink class partitioning, you
> don't want to compile a newer policy.conf that has the fine-grained
> netlink classes with an older checkpolicy, as the best it could do would
> be to map them all to the old netlink class, possibly opening up
> unintended access.

And likewise for any significant use of booleans, since the
compatibility code just discards the conditional statements entirely
rather than generating statements based on the initial boolean value...

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: Policy backward compatibility

[Karl MacMillan]

> 
> On Tue, 2004-04-13 at 09:22, Stephen Smalley wrote:
> > And, yes, this will require separate policy.conf files for the different
> > versions, but that is going to be necessary anyway for significant
> > changes to the policy.  Even for the netlink class partitioning, you
> > don't want to compile a newer policy.conf that has the fine-grained
> > netlink classes with an older checkpolicy, as the best it could do would
> > be to map them all to the old netlink class, possibly opening up
> > unintended access.
> 
> And likewise for any significant use of booleans, since the
> compatibility code just discards the conditional statements entirely
> rather than generating statements based on the initial boolean value...
> 

It is clear that generating old format binary policies from policy.conf
files with significant use of new features is not going to work well. This
doesn't mean, however, that checkpolicy shouldn't have the ability to
generate an old binary policy format from a policy.conf that doesn't use
those features.

I think that keeping multiple versions of checkpolicy around (that have to
be compiled from separate source trees) is going to be a huge problem. The
modutils example is not exactly analogous. In that case it was clear that
there were only going to be 2 versions of the utilities. In the checkpolicy
case there are going to be at least 3 and likely more. I definitely
understand that maintaining backwards compatibility code can be problematic
- Apol supports policies as old as pre-version 11, for example. I believe
this will be less of a problem than the multiple versions of checkpolicy,
though.

I suggest that binary compatibility can be dropped from the kernel. It was
useful for the conditional policy transition, but I think it can be dropped
without too much user pain. I also suggest that the backwards compatibility
should be retained in the same way as it is now for checkpolicy. That means
that by default checkpolicy only generates the latest version and if the
user requests, it will generate a specific older version binary (through the
-c VERSION flag). If the policy.conf file they are compiling uses newer
features it can take an appropriate action (like dropping the conditional
policy) or refuse to generate the policy entirely.

Karl MacMillan
Tresys Technology
http://www.tresys.com
(410)290-1411 ext 134

> --
> Stephen Smalley <sds@epoch.ncsc.mil>
> 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.


--
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: Policy backward compatibility

[Russell Coker]

On Tue, 13 Apr 2004 23:33, Stephen Smalley <sds@epoch.ncsc.mil> wrote:
> On Tue, 2004-04-13 at 09:22, Stephen Smalley wrote:
> > And, yes, this will require separate policy.conf files for the different
> > versions, but that is going to be necessary anyway for significant
> > changes to the policy.  Even for the netlink class partitioning, you
> > don't want to compile a newer policy.conf that has the fine-grained
> > netlink classes with an older checkpolicy, as the best it could do would
> > be to map them all to the old netlink class, possibly opening up
> > unintended access.
>
> And likewise for any significant use of booleans, since the
> compatibility code just discards the conditional statements entirely
> rather than generating statements based on the initial boolean value...

Yes, this is why I haven't written any policy to make significant use of 
booleans.  I haven't yet upgraded all machines I use to the latest policy 
(and still have some machines that can't run 2.6).

Maybe we need a policy.conf.15 and policy.conf.16 etc?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: Policy backward compatibility

[John D. Ramsdell]

Stephen Smalley <sds@epoch.ncsc.mil> writes:

> And likewise for any significant use of booleans, since the
> compatibility code just discards the conditional statements entirely
> rather than generating statements based on the initial boolean value...

The poldecond program, which is part of the most recent slat
distribution, was intended to help with this problem.  It removes
conditionals by generating statements based on the initial boolean
values.  Thus, tools that have not been updated to accept boolean
conditions, such as slat, can be used with a policy file that contains
booleans as long as the file has been preprocessed using poldecond.

The poldecond program is part of the slat sources stored in the
selinux project CVS repository on SourceForge in the nsa module.  We
intend to make a tarball and an RPM of this version of the code
available on a MITRE web server soon, although, our internal approval
process seems to be greatly slowing us down.  The slat change log says
that the poldecond program was checked near the end of February!

John

--
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: Policy backward compatibility

[James Morris]

On Tue, 13 Apr 2004, Stephen Smalley wrote:

> On Mon, 2004-04-12 at 04:34, Russell Coker wrote:
> > I recall that James originally suggested encoding policy version in the value 
> > that is used for uname -r not the other way around.  Apart from the issue of 
> > changing the version numbering scheme used for kernels this should be OK.
> 
> I don't think this is what James suggested, but he can clarify.  It
> makes more sense to me to encode the kernel release in the policy
> pathname, not the policy version in the kernel release.  The analogy is
> kernel modules and /lib/modules/`uname -r`.

Yes, this is what I meant.


- James
-- 
James Morris
<jmorris@redhat.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.