[PATCH 0/2] new and improved range_transition statements

[PATCH 0/2] new and improved range_transition statements

[Darrel Goeddel]

This following patches allow for specification of security classes for
range_transition statements in the policy.  This is intended to address
a solution for RedHat Bugzilla #185436.

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185436

While working on this format change to allow class specification, it was
noted that the current range_transition handling in the policy toolchain was
not ideal.  It expanded things at compile time and there was no way to get
these statements into policy modules.  So, in addition to changing the kernel
policy format and base policy format in a trivial manner to support the
desired functionality, I also tried to make the base and module formats more
robust when handling range_transition rules.  Hopefully, this format will
allow for range_transition statements in modules with additional work for
libsepol in the (near?) future.  I will defer the toolchain gurus on the
completeness of my approach ;)  This patch set has been tested in the
following configurations:

old kernel / all old policy - sure glad that worked
old kernel / old format modules generating a new format kernel policy that
  is automatically downgraded at load time
old kernel / new format modules generating a new format kernel policy that
  is automatically downgraded at load time
new kernel / old format modules generating a new format kernel policy
old kernel / new format modules generating a new format kernel policy

The old style statements (without class specification) are correctly
interpreted as applying to the "process" class.  Old and new style statements
can be used together happily.  Duplicate and conflicting rules are properly
handled when expanding the rules with dups being dropped and conflicts
resulting in an error.  Also, a kernel policy that contains range_transitions
for classes other than "process" will have those transition rules dropped when
it is downgraded, but all "process" rules will remain as the old format supports
them.

The kernel change is fairly simple.  Sure would be nice to get that into 2.6.18
since it is for a bug fix...

The toolchain changes are a bit more complex, although it sure seems a lot easier
than it did when I started looking at the code.  I'd appreciate some scrutiny of
this, especially in the area of future support for range_transition statements in
policy modules.  I feel that will be very necessary and I hope to ease that path
with the format change.

-- 

Darrel

--
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: [PATCH 0/2] new and improved range_transition statements

[Karl MacMillan]

On Fri, 2006-07-28 at 10:11 -0500, Darrel Goeddel wrote:
> This following patches allow for specification of security classes for
> range_transition statements in the policy.  This is intended to address
> a solution for RedHat Bugzilla #185436.
> 
> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185436
> 
> While working on this format change to allow class specification, it was
> noted that the current range_transition handling in the policy toolchain was
> not ideal.  It expanded things at compile time and there was no way to get
> these statements into policy modules.  So, in addition to changing the kernel
> policy format and base policy format in a trivial manner to support the
> desired functionality, I also tried to make the base and module formats more
> robust when handling range_transition rules.

Thanks for taking the time to make this more complete.

>   Hopefully, this format will
> allow for range_transition statements in modules with additional work for
> libsepol in the (near?) future.  I will defer the toolchain gurus on the
> completeness of my approach ;)  This patch set has been tested in the
> following configurations:
> 
> old kernel / all old policy - sure glad that worked
> old kernel / old format modules generating a new format kernel policy that
>   is automatically downgraded at load time
> old kernel / new format modules generating a new format kernel policy that
>   is automatically downgraded at load time
> new kernel / old format modules generating a new format kernel policy
> old kernel / new format modules generating a new format kernel policy
> 

My biggest question is how to handle the format change. There are some
other bug fixes awaiting a module format change (not certain about
kernel format change) and it would be nice to include those in this
format bump. Unfortunately there are not patches for those fixes at the
moment.

Could we branch the code for a month or so for the other changes can be
introduced or is the fix more critical? Do you think that this must go
into RHEL 5 / FC6? Is it possible for the kernel changes to make it in
time for 2.6.18 and if they don't will this be included in RHEL 5 / FC6?

<snip>

> The kernel change is fairly simple.  Sure would be nice to get that into 2.6.18
> since it is for a bug fix...
> 

This makes me think that you time is critical.

> The toolchain changes are a bit more complex, although it sure seems a lot easier
> than it did when I started looking at the code.  I'd appreciate some scrutiny of
> this, especially in the area of future support for range_transition statements in
> policy modules.  I feel that will be very necessary and I hope to ease that path
> with the format change.
> 

I'll try to do a review of this today. Josh - could you take a look as
well?

Karl

--
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: [PATCH 0/2] new and improved range_transition statements

[Stephen Smalley]

On Mon, 2006-07-31 at 09:07 -0400, Karl MacMillan wrote:
> My biggest question is how to handle the format change. There are some
> other bug fixes awaiting a module format change (not certain about
> kernel format change) and it would be nice to include those in this
> format bump. Unfortunately there are not patches for those fixes at the
> moment.
> 
> Could we branch the code for a month or so for the other changes can be
> introduced or is the fix more critical? Do you think that this must go
> into RHEL 5 / FC6? Is it possible for the kernel changes to make it in
> time for 2.6.18 and if they don't will this be included in RHEL 5 / FC6?

It doesn't necessarily have to be in 2.6.18 to make RHEL5; consider the
MLSXFRM and NetLabel patches, which are being queued for 2.6.19 but IIUC
will be back ported and included in RHEL5.

-- 
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: [PATCH 0/2] new and improved range_transition statements

[Karl MacMillan]

On Mon, 2006-07-31 at 09:56 -0400, Stephen Smalley wrote:
> On Mon, 2006-07-31 at 09:07 -0400, Karl MacMillan wrote:
> > My biggest question is how to handle the format change. There are some
> > other bug fixes awaiting a module format change (not certain about
> > kernel format change) and it would be nice to include those in this
> > format bump. Unfortunately there are not patches for those fixes at the
> > moment.
> > 
> > Could we branch the code for a month or so for the other changes can be
> > introduced or is the fix more critical? Do you think that this must go
> > into RHEL 5 / FC6? Is it possible for the kernel changes to make it in
> > time for 2.6.18 and if they don't will this be included in RHEL 5 / FC6?
> 
> It doesn't necessarily have to be in 2.6.18 to make RHEL5; consider the
> MLSXFRM and NetLabel patches, which are being queued for 2.6.19 but IIUC
> will be back ported and included in RHEL5.
> 

I know. I'm trying to get a feel for whether this change is critical or
the workarounds mentioned in the bug are sufficient for now. If it is
not critical I'd rather batch some other format changes. Otherwise the
change should go in and potentially be backported if it misses 2.6.18.

Karl

--
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: [PATCH 0/2] new and improved range_transition statements

[Joshua Brindle]

> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
> 
> On Mon, 2006-07-31 at 09:56 -0400, Stephen Smalley wrote:
> > On Mon, 2006-07-31 at 09:07 -0400, Karl MacMillan wrote:
> > > My biggest question is how to handle the format change. There are 
> > > some other bug fixes awaiting a module format change (not certain 
> > > about kernel format change) and it would be nice to 
> include those in 
> > > this format bump. Unfortunately there are not patches for those 
> > > fixes at the moment.
> > > 
> > > Could we branch the code for a month or so for the other 
> changes can 
> > > be introduced or is the fix more critical? Do you think that this 
> > > must go into RHEL 5 / FC6? Is it possible for the kernel 
> changes to 
> > > make it in time for 2.6.18 and if they don't will this be 
> included in RHEL 5 / FC6?
> > 
> > It doesn't necessarily have to be in 2.6.18 to make RHEL5; consider 
> > the MLSXFRM and NetLabel patches, which are being queued for 2.6.19 
> > but IIUC will be back ported and included in RHEL5.
> > 
> 
> I know. I'm trying to get a feel for whether this change is 
> critical or the workarounds mentioned in the bug are 
> sufficient for now. If it is not critical I'd rather batch 
> some other format changes. Otherwise the change should go in 
> and potentially be backported if it misses 2.6.18.

I don't think any kernel format changes are planned so the kernel patch
can go forward and we can branch off the userland for the changes you
are talking about (which ones are those btw?).


--
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: [PATCH 0/2] new and improved range_transition statements

[Karl MacMillan]

On Mon, 2006-07-31 at 10:01 -0400, Joshua Brindle wrote:
> > From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
> > 
> > On Mon, 2006-07-31 at 09:56 -0400, Stephen Smalley wrote:
> > > On Mon, 2006-07-31 at 09:07 -0400, Karl MacMillan wrote:
> > > > My biggest question is how to handle the format change. There are 
> > > > some other bug fixes awaiting a module format change (not certain 
> > > > about kernel format change) and it would be nice to 
> > include those in 
> > > > this format bump. Unfortunately there are not patches for those 
> > > > fixes at the moment.
> > > > 
> > > > Could we branch the code for a month or so for the other 
> > changes can 
> > > > be introduced or is the fix more critical? Do you think that this 
> > > > must go into RHEL 5 / FC6? Is it possible for the kernel 
> > changes to 
> > > > make it in time for 2.6.18 and if they don't will this be 
> > included in RHEL 5 / FC6?
> > > 
> > > It doesn't necessarily have to be in 2.6.18 to make RHEL5; consider 
> > > the MLSXFRM and NetLabel patches, which are being queued for 2.6.19 
> > > but IIUC will be back ported and included in RHEL5.
> > > 
> > 
> > I know. I'm trying to get a feel for whether this change is 
> > critical or the workarounds mentioned in the bug are 
> > sufficient for now. If it is not critical I'd rather batch 
> > some other format changes. Otherwise the change should go in 
> > and potentially be backported if it misses 2.6.18.
> 
> I don't think any kernel format changes are planned so the kernel patch
> can go forward and we can branch off the userland for the changes you
> are talking about 

The kernel change isn't useful without the format change though. The
current approach (which seems right) requires both the kernel and module
format change, correct?

> (which ones are those btw?).
> 

The ones that I can remember are:

- scoping fixes to allow permissions to be scoped. Ideally this would
add enough scoping information to allow the relaxation of some of the
ordering constraints.

- fixing avrule_block to correctly represent what is possible (removing
arbitrary branches)

- better handling of type->flavor (if needed)

- whatever is needed to support incremental linking

Do you have anything else?

Karl

--
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: [PATCH 0/2] new and improved range_transition statements

[Joshua Brindle]

> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
> 
> On Mon, 2006-07-31 at 10:01 -0400, Joshua Brindle wrote:
> > > From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com]
<snip?
> > 
> > I don't think any kernel format changes are planned so the kernel 
> > patch can go forward and we can branch off the userland for the 
> > changes you are talking about
> 
> The kernel change isn't useful without the format change 
> though. The current approach (which seems right) requires 
> both the kernel and module format change, correct?
> 

Eh? That doesn't mean they have to be merged at the exact same time,
kernel changes need to go in sooner to get backported to RHEL5 whereas
we have some time with userland changes.

> > (which ones are those btw?).
> > 
> 
> The ones that I can remember are:
> 
> - scoping fixes to allow permissions to be scoped. Ideally 
> this would add enough scoping information to allow the 
> relaxation of some of the ordering constraints.
> 

Right, I don't know who/when this will get done

> - fixing avrule_block to correctly represent what is possible 
> (removing arbitrary branches)
> 

That's a style change more than anything, no functional difference, very
low priority

> - better handling of type->flavor (if needed)
> 

??

> - whatever is needed to support incremental linking
> 

I'd like to get this in but that seems unlikely, it would be very nice
to speed up linking and memory usage (which is currently very high). I
don't think this will necessitate a format change but can't be sure.

> Do you have anything else?
>

That's all I know of, I'm not sure if any of these are going to go in
anytime soon unless other people have time/ability. The most important
thing is obviously permission scoping.


--
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: [PATCH 0/2] new and improved range_transition statements

[Karl MacMillan]

On Mon, 2006-07-31 at 10:23 -0400, Joshua Brindle wrote:
> > From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
> > 

<snip>

> > - scoping fixes to allow permissions to be scoped. Ideally 
> > this would add enough scoping information to allow the 
> > relaxation of some of the ordering constraints.
> > 
> 
> Right, I don't know who/when this will get done
> 

I've made some good progress cleaning up the scoping storage and
management on top of the symtab_datum_t patches. I'll likely be able to
send a version without a format change soon that will have all of the
needed infrastructure for when the format change happens.

> > - fixing avrule_block to correctly represent what is possible 
> > (removing arbitrary branches)
> > 
> 
> That's a style change more than anything, no functional difference, very
> low priority
> 

Yep

> > - better handling of type->flavor (if needed)
> > 
> 
> ??
> 

I remembered some discussion about how this would be done when it was
added - doesn't look like anything needs to change so never mind.

> > - whatever is needed to support incremental linking
> > 
> 
> I'd like to get this in but that seems unlikely, it would be very nice
> to speed up linking and memory usage (which is currently very high). I
> don't think this will necessitate a format change but can't be sure.
> 

Right - I'm betting that there will be something needed.

> > Do you have anything else?
> >
> 
> That's all I know of, I'm not sure if any of these are going to go in
> anytime soon unless other people have time/ability. The most important
> thing is obviously permission scoping.
> 

Like I said I'm working on the scoping, but it is a low priority task
for me.

Karl

--
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: [PATCH 0/2] new and improved range_transition statements

[Stephen Smalley]

On Mon, 2006-07-31 at 09:58 -0400, Karl MacMillan wrote:
> On Mon, 2006-07-31 at 09:56 -0400, Stephen Smalley wrote:
> > On Mon, 2006-07-31 at 09:07 -0400, Karl MacMillan wrote:
> > > My biggest question is how to handle the format change. There are some
> > > other bug fixes awaiting a module format change (not certain about
> > > kernel format change) and it would be nice to include those in this
> > > format bump. Unfortunately there are not patches for those fixes at the
> > > moment.
> > > 
> > > Could we branch the code for a month or so for the other changes can be
> > > introduced or is the fix more critical? Do you think that this must go
> > > into RHEL 5 / FC6? Is it possible for the kernel changes to make it in
> > > time for 2.6.18 and if they don't will this be included in RHEL 5 / FC6?
> > 
> > It doesn't necessarily have to be in 2.6.18 to make RHEL5; consider the
> > MLSXFRM and NetLabel patches, which are being queued for 2.6.19 but IIUC
> > will be back ported and included in RHEL5.
> > 
> 
> I know. I'm trying to get a feel for whether this change is critical or
> the workarounds mentioned in the bug are sufficient for now. If it is
> not critical I'd rather batch some other format changes. Otherwise the
> change should go in and potentially be backported if it misses 2.6.18.

I'd view this change as more important to RHEL5 than any of the other
proposed format changes, so I'd like to see both the kernel change and
the userland change make it into RHEL5.

-- 
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: [PATCH 0/2] new and improved range_transition statements

[Karl MacMillan]

On Mon, 2006-07-31 at 10:30 -0400, Stephen Smalley wrote:
> On Mon, 2006-07-31 at 09:58 -0400, Karl MacMillan wrote:
> > On Mon, 2006-07-31 at 09:56 -0400, Stephen Smalley wrote:
> > > On Mon, 2006-07-31 at 09:07 -0400, Karl MacMillan wrote:
> > > > My biggest question is how to handle the format change. There are some
> > > > other bug fixes awaiting a module format change (not certain about
> > > > kernel format change) and it would be nice to include those in this
> > > > format bump. Unfortunately there are not patches for those fixes at the
> > > > moment.
> > > > 
> > > > Could we branch the code for a month or so for the other changes can be
> > > > introduced or is the fix more critical? Do you think that this must go
> > > > into RHEL 5 / FC6? Is it possible for the kernel changes to make it in
> > > > time for 2.6.18 and if they don't will this be included in RHEL 5 / FC6?
> > > 
> > > It doesn't necessarily have to be in 2.6.18 to make RHEL5; consider the
> > > MLSXFRM and NetLabel patches, which are being queued for 2.6.19 but IIUC
> > > will be back ported and included in RHEL5.
> > > 
> > 
> > I know. I'm trying to get a feel for whether this change is critical or
> > the workarounds mentioned in the bug are sufficient for now. If it is
> > not critical I'd rather batch some other format changes. Otherwise the
> > change should go in and potentially be backported if it misses 2.6.18.
> 
> I'd view this change as more important to RHEL5 than any of the other
> proposed format changes, so I'd like to see both the kernel change and
> the userland change make it into RHEL5.
> 

Ok - that is fine with me. I'll work on the other format changes
separately.

Karl

--
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: [PATCH 0/2] new and improved range_transition statements

[Darrel Goeddel]

Stephen Smalley wrote:
> On Mon, 2006-07-31 at 09:58 -0400, Karl MacMillan wrote:
> 
>>On Mon, 2006-07-31 at 09:56 -0400, Stephen Smalley wrote:
>>
>>>On Mon, 2006-07-31 at 09:07 -0400, Karl MacMillan wrote:
>>>
>>>>My biggest question is how to handle the format change. There are some
>>>>other bug fixes awaiting a module format change (not certain about
>>>>kernel format change) and it would be nice to include those in this
>>>>format bump. Unfortunately there are not patches for those fixes at the
>>>>moment.
>>>>
>>>>Could we branch the code for a month or so for the other changes can be
>>>>introduced or is the fix more critical? Do you think that this must go
>>>>into RHEL 5 / FC6? Is it possible for the kernel changes to make it in
>>>>time for 2.6.18 and if they don't will this be included in RHEL 5 / FC6?
>>>
>>>It doesn't necessarily have to be in 2.6.18 to make RHEL5; consider the
>>>MLSXFRM and NetLabel patches, which are being queued for 2.6.19 but IIUC
>>>will be back ported and included in RHEL5.
>>>
>>
>>I know. I'm trying to get a feel for whether this change is critical or
>>the workarounds mentioned in the bug are sufficient for now. If it is
>>not critical I'd rather batch some other format changes. Otherwise the
>>change should go in and potentially be backported if it misses 2.6.18.
> 
> 
> I'd view this change as more important to RHEL5 than any of the other
> proposed format changes, so I'd like to see both the kernel change and
> the userland change make it into RHEL5.

As an aside to the primary bugfix that this patch addresses...

As I mentioned, I was striving to make to new formats be ready to handle
range_transitions in policy modules.  I think that this will be a necessity
for MLS application developers that with to use RHEL5.  The current alternative
seems to be (assuming the need to use new range_transitions statements, which
we currently do...) replacing the RHEL policy package altogether with
something that includes source to build either a new base policy or a
monolithic policy that provides the necessary transitions.

I was hoping that by solidifying the formats now (and getting those accepted
into RHEL5 early), we could continue to work on on code fixes/enhancements
to allow the statements in policy modules and hope to get that work into
RHEL since it would not require further format changes.  I am hoping that the
format can handle that now...  There are still thing that will need to be
addressed (such as how to handle MLS requirements for modules) to achieve
the goal.  I'm willing to lend a hand on the further work, but I'm sure I
will need some serious hand-holding when I dig into the link phase ;)  Thanks
again to Joshua for the help he has provided me to get the patches to where
they are right now.

-- 

Darrel

--
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: [PATCH 0/2] new and improved range_transition statements

[Valdis.Kletnieks]

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

On Mon, 31 Jul 2006 09:56:24 EDT, Stephen Smalley said:
> On Mon, 2006-07-31 at 09:07 -0400, Karl MacMillan wrote:
> > My biggest question is how to handle the format change. There are some
> > other bug fixes awaiting a module format change (not certain about
> > kernel format change) and it would be nice to include those in this
> > format bump. Unfortunately there are not patches for those fixes at the
> > moment.
> > 
> > Could we branch the code for a month or so for the other changes can be
> > introduced or is the fix more critical? Do you think that this must go
> > into RHEL 5 / FC6? Is it possible for the kernel changes to make it in
> > time for 2.6.18 and if they don't will this be included in RHEL 5 / FC6?
> 
> It doesn't necessarily have to be in 2.6.18 to make RHEL5; consider the
> MLSXFRM and NetLabel patches, which are being queued for 2.6.19 but IIUC
> will be back ported and included in RHEL5.

2.6.18-rc3 just came out - I suspect that a patch that modifies an
external module format won't be looked upon kindly for inclusion in .18.
Looks like "submit for the .19 merge window and backport for RHEL5" will
be the way to go. (Looks like FC6 will be in the same category, AFAICT).

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

Re: [PATCH 0/2] new and improved range_transition statements

[Stephen Smalley]

On Mon, 2006-07-31 at 10:28 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Mon, 31 Jul 2006 09:56:24 EDT, Stephen Smalley said:
> > On Mon, 2006-07-31 at 09:07 -0400, Karl MacMillan wrote:
> > > My biggest question is how to handle the format change. There are some
> > > other bug fixes awaiting a module format change (not certain about
> > > kernel format change) and it would be nice to include those in this
> > > format bump. Unfortunately there are not patches for those fixes at the
> > > moment.
> > > 
> > > Could we branch the code for a month or so for the other changes can be
> > > introduced or is the fix more critical? Do you think that this must go
> > > into RHEL 5 / FC6? Is it possible for the kernel changes to make it in
> > > time for 2.6.18 and if they don't will this be included in RHEL 5 / FC6?
> > 
> > It doesn't necessarily have to be in 2.6.18 to make RHEL5; consider the
> > MLSXFRM and NetLabel patches, which are being queued for 2.6.19 but IIUC
> > will be back ported and included in RHEL5.
> 
> 2.6.18-rc3 just came out - I suspect that a patch that modifies an
> external module format won't be looked upon kindly for inclusion in .18.
> Looks like "submit for the .19 merge window and backport for RHEL5" will
> be the way to go. (Looks like FC6 will be in the same category, AFAICT).

I agree that it is too late for 2.6.18, but just to clarify - the kernel
patch preserves backward compatibility for older binary policy
formats.  

As far as compatibility is concerned, FC4 will need some kind of
userland update when it updates to a kernel with the new policy format;
otherwise, init will give up when it cannot find policy.21 or policy.20
(older sysvinit selinux patch only tried n and (n-1)), and the policy in
FC4 was version 19.

-- 
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: [PATCH 0/2] new and improved range_transition statements

[Valdis.Kletnieks]

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

On Mon, 31 Jul 2006 10:43:15 EDT, Stephen Smalley said:

> I agree that it is too late for 2.6.18, but just to clarify - the kernel
> patch preserves backward compatibility for older binary policy
> formats.  
> 
> As far as compatibility is concerned, FC4 will need some kind of
> userland update when it updates to a kernel with the new policy format;
> otherwise, init will give up when it cannot find policy.21 or policy.20
> (older sysvinit selinux patch only tried n and (n-1)), and the policy in
> FC4 was version 19.

Given that Andrew Morton is currently having a cow over the fact that
2.6.18-rc3 includes a change that breaks the udev that shipped with FC3,
we might want to make sure we have all our ducks lined up....

(To be fair, the udev change is one that breaks any udev more than 10 months
or so old...)

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

Re: [PATCH 0/2] new and improved range_transition statements

[Stephen Smalley]

On Mon, 2006-07-31 at 11:10 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Mon, 31 Jul 2006 10:43:15 EDT, Stephen Smalley said:
> 
> > I agree that it is too late for 2.6.18, but just to clarify - the kernel
> > patch preserves backward compatibility for older binary policy
> > formats.  
> > 
> > As far as compatibility is concerned, FC4 will need some kind of
> > userland update when it updates to a kernel with the new policy format;
> > otherwise, init will give up when it cannot find policy.21 or policy.20
> > (older sysvinit selinux patch only tried n and (n-1)), and the policy in
> > FC4 was version 19.
> 
> Given that Andrew Morton is currently having a cow over the fact that
> 2.6.18-rc3 includes a change that breaks the udev that shipped with FC3,
> we might want to make sure we have all our ducks lined up....
> 
> (To be fair, the udev change is one that breaks any udev more than 10 months
> or so old...)

After a bit of discussion (see bug 201242 in the redhat bugzilla) about
updating FC4 userland, it seems that we should try to address this
compatibility concern for legacy userland in the kernel.  We could first
upstream the patch below, then re-base the range_transition kernel patch
against it.  This patch makes the maximum policy version a kernel config
option so that it can be adjusted down to accommodate legacy userland,
with instructions and examples in the help text of the config option on
how to determine what value to use.  The range_transition kernel patch
would then adjust the "range" and "default" attributes of this new
config option to reflect the new version support, while users could
still build kernels to an older version.  Thoughts?

diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig
index 814ddc4..eb7c142 100644
--- a/security/selinux/Kconfig
+++ b/security/selinux/Kconfig
@@ -124,3 +124,24 @@ config SECURITY_SELINUX_ENABLE_SECMARK_D
 
 	  If you are unsure what do do here, select N.
 
+config SECURITY_SELINUX_POLICYDB_VERSION_MAX
+	int "NSA SELinux maximum supported policy format version"
+	depends on SECURITY_SELINUX
+	range 15 20
+	default 20
+	help
+	  This option sets the maximum policy format version supported
+	  by SELinux.  This value is reported to userspace via
+	  /selinux/policyvers and used at policy load time.  It can
+	  be adjusted downward to support legacy userland that does not
+	  properly handle multiple policy version increments.
+
+	  If you are unsure how to answer this question, look for the
+	  policy format version supported by your policy toolchain, by
+	  running 'checkpolicy -V'. Or look at what policy you have
+	  installed under /etc/selinux/$SELINUXTYPE/policy, where
+	  SELINUXTYPE is defined in your /etc/selinux/config.
+
+	  Examples:  For FC3, use 18.  For FC4, use 19.  For FC5 and later,
+	  userland correctly handles this situation, so there is no need to
+	  adjust this value down. 
diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
index 063af47..be303af 100644
--- a/security/selinux/include/security.h
+++ b/security/selinux/include/security.h
@@ -27,7 +27,7 @@ #define POLICYDB_VERSION_AVTAB		20
 
 /* Range of policy versions we understand*/
 #define POLICYDB_VERSION_MIN   POLICYDB_VERSION_BASE
-#define POLICYDB_VERSION_MAX   POLICYDB_VERSION_AVTAB
+#define POLICYDB_VERSION_MAX   CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX
 
 extern int selinux_enabled;
 extern int selinux_mls_enabled;


-- 
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: [PATCH 0/2] new and improved range_transition statements

[James Morris]

On Fri, 4 Aug 2006, Stephen Smalley wrote:

> would then adjust the "range" and "default" attributes of this new
> config option to reflect the new version support, while users could
> still build kernels to an older version.  Thoughts?

Makes sense to me.


-- 
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: [PATCH 0/2] new and improved range_transition statements

[Darrel Goeddel]

Stephen Smalley wrote:
> On Mon, 2006-07-31 at 11:10 -0400, Valdis.Kletnieks@vt.edu wrote:
> 
>>On Mon, 31 Jul 2006 10:43:15 EDT, Stephen Smalley said:
>>
>>
>>>I agree that it is too late for 2.6.18, but just to clarify - the kernel
>>>patch preserves backward compatibility for older binary policy
>>>formats.  
>>>
>>>As far as compatibility is concerned, FC4 will need some kind of
>>>userland update when it updates to a kernel with the new policy format;
>>>otherwise, init will give up when it cannot find policy.21 or policy.20
>>>(older sysvinit selinux patch only tried n and (n-1)), and the policy in
>>>FC4 was version 19.
>>
>>Given that Andrew Morton is currently having a cow over the fact that
>>2.6.18-rc3 includes a change that breaks the udev that shipped with FC3,
>>we might want to make sure we have all our ducks lined up....
>>
>>(To be fair, the udev change is one that breaks any udev more than 10 months
>>or so old...)
> 
> 
> After a bit of discussion (see bug 201242 in the redhat bugzilla) about
> updating FC4 userland, it seems that we should try to address this
> compatibility concern for legacy userland in the kernel.  We could first
> upstream the patch below, then re-base the range_transition kernel patch
> against it.  This patch makes the maximum policy version a kernel config
> option so that it can be adjusted down to accommodate legacy userland,
> with instructions and examples in the help text of the config option on
> how to determine what value to use.  The range_transition kernel patch
> would then adjust the "range" and "default" attributes of this new
> config option to reflect the new version support, while users could
> still build kernels to an older version.  Thoughts?

This patch will certainly provide a solution to the problem.  However, I wonder
if most people that would have had the problem in the first place (those with
old userspace components) will still run into the problem for their first kernel
build because they did not know alter the config for the situation.  So we'll
likely need to advertise this change accordingly ;).  At least it will be an
easier fix than updating the SELinux userland components and init.  I can rebase
the range_transition patch when this goes upstream (of course there is not much
to it...)

-- 

Darrel

--
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: [PATCH 0/2] new and improved range_transition statements

[Joshua Brindle]

 

> -----Original Message-----
> From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> Sent: Friday, August 04, 2006 9:20 AM
> To: Valdis.Kletnieks@vt.edu
> Cc: James Morris; Karl MacMillan; Darrel Goeddel; 'SELinux 
> List'; Eric Paris; Joshua Brindle
> Subject: Re: [PATCH 0/2] new and improved range_transition statements
> 
> On Mon, 2006-07-31 at 11:10 -0400, Valdis.Kletnieks@vt.edu wrote:
> > On Mon, 31 Jul 2006 10:43:15 EDT, Stephen Smalley said:
> > 
> > > I agree that it is too late for 2.6.18, but just to clarify - the 
> > > kernel patch preserves backward compatibility for older binary 
> > > policy formats.
> > > 
> > > As far as compatibility is concerned, FC4 will need some kind of 
> > > userland update when it updates to a kernel with the new policy 
> > > format; otherwise, init will give up when it cannot find 
> policy.21 
> > > or policy.20 (older sysvinit selinux patch only tried n 
> and (n-1)), 
> > > and the policy in
> > > FC4 was version 19.
> > 
> > Given that Andrew Morton is currently having a cow over the 
> fact that
> > 2.6.18-rc3 includes a change that breaks the udev that shipped with 
> > FC3, we might want to make sure we have all our ducks lined up....
> > 
> > (To be fair, the udev change is one that breaks any udev 
> more than 10 
> > months or so old...)
> 
> After a bit of discussion (see bug 201242 in the redhat 
> bugzilla) about updating FC4 userland, it seems that we 
> should try to address this compatibility concern for legacy 
> userland in the kernel.  We could first upstream the patch 
> below, then re-base the range_transition kernel patch against 
> it.  This patch makes the maximum policy version a kernel 
> config option so that it can be adjusted down to accommodate 
> legacy userland, with instructions and examples in the help 
> text of the config option on how to determine what value to 
> use.  The range_transition kernel patch would then adjust the 
> "range" and "default" attributes of this new config option to 
> reflect the new version support, while users could still 
> build kernels to an older version.  Thoughts?

Hrm, I'd have really prefered this be handled in userspace, for example
by having init query semanage to find out what policy version to use
(this not only affects loading old policies but also potentially stale
ones which we have no protection against right now)

If libsemanage wrote the latest policy name into the store an semanage
call could give it the info whether it was policy.n, policy.n-2 or
policy.somethingentirelydifferent.One thing to think about with this
solution is how to handle multiple security servers though. 

However, this seems fairly imperative and your proposed way of handling
it is fast and simple so I guess it needs to go in regardless.


--
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: [PATCH 0/2] new and improved range_transition statements

[Stephen Smalley]

On Mon, 2006-08-07 at 08:04 -0400, Joshua Brindle wrote:
>  
> > -----Original Message-----
> > From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> > Sent: Friday, August 04, 2006 9:20 AM
> > To: Valdis.Kletnieks@vt.edu
> > Cc: James Morris; Karl MacMillan; Darrel Goeddel; 'SELinux 
> > List'; Eric Paris; Joshua Brindle
> > Subject: Re: [PATCH 0/2] new and improved range_transition statements
> > 
> > On Mon, 2006-07-31 at 11:10 -0400, Valdis.Kletnieks@vt.edu wrote:
> > > On Mon, 31 Jul 2006 10:43:15 EDT, Stephen Smalley said:
> > > 
> > > > I agree that it is too late for 2.6.18, but just to clarify - the 
> > > > kernel patch preserves backward compatibility for older binary 
> > > > policy formats.
> > > > 
> > > > As far as compatibility is concerned, FC4 will need some kind of 
> > > > userland update when it updates to a kernel with the new policy 
> > > > format; otherwise, init will give up when it cannot find 
> > policy.21 
> > > > or policy.20 (older sysvinit selinux patch only tried n 
> > and (n-1)), 
> > > > and the policy in
> > > > FC4 was version 19.
> > > 
> > > Given that Andrew Morton is currently having a cow over the 
> > fact that
> > > 2.6.18-rc3 includes a change that breaks the udev that shipped with 
> > > FC3, we might want to make sure we have all our ducks lined up....
> > > 
> > > (To be fair, the udev change is one that breaks any udev 
> > more than 10 
> > > months or so old...)
> > 
> > After a bit of discussion (see bug 201242 in the redhat 
> > bugzilla) about updating FC4 userland, it seems that we 
> > should try to address this compatibility concern for legacy 
> > userland in the kernel.  We could first upstream the patch 
> > below, then re-base the range_transition kernel patch against 
> > it.  This patch makes the maximum policy version a kernel 
> > config option so that it can be adjusted down to accommodate 
> > legacy userland, with instructions and examples in the help 
> > text of the config option on how to determine what value to 
> > use.  The range_transition kernel patch would then adjust the 
> > "range" and "default" attributes of this new config option to 
> > reflect the new version support, while users could still 
> > build kernels to an older version.  Thoughts?
> 
> Hrm, I'd have really prefered this be handled in userspace, for example
> by having init query semanage to find out what policy version to use
> (this not only affects loading old policies but also potentially stale
> ones which we have no protection against right now)
> 
> If libsemanage wrote the latest policy name into the store an semanage
> call could give it the info whether it was policy.n, policy.n-2 or
> policy.somethingentirelydifferent.One thing to think about with this
> solution is how to handle multiple security servers though. 
> 
> However, this seems fairly imperative and your proposed way of handling
> it is fast and simple so I guess it needs to go in regardless.

Possibly we aren't communicating - the current userland (e.g. in FC5 and
later) already handles this situation correctly; libsemanage always
generates the latest policy version supported by libsepol (unless
overridden by semanage.conf), and libselinux loads the latest policy
version supported by libsepol, or the closest one to it, downgrading on
the fly if necessary via libsepol to the kernel's policyvers, and
SysVinit uses the libselinux policy loader now.  The purpose of this
kernel patch is to avoid breaking legacy userland (e.g. FC3, FC4) that
predates all of this support (libsemanage altogether, the libsepol
interfaces needed to make it work, the libselinux helper function to
fully encapsulate the policy load, and the changes to SysVinit to use
the libselinux helper function).

BTW, one way to address Darrel's concern is to leave the default value
unchanged (at 20) when we merge the range transition patch, so that the
kernel package maintainer or user has to take positive action to force
the kernel to support policy version 21.

-- 
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: [PATCH 0/2] new and improved range_transition statements

[Joshua Brindle]

> From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> 
> On Mon, 2006-08-07 at 08:04 -0400, Joshua Brindle wrote:
> >  
<snip>
> > Hrm, I'd have really prefered this be handled in userspace, for 
> > example by having init query semanage to find out what 
> policy version 
> > to use (this not only affects loading old policies but also 
> > potentially stale ones which we have no protection against 
> right now)
> > 
> > If libsemanage wrote the latest policy name into the store 
> an semanage 
> > call could give it the info whether it was policy.n, policy.n-2 or 
> > policy.somethingentirelydifferent.One thing to think about 
> with this 
> > solution is how to handle multiple security servers though.
> > 
> > However, this seems fairly imperative and your proposed way of 
> > handling it is fast and simple so I guess it needs to go in 
> regardless.
> 
> Possibly we aren't communicating - the current userland (e.g. 
> in FC5 and
> later) already handles this situation correctly; libsemanage 
> always generates the latest policy version supported by 
> libsepol (unless overridden by semanage.conf), and libselinux 
> loads the latest policy version supported by libsepol, or the 
> closest one to it, downgrading on the fly if necessary via 
> libsepol to the kernel's policyvers, and SysVinit uses the 
> libselinux policy loader now.  The purpose of this kernel 
> patch is to avoid breaking legacy userland (e.g. FC3, FC4) 
> that predates all of this support (libsemanage altogether, 
> the libsepol interfaces needed to make it work, the 
> libselinux helper function to fully encapsulate the policy 
> load, and the changes to SysVinit to use the libselinux 
> helper function).
> 

Ah, ok, fair enough. It seems strange that people are upgrading kernels
in FC3, FC4 but not userland, just seems like a bad idea.

> BTW, one way to address Darrel's concern is to leave the 
> default value unchanged (at 20) when we merge the range 
> transition patch, so that the kernel package maintainer or 
> user has to take positive action to force the kernel to 
> support policy version 21.
> 

That is reasonable for RH to do for its legacy systems but doing it in
mainline seems silly, particularly since its going to mean very few
people testing out the new code.


--
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: [PATCH 0/2] new and improved range_transition statements

[Stephen Smalley]

On Mon, 2006-08-07 at 10:32 -0400, Joshua Brindle wrote:
> > From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
> > Possibly we aren't communicating - the current userland (e.g. 
> > in FC5 and
> > later) already handles this situation correctly; libsemanage 
> > always generates the latest policy version supported by 
> > libsepol (unless overridden by semanage.conf), and libselinux 
> > loads the latest policy version supported by libsepol, or the 
> > closest one to it, downgrading on the fly if necessary via 
> > libsepol to the kernel's policyvers, and SysVinit uses the 
> > libselinux policy loader now.  The purpose of this kernel 
> > patch is to avoid breaking legacy userland (e.g. FC3, FC4) 
> > that predates all of this support (libsemanage altogether, 
> > the libsepol interfaces needed to make it work, the 
> > libselinux helper function to fully encapsulate the policy 
> > load, and the changes to SysVinit to use the libselinux 
> > helper function).
> > 
> 
> Ah, ok, fair enough. It seems strange that people are upgrading kernels
> in FC3, FC4 but not userland, just seems like a bad idea.

IIUC, that's standard practice in Fedora - userland freezes except for
bug fixes at release time, while kernels re-base to each new kernel.org
release during the life cycle of the distribution.  Not something I can
control...

More importantly, kernel developers and some users often build and test
new kernels on existing distros, and expect new kernels to always
provide backward compatibility for existing userland, even when that
existing userland is broken. 

> > BTW, one way to address Darrel's concern is to leave the 
> > default value unchanged (at 20) when we merge the range 
> > transition patch, so that the kernel package maintainer or 
> > user has to take positive action to force the kernel to 
> > support policy version 21.
> > 
> 
> That is reasonable for RH to do for its legacy systems but doing it in
> mainline seems silly, particularly since its going to mean very few
> people testing out the new code.

Mainline seems to take the opposite view, i.e. require people to take
positive action to do anything that will break their existing userland.
Compatibility given precedence over new features.
 
-- 
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: [PATCH 0/2] new and improved range_transition statements

[Christopher J. PeBenito]

On Fri, 2006-08-04 at 09:19 -0400, Stephen Smalley wrote:
> On Mon, 2006-07-31 at 11:10 -0400, Valdis.Kletnieks@vt.edu wrote:
> > On Mon, 31 Jul 2006 10:43:15 EDT, Stephen Smalley said:
> > 
> > > I agree that it is too late for 2.6.18, but just to clarify - the kernel
> > > patch preserves backward compatibility for older binary policy
> > > formats.  
> > > 
> > > As far as compatibility is concerned, FC4 will need some kind of
> > > userland update when it updates to a kernel with the new policy format;
> > > otherwise, init will give up when it cannot find policy.21 or policy.20
> > > (older sysvinit selinux patch only tried n and (n-1)), and the policy in
> > > FC4 was version 19.

> After a bit of discussion (see bug 201242 in the redhat bugzilla) about
> updating FC4 userland, it seems that we should try to address this
> compatibility concern for legacy userland in the kernel.  We could first
> upstream the patch below, then re-base the range_transition kernel patch
> against it.  This patch makes the maximum policy version a kernel config
> option so that it can be adjusted down to accommodate legacy userland,
> with instructions and examples in the help text of the config option on
> how to determine what value to use.  The range_transition kernel patch
> would then adjust the "range" and "default" attributes of this new
> config option to reflect the new version support, while users could
> still build kernels to an older version.  Thoughts?

My feeling is that this is optimized for the wrong case.  Since the
current userland has known how to auto downgrade for a while, no one
will actually need this option unless they're building a kernel for for
FC3 or 4, so the common case would be not to override the max version,
especially as time progresses and FC3 and 4 become no longer maintained.
Also, people that compile their kernel, and use `make oldconfig` won't
know they need to update their max version in their config when the
policydb version increases.  My suggestion is to have this as an option,
so that if needed the max version can be overridden.  Then if the option
is off, it uses the actual max version.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
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: [PATCH 0/2] new and improved range_transition statements

[Stephen Smalley]

On Mon, 2006-08-07 at 10:34 -0400, Christopher J. PeBenito wrote:
> On Fri, 2006-08-04 at 09:19 -0400, Stephen Smalley wrote:
> > On Mon, 2006-07-31 at 11:10 -0400, Valdis.Kletnieks@vt.edu wrote:
> > > On Mon, 31 Jul 2006 10:43:15 EDT, Stephen Smalley said:
> > > 
> > > > I agree that it is too late for 2.6.18, but just to clarify - the kernel
> > > > patch preserves backward compatibility for older binary policy
> > > > formats.  
> > > > 
> > > > As far as compatibility is concerned, FC4 will need some kind of
> > > > userland update when it updates to a kernel with the new policy format;
> > > > otherwise, init will give up when it cannot find policy.21 or policy.20
> > > > (older sysvinit selinux patch only tried n and (n-1)), and the policy in
> > > > FC4 was version 19.
> 
> > After a bit of discussion (see bug 201242 in the redhat bugzilla) about
> > updating FC4 userland, it seems that we should try to address this
> > compatibility concern for legacy userland in the kernel.  We could first
> > upstream the patch below, then re-base the range_transition kernel patch
> > against it.  This patch makes the maximum policy version a kernel config
> > option so that it can be adjusted down to accommodate legacy userland,
> > with instructions and examples in the help text of the config option on
> > how to determine what value to use.  The range_transition kernel patch
> > would then adjust the "range" and "default" attributes of this new
> > config option to reflect the new version support, while users could
> > still build kernels to an older version.  Thoughts?
> 
> My feeling is that this is optimized for the wrong case.  Since the
> current userland has known how to auto downgrade for a while, no one
> will actually need this option unless they're building a kernel for for
> FC3 or 4, so the common case would be not to override the max version,
> especially as time progresses and FC3 and 4 become no longer maintained.
> Also, people that compile their kernel, and use `make oldconfig` won't
> know they need to update their max version in their config when the
> policydb version increases.  My suggestion is to have this as an option,
> so that if needed the max version can be overridden.  Then if the option
> is off, it uses the actual max version.

Ok, the patch below takes this approach.  I would then expect the range
transition patch to just update the "range" attribute max in Kconfig and
the definition of POLICYDB_VERSION_MAX in the #else clause in security.h
for the new version, while leaving the rest alone.

diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig
index 814ddc4..e718381 100644
--- a/security/selinux/Kconfig
+++ b/security/selinux/Kconfig
@@ -124,3 +124,36 @@ config SECURITY_SELINUX_ENABLE_SECMARK_D
 
 	  If you are unsure what do do here, select N.
 
+config SECURITY_SELINUX_POLICYDB_VERSION_MAX
+	bool "NSA SELinux maximum supported policy format version"
+	depends on SECURITY_SELINUX
+	default n
+	help
+	  This option enables the maximum policy format version supported
+	  by SELinux to be set to a particular value.  This value is reported
+	  to userspace via /selinux/policyvers and used at policy load time.
+	  It can be adjusted downward to support legacy userland (init) that
+	  does not correctly handle kernels that support newer policy versions.
+
+	  Examples:  For FC3 or FC4, enable this option and set the value via
+	  the next option.  For FC5 and later, do not enable this option.
+
+	  If you are unsure how to answer this question, answer N.
+
+config SECURITY_SELINUX_POLICYDB_VERSION_MAX_VALUE
+	int "NSA SELinux maximum supported policy format version value"
+	depends on SECURITY_SELINUX_POLICYDB_VERSION_MAX
+	range 15 20
+	default 19
+	help
+	  This option sets the value for the maximum policy format version
+	  supported by SELinux.
+
+	  Examples:  For FC3, use 18.  For FC4, use 19.
+
+	  If you are unsure how to answer this question, look for the
+	  policy format version supported by your policy toolchain, by
+	  running 'checkpolicy -V'. Or look at what policy you have
+	  installed under /etc/selinux/$SELINUXTYPE/policy, where
+	  SELINUXTYPE is defined in your /etc/selinux/config.
+
diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
index 063af47..f4b784f 100644
--- a/security/selinux/include/security.h
+++ b/security/selinux/include/security.h
@@ -27,7 +27,11 @@ #define POLICYDB_VERSION_AVTAB		20
 
 /* Range of policy versions we understand*/
 #define POLICYDB_VERSION_MIN   POLICYDB_VERSION_BASE
-#define POLICYDB_VERSION_MAX   POLICYDB_VERSION_AVTAB
+#ifdef CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX
+#define POLICYDB_VERSION_MAX	CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX_VALUE
+#else
+#define POLICYDB_VERSION_MAX	POLICYDB_VERSION_AVTAB
+#endif
 
 extern int selinux_enabled;
 extern int selinux_mls_enabled;


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