On Wed, 2008-09-17 at 15:32 -0700, Eric W. Biederman wrote:
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.
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.
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
--
