Deprecating policy capabilities (was: Clarification of labeled IPsec checks)

Deprecating policy capabilities (was: Clarification of labeled IPsec checks)

[Paul Moore]

On Tuesday, May 07, 2013 09:05:30 AM Paul Moore wrote:
> On Monday, May 06, 2013 09:50:04 AM Christopher J. PeBenito wrote:
> > On 05/03/13 15:20, Paul Moore wrote:
> > > It has been a while since we introduced the netpeer policy capability so
> > > I imagine we could start a process of deprecating policies that don't
> > > enable it. We could dump a warning message if someone loads a policy
> > > with the netpeer capability disabled and then after a few releases (how
> > > many?) we could remove the legacy bits from the kernel and reject
> > > policies which don't have the netpeer capability set.
> > 
> > The common case obviously is no labeling, and in that case, there wouldn't
> > be checks.  So I suspect this wouldn't have any real problems.  My guess
> > is systems that use this wouldn't be changing their OS very often, and
> > when they do, it would be major jumps (e.g. RHEL6 to RHEL7), so they'd be
> > anticipating changes like this.
> 
> Yeah, I agree.  I'll throw together a deprecation patch and toss it out so
> we can have a bit more of a discussion on this.

I just took a closer look at this and as much as I would like to require 
policies to enable the netpeer capability so we could remove a bunch of old 
code, I don't think we can do this anytime soon.

The problem is that the kernel still supports old policy versions, back to 
v15, and the policy capability support wasn't added until policy v22.  For 
obvious reasons, we can't really deprecate a policy capability (at least not 
the netpeer capability) until our minimum supported policy version is v22 or 
higher.  I'm not sure that is something we can really do at this point - 
thoughts?

-- 
paul moore
security and virtualization @ redhat


--
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: Deprecating policy capabilities (was: Clarification of labeled IPsec checks)

[Joshua Brindle]

On Fri, Jun 14, 2013 at 3:46 PM, Paul Moore <pmoore@redhat.com> wrote:
> On Tuesday, May 07, 2013 09:05:30 AM Paul Moore wrote:
>> On Monday, May 06, 2013 09:50:04 AM Christopher J. PeBenito wrote:
>> > On 05/03/13 15:20, Paul Moore wrote:
>> > > It has been a while since we introduced the netpeer policy capability so
>> > > I imagine we could start a process of deprecating policies that don't
>> > > enable it. We could dump a warning message if someone loads a policy
>> > > with the netpeer capability disabled and then after a few releases (how
>> > > many?) we could remove the legacy bits from the kernel and reject
>> > > policies which don't have the netpeer capability set.
>> >
>> > The common case obviously is no labeling, and in that case, there wouldn't
>> > be checks.  So I suspect this wouldn't have any real problems.  My guess
>> > is systems that use this wouldn't be changing their OS very often, and
>> > when they do, it would be major jumps (e.g. RHEL6 to RHEL7), so they'd be
>> > anticipating changes like this.
>>
>> Yeah, I agree.  I'll throw together a deprecation patch and toss it out so
>> we can have a bit more of a discussion on this.
>
> I just took a closer look at this and as much as I would like to require
> policies to enable the netpeer capability so we could remove a bunch of old
> code, I don't think we can do this anytime soon.
>
> The problem is that the kernel still supports old policy versions, back to
> v15, and the policy capability support wasn't added until policy v22.  For
> obvious reasons, we can't really deprecate a policy capability (at least not
> the netpeer capability) until our minimum supported policy version is v22 or
> higher.  I'm not sure that is something we can really do at this point -
> thoughts?
>

I doubt that anyone has tested a < v22 policy on a modern system in
quite some time... I would wonder if it still works correctly. If it
hasn't been it seems like a good idea to deprecate unused, untested
configurations for stability and security. There isn't much of a
reason to use old policies on new kernels since 1) pre-existing binary
policies are unlikely to work on new distros and 2) the toolchain can
build new policies from old source.

--
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: Deprecating policy capabilities (was: Clarification of labeled IPsec checks)

[Stephen Smalley]

On 06/14/2013 04:03 PM, Joshua Brindle wrote:
> On Fri, Jun 14, 2013 at 3:46 PM, Paul Moore <pmoore@redhat.com> wrote:
>> On Tuesday, May 07, 2013 09:05:30 AM Paul Moore wrote:
>>> On Monday, May 06, 2013 09:50:04 AM Christopher J. PeBenito wrote:
>>>> On 05/03/13 15:20, Paul Moore wrote:
>>>>> It has been a while since we introduced the netpeer policy capability so
>>>>> I imagine we could start a process of deprecating policies that don't
>>>>> enable it. We could dump a warning message if someone loads a policy
>>>>> with the netpeer capability disabled and then after a few releases (how
>>>>> many?) we could remove the legacy bits from the kernel and reject
>>>>> policies which don't have the netpeer capability set.
>>>>
>>>> The common case obviously is no labeling, and in that case, there wouldn't
>>>> be checks.  So I suspect this wouldn't have any real problems.  My guess
>>>> is systems that use this wouldn't be changing their OS very often, and
>>>> when they do, it would be major jumps (e.g. RHEL6 to RHEL7), so they'd be
>>>> anticipating changes like this.
>>>
>>> Yeah, I agree.  I'll throw together a deprecation patch and toss it out so
>>> we can have a bit more of a discussion on this.
>>
>> I just took a closer look at this and as much as I would like to require
>> policies to enable the netpeer capability so we could remove a bunch of old
>> code, I don't think we can do this anytime soon.
>>
>> The problem is that the kernel still supports old policy versions, back to
>> v15, and the policy capability support wasn't added until policy v22.  For
>> obvious reasons, we can't really deprecate a policy capability (at least not
>> the netpeer capability) until our minimum supported policy version is v22 or
>> higher.  I'm not sure that is something we can really do at this point -
>> thoughts?
>>
>
> I doubt that anyone has tested a < v22 policy on a modern system in
> quite some time... I would wonder if it still works correctly. If it
> hasn't been it seems like a good idea to deprecate unused, untested
> configurations for stability and security. There isn't much of a
> reason to use old policies on new kernels since 1) pre-existing binary
> policies are unlikely to work on new distros and 2) the toolchain can
> build new policies from old source.

I thought the requirement was that new kernels cannot break old 
userspace (including policies), i.e. we have to be able to boot latest 
kernel with ancient Fedora or RHEL and not have anything break.  RHEL4 
used policy.18 IIRC.  At the moment booting a new kernel with an old 
distro usually works due to a combination of handle_unknown=allow and 
policy capabilities not being enabled in the old policy.



--
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: Deprecating policy capabilities (was: Clarification of labeled IPsec checks)

[Joshua Brindle]

On Fri, Jun 14, 2013 at 4:17 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 06/14/2013 04:03 PM, Joshua Brindle wrote:
>>
>> On Fri, Jun 14, 2013 at 3:46 PM, Paul Moore <pmoore@redhat.com> wrote:
>>>
>>> On Tuesday, May 07, 2013 09:05:30 AM Paul Moore wrote:
>>>>
>>>> On Monday, May 06, 2013 09:50:04 AM Christopher J. PeBenito wrote:
>>>>>
>>>>> On 05/03/13 15:20, Paul Moore wrote:
>>>>>>
>>>>>> It has been a while since we introduced the netpeer policy capability
>>>>>> so
>>>>>> I imagine we could start a process of deprecating policies that don't
>>>>>> enable it. We could dump a warning message if someone loads a policy
>>>>>> with the netpeer capability disabled and then after a few releases
>>>>>> (how
>>>>>> many?) we could remove the legacy bits from the kernel and reject
>>>>>> policies which don't have the netpeer capability set.
>>>>>
>>>>>
>>>>> The common case obviously is no labeling, and in that case, there
>>>>> wouldn't
>>>>> be checks.  So I suspect this wouldn't have any real problems.  My
>>>>> guess
>>>>> is systems that use this wouldn't be changing their OS very often, and
>>>>> when they do, it would be major jumps (e.g. RHEL6 to RHEL7), so they'd
>>>>> be
>>>>> anticipating changes like this.
>>>>
>>>>
>>>> Yeah, I agree.  I'll throw together a deprecation patch and toss it out
>>>> so
>>>> we can have a bit more of a discussion on this.
>>>
>>>
>>> I just took a closer look at this and as much as I would like to require
>>> policies to enable the netpeer capability so we could remove a bunch of
>>> old
>>> code, I don't think we can do this anytime soon.
>>>
>>> The problem is that the kernel still supports old policy versions, back
>>> to
>>> v15, and the policy capability support wasn't added until policy v22.
>>> For
>>> obvious reasons, we can't really deprecate a policy capability (at least
>>> not
>>> the netpeer capability) until our minimum supported policy version is v22
>>> or
>>> higher.  I'm not sure that is something we can really do at this point -
>>> thoughts?
>>>
>>
>> I doubt that anyone has tested a < v22 policy on a modern system in
>> quite some time... I would wonder if it still works correctly. If it
>> hasn't been it seems like a good idea to deprecate unused, untested
>> configurations for stability and security. There isn't much of a
>> reason to use old policies on new kernels since 1) pre-existing binary
>> policies are unlikely to work on new distros and 2) the toolchain can
>> build new policies from old source.
>
>
> I thought the requirement was that new kernels cannot break old userspace
> (including policies), i.e. we have to be able to boot latest kernel with
> ancient Fedora or RHEL and not have anything break.  RHEL4 used policy.18
> IIRC.  At the moment booting a new kernel with an old distro usually works
> due to a combination of handle_unknown=allow and policy capabilities not
> being enabled in the old policy.
>

Oh right, I forgot that there are people that boot new kernels on
ancient distros. How far back does the backward support have to go?

--
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: Deprecating policy capabilities

[Stephen Smalley]

On 06/14/2013 04:20 PM, Joshua Brindle wrote:
> On Fri, Jun 14, 2013 at 4:17 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> On 06/14/2013 04:03 PM, Joshua Brindle wrote:
>>>
>>> On Fri, Jun 14, 2013 at 3:46 PM, Paul Moore <pmoore@redhat.com> wrote:
>>>> I just took a closer look at this and as much as I would like to require
>>>> policies to enable the netpeer capability so we could remove a bunch of
>>>> old
>>>> code, I don't think we can do this anytime soon.
>>>>
>>>> The problem is that the kernel still supports old policy versions, back
>>>> to
>>>> v15, and the policy capability support wasn't added until policy v22.
>>>> For
>>>> obvious reasons, we can't really deprecate a policy capability (at least
>>>> not
>>>> the netpeer capability) until our minimum supported policy version is v22
>>>> or
>>>> higher.  I'm not sure that is something we can really do at this point -
>>>> thoughts?
>>>>
>>>
>>> I doubt that anyone has tested a < v22 policy on a modern system in
>>> quite some time... I would wonder if it still works correctly. If it
>>> hasn't been it seems like a good idea to deprecate unused, untested
>>> configurations for stability and security. There isn't much of a
>>> reason to use old policies on new kernels since 1) pre-existing binary
>>> policies are unlikely to work on new distros and 2) the toolchain can
>>> build new policies from old source.
>>
>>
>> I thought the requirement was that new kernels cannot break old userspace
>> (including policies), i.e. we have to be able to boot latest kernel with
>> ancient Fedora or RHEL and not have anything break.  RHEL4 used policy.18
>> IIRC.  At the moment booting a new kernel with an old distro usually works
>> due to a combination of handle_unknown=allow and policy capabilities not
>> being enabled in the old policy.
>>
>
> Oh right, I forgot that there are people that boot new kernels on
> ancient distros. How far back does the backward support have to go?

I think the view of the kernel developers was forever; new kernel is 
never supposed to break old userspace.  Of course there have been a few 
examples of that being broken by others in other subsystems, but that is 
frowned upon.

Even if we were to limit it to currently-supported enterprise 
distributions, I think we'd have to wait until RHEL-5 (policy.20?) is 
EOL'd.  Don't know about Debian or Ubuntu LTS.   Might as well be 
forever as we likely won't remember this conversation then.


--
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: Deprecating policy capabilities

[Russell Coker]

On Fri, 14 Jun 2013 16:25:52 Stephen Smalley wrote:
> > Oh right, I forgot that there are people that boot new kernels on
> > ancient distros. How far back does the backward support have to go?
> 
> I think the view of the kernel developers was forever; new kernel is 
> never supposed to break old userspace.  Of course there have been a few 
> examples of that being broken by others in other subsystems, but that is 
> frowned upon.
> 
> Even if we were to limit it to currently-supported enterprise 
> distributions, I think we'd have to wait until RHEL-5 (policy.20?) is 
> EOL'd.  Don't know about Debian or Ubuntu LTS.   Might as well be 
> forever as we likely won't remember this conversation then.

Sorry for the late reply, but this is an important an ongoing issue.

In Debian we don't aim to have any support for a kernel that is more than one 
version of Debian before or after the current version.

Debian/Wheezy works with a Squeeze kernel and I'll include an update to Wheezy 
to make it work better with a Jessie kernel when Jessie is released.

I will not accept bug reports about problems mixing Jessie and Squeeze parts.  
So the current userspace can entirely drop support for kernel 2.6.32 and the 
current kernel code can drop support for policy 20100524 and libselinux 2.0.96 
without doing anything that I'll accept as a Debian bug report.

What amount of mixing and matching kernel and userspace versions does Red Hat 
support?

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: Deprecating policy capabilities

[Paul Moore]

On Tuesday, June 10, 2014 10:54:21 AM Russell Coker wrote:
> On Fri, 14 Jun 2013 16:25:52 Stephen Smalley wrote:
> > > Oh right, I forgot that there are people that boot new kernels on
> > > ancient distros. How far back does the backward support have to go?
> > 
> > I think the view of the kernel developers was forever; new kernel is
> > never supposed to break old userspace.  Of course there have been a few
> > examples of that being broken by others in other subsystems, but that is
> > frowned upon.
> > 
> > Even if we were to limit it to currently-supported enterprise
> > distributions, I think we'd have to wait until RHEL-5 (policy.20?) is
> > EOL'd.  Don't know about Debian or Ubuntu LTS.   Might as well be
> > forever as we likely won't remember this conversation then.
> 
> Sorry for the late reply, but this is an important an ongoing issue.
> 
> In Debian we don't aim to have any support for a kernel that is more than
> one version of Debian before or after the current version.
> 
> Debian/Wheezy works with a Squeeze kernel and I'll include an update to
> Wheezy to make it work better with a Jessie kernel when Jessie is released.
> 
> I will not accept bug reports about problems mixing Jessie and Squeeze
> parts. So the current userspace can entirely drop support for kernel 2.6.32
> and the current kernel code can drop support for policy 20100524 and
> libselinux 2.0.96 without doing anything that I'll accept as a Debian bug
> report.
> 
> What amount of mixing and matching kernel and userspace versions does Red
> Hat support?

What an individual distribution supports isn't the critical point here as far 
as I'm concerned, the issue is that dropping support for older policies, 
regardless of use, is frowned upon and will likely cause a lot of shouting 
that I'd just assume avoid.

The only real exception to this that I can see is that if we prove that a 
older policies no longer work correctly and fixing it in the kernel is non-
trivial.  Also, when I say "older policies", I'm thinking that the policy has 
to be out of use from any major distribution for quite some time; anything new 
we just need to fix.

-- 
paul moore
www.paul-moore.com