On Wed, May 17, 2017 at 9:17 AM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > On Tue, 2017-05-16 at 17:19 -0400, Paul Moore wrote: >> On Tue, May 16, 2017 at 5:11 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> >> wrote: ... >> > If the kernel does not support a policy capability that was enabled >> > in >> > the policy, then it may not be capable of enforcing the policy as >> > intended, and may therefore be operating insecurely (e.g. consider >> > if >> > your kernel was too old to support network_peer_controls or >> > always_check_network or open_perms but your policy has enabled them >> > and >> > is relying on those checks to be present) ... >> >> Well, I think the key is "may"; depending on the policy capability >> and >> the handle_unknown setting things might not fail in an insecure >> manner, but the system would definitely behave >> strangely. Regardless, >> I see your point and I'm now wondering if we should just fail the >> policy load if we detect any policy capabilities beyond what we know >> about. > > I think that would prove problematic in practice since the system would > then refuse to boot with such a policy (the only way to boot in Linux > distributions would then be to boot with enforcing=0 and come up with > no policy - requiring you to then replace the policy, reboot, and > relabel, and in Android you can't boot at all if policy load fails - it > will reboot into recovery mode). It would mean that we could not add a > new policy capability to a policy until we were sure that no one was > still using a kernel that predated the support for it. Isn't that the right thing to do anyway? You shouldn't use a policy with a policy capability on a kernel that has no knowledge of the policy capability for the reasons we've already discussed. I'm also going to guess that this isn't as large a problem as we may be making it out, distributions should catch this problem fairly quickly in their development process and those that are savvy enough to load their own policy should know how to handle this as well. > That would more or less preclude new policy capabilities from ever being enabled by > default in refpolicy (or at least take years to introduce them) ... Once again, is it safe for refpolicy to enable these now if we are worrying about older kernels? > ... and > would also be a problem for Android, since many different kernel > versions (and often much older ones) are used with both. I'm not saying I have completely made my mind up about this, but right now I'm thinking the issue of new-policy/old-kernel is a distro problem (I view Android as just another distribution) and not something we can safely resolve upstream. > A warning seemed like a reasonable middle ground between silently > ignoring unknown policy capabilities (as the kernel currently does > before this patch) and rejecting the policy altogether. WARN vs INFO > was due to the fact that an unknown capability seemed more significant > and potentially an indicator of a kernel/policy mismatch than the state > of the known policy capabilities. -- paul moore www.paul-moore.com
