On Fri, Jun 14, 2013 at 3:46 PM, Paul Moore <pmoore@xxxxxxxxxx> 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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
