new and improved range_transition statements
cover new and improved range_transition statements
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.
Signature · 6 lines
Darrel -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 6 lines · Darrel Goeddel
This following patches allow for specification of security classes for
range_transitionstatements in the policy. This is intended to address a solution for RedHat Bugzilla #185436.
Quoted 7 lines
While working on this format change to allow class specification, it was noted that the current
range_transitionhandling 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 handlingrange_transitionrules.
Thanks for taking the time to make this more complete.
Quoted 6 lines
Hopefully, this format will
allow forrange_transitionstatements 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:
Quoted 8 lines
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>
Quoted 3 lines
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.
Quoted 6 lines
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_transitionstatements 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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 10 lines · Karl MacMillan
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.
Signature · 8 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 7 lines · Stephen Smalley
Quoted 6 lines · Karl MacMillan
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.
Quoted 9 lines
Quoted 4 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 24 lines
From: Karl MacMillan [mailto:[email protected]]
Quoted 4 lines · Stephen Smalley
Quoted 3 lines · Karl MacMillan
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
Quoted 4 lines
Quoted 4 lines
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
Quoted 2 lines
Quoted 2 lines
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
Quoted 1 line
Quoted 1 line
make it in time for 2.6.18 and if they don't will this be
included in RHEL 5 / FC6?
Quoted 5 lines
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.
Quoted 5 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 30 lines · Joshua Brindle
Quoted 24 lines
From: Karl MacMillan [mailto:[email protected]]
Quoted 4 lines · Stephen Smalley
Quoted 3 lines · Karl MacMillan
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
Quoted 4 lines
Quoted 4 lines
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
Quoted 2 lines
Quoted 2 lines
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
Quoted 1 line
Quoted 1 line
make it in time for 2.6.18 and if they don't will this be
included in RHEL 5 / FC6?
Quoted 5 lines
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.
Quoted 5 lines
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.
Quoted 3 lines
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?
Quoted 2 lines
(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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 4 lines
From: Karl MacMillan [mailto:[email protected]]
Quoted 1 line · Joshua Brindle
Quoted 1 line
From: Karl MacMillan [mailto:[email protected]]
<snip?
Quoted 9 lines
Quoted 4 lines
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.
Quoted 9 lines
Quoted 2 lines
(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
Quoted 3 lines
- fixing
avrule_blockto correctly represent what is possible (removing arbitrary branches)
That's a style change more than anything, no functional difference, very low priority
Quoted 2 lines
- better handling of
type->flavor(if needed)
??
Quoted 2 lines
- 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.
Quoted 2 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 7 lines · Stephen Smalley
Quoted 6 lines · Karl MacMillan
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.
Quoted 8 lines
Quoted 4 lines
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).
Quoted 18 lines · Karl MacMillan
Quoted 7 lines · Stephen Smalley
Quoted 6 lines · Karl MacMillan
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.
Quoted 9 lines
Quoted 4 lines
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.
Quoted 4 lines
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.
Signature · 8 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 13 lines · On Mon, 2006-07-31 at 10:28 -0400, [email protected] wrote:
Quoted 12 lines · Stephen Smalley
Quoted 10 lines · Karl MacMillan
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?
Quoted 8 lines
Quoted 3 lines
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.
Signature · 8 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 19 lines · Stephen Smalley
Quoted 18 lines · Karl MacMillan
Quoted 16 lines · Stephen Smalley
Quoted 10 lines · Karl MacMillan
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.
Quoted 9 lines
Quoted 4 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 28 lines · Stephen Smalley
Quoted 20 lines · Karl MacMillan
Quoted 8 lines · Stephen Smalley
Quoted 6 lines · Karl MacMillan
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.
Quoted 9 lines
Quoted 4 lines
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.
Quoted 4 lines
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.
Quoted 3 lines
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.
Signature · 6 lines
Darrel -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 2 lines · Joshua Brindle
Quoted 2 lines
From: Karl MacMillan [mailto:[email protected]]
<snip>
Quoted 7 lines
Quoted 4 lines
- 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.
Quoted 7 lines
Quoted 3 lines
- fixing
avrule_blockto correctly represent what is possible (removing arbitrary branches)That's a style change more than anything, no functional difference, very low priority
Yep
Quoted 5 lines
Quoted 2 lines
- 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.
Quoted 7 lines
Quoted 2 lines
- 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.
Quoted 7 lines
Quoted 2 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 9 lines · Stephen Smalley
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...)
Quoted 12 lines · On Mon, 2006-07-31 at 11:10 -0400, [email protected] wrote:
Quoted 9 lines · Stephen Smalley
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.
Quoted 6 lines
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?
security/selinux/Kconfig +21 -0
@@ -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.
security/selinux/include/security.h +1 -1
@@ -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_MAXextern int selinux_enabled;extern int selinux_mls_enabled;
Signature · 8 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 3 lines · Stephen Smalley
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.
Signature · 7 lines
James Morris <[email protected]> -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 23 lines · Stephen Smalley
Quoted 13 lines · On Mon, 2006-07-31 at 11:10 -0400, [email protected] wrote:
Quoted 9 lines · Stephen Smalley
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.
Quoted 6 lines
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...)
Quoted 11 lines
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_transitionkernel 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. Therange_transitionkernel 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...)
Signature · 6 lines
Darrel -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 35 lines
-----Original Message-----
From: Stephen Smalley [mailto:[email protected]]
Sent: Friday, August 04, 2006 9:20 AM
To: [email protected]
Cc: James Morris; Karl MacMillan; Darrel Goeddel; 'SELinux List'; Eric Paris; Joshua Brindle
Subject: Re: [PATCH 0/2] new and improvedrange_transitionstatementsQuoted 9 lines · On Mon, 2006-07-31 at 11:10 -0400, [email protected] wrote:
Quoted 7 lines · Stephen Smalley
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
Quoted 1 line
Quoted 1 line
or policy.20 (older sysvinit selinux patch only tried n
and (n-1)),
Quoted 4 lines
Quoted 2 lines
and the policy in
FC4 was version 19.Given that Andrew Morton is currently having a cow over the
fact that
Quoted 4 lines
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
Quoted 1 line
months or so old...)
Quoted 13 lines
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_transitionkernel 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. Therange_transitionkernel 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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 53 lines · Joshua Brindle
Quoted 34 lines
-----Original Message-----
From: Stephen Smalley [mailto:[email protected]]
Sent: Friday, August 04, 2006 9:20 AM
To: [email protected]
Cc: James Morris; Karl MacMillan; Darrel Goeddel; 'SELinux List'; Eric Paris; Joshua Brindle
Subject: Re: [PATCH 0/2] new and improvedrange_transitionstatementsQuoted 9 lines · On Mon, 2006-07-31 at 11:10 -0400, [email protected] wrote:
Quoted 7 lines · Stephen Smalley
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
Quoted 1 line
Quoted 1 line
or policy.20 (older sysvinit selinux patch only tried n
and (n-1)),
Quoted 4 lines
Quoted 2 lines
and the policy in
FC4 was version 19.Given that Andrew Morton is currently having a cow over the
fact that
Quoted 4 lines
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
Quoted 1 line
months or so old...)
Quoted 13 lines
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_transitionkernel 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. Therange_transitionkernel 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)
Quoted 7 lines
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.
Signature · 8 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 4 lines
From: Stephen Smalley [mailto:[email protected]]
Quoted 1 line · Joshua Brindle
<snip>
Quoted 18 lines
Quoted 2 lines
Hrm, I'd have really prefered this be handled in userspace, for example by having init query semanage to find out what
policy version
Quoted 2 lines
to use (this not only affects loading old policies but also potentially stale ones which we have no protection against
right now)
Quoted 2 lines
If libsemanage wrote the latest policy name into the store
an semanage
Quoted 2 lines
call could give it the info whether it was policy.n, policy.n-2 or policy.somethingentirelydifferent.One thing to think about
with this
Quoted 4 lines
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.
Quoted 16 lines
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.
Quoted 6 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 13 lines · Stephen Smalley
Quoted 11 lines · On Mon, 2006-07-31 at 11:10 -0400, [email protected] wrote:
Quoted 9 lines · Stephen Smalley
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.
Quoted 11 lines
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_transitionkernel 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. Therange_transitionkernel 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.
Signature · 9 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 18 lines · Joshua Brindle
Quoted 8 lines
From: Stephen Smalley [mailto:[email protected]] 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 viaQuoted 9 lines
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).
Quoted 2 lines
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.
Quoted 10 lines
Quoted 6 lines
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.
Signature · 8 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 26 lines · Christopher J. PeBenito
Quoted 13 lines · Stephen Smalley
Quoted 11 lines · On Mon, 2006-07-31 at 11:10 -0400, [email protected] wrote:
Quoted 9 lines · Stephen Smalley
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.
Quoted 11 lines
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_transitionkernel 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. Therange_transitionkernel 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?
Quoted 10 lines
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 oldconfigwon'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.
security/selinux/Kconfig +33 -0
@@ -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. +
security/selinux/include/security.h +5 -1
@@ -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;
Signature · 8 lines
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.