On Wed, 2008-09-17 at 15:32 -0700, Eric W. Biederman wrote: > Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> writes: > > > We don't even know the extent of the damage yet. Which distros were > > affected? With which versions of which userspace packages? > > This seems to me to be an extremely fragile selinux user space policy. > In their code that derives security labels from path names. > Why don't we have AppArmor in the kernel again? I think I explained that one before - in the case of /proc, the only stable basis we have for deducing the security properties / protection requirements for a given entry is its name, and its name can be reliably constructed from the kernel's internal proc_dir_entry tree w/o any ambiguity or potential for userspace manipulation (unlike the pathname returned by d_path for a normal file). I'd agree that it isn't optimal, but it is what we have. > Further I don't see how we could have possibly have supported that user space > policy. How can we apply a user space defined label required by the selinux > policy to a symlink that did not exist? I'm not blaming anyone here, or trying to argue that the /proc/net changes should be reverted. What happened here is that a kernel interface (/proc/net) changed in a subtle way that had a side effect on permission checking, and we tried to hide that change at the time (in terms of ensuring that the new /proc/self/net tree would still be labeled correctly), and we missed the fact that there would still be a new check on the symlink read that wouldn't be covered by existing policy. > Everything here sounds to me like that selinux policy is impossibly brittle. > And anything that is that brittle I have no intention in claiming is a bug > in proc. I'm not arguing that this is a bug in proc or in selinux for that matter. I do however think that the mantra that we can't require users to update policy for kernel changes is unsupportable in general. The precise set of permission checks on a given operation is not set in stone and it is not part of the kernel/userland interface/contract. Policy isn't "userspace"; it governs what userspace can do, and it has to adapt to kernel changes. Users who are willing/able to run the latest kernel on their own w/o waiting for a coordinated update of kernel and policy from their distribution ought to be able to create a local policy module - it isn't rocket science, and they can always fall back on audit2allow if they need to do so. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
