On Fri, 2008-09-19 at 09:58 -0700, david@lang.hm wrote:

On Thu, 18 Sep 2008, Stephen Smalley wrote:

quoted

On Thu, 2008-09-18 at 11:09 -0700, Eric W. Biederman wrote:

quoted

Stephen Smalley [off-list ref] writes:

quoted

On Thu, 2008-09-18 at 08:38 -0400, Stephen Smalley wrote:

quoted

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.

I should note here that for changes to SELinux, we have gone out of our
way to avoid such breakage to date through the introduction of
compatibility switches, policy flags to enable any new checks, etc
(albeit at a cost in complexity and ever creeping compatibility code).
But changes to the rest of the kernel can just as easily alter the set
of permission checks that get applied on a given operation, and I don't
think we are always going to be able to guarantee that new kernel + old
policy will Just Work.

I know of at least 2 more directories that I intend to turn into
symlinks into somewhere under /proc/self.  How do we keep from
breaking selinux policies when I do that?

I suspect we could tweak the logic in selinux_proc_get_sid() to always
label all symlinks under /proc with the base proc_t type already used
for e.g. /proc/self, at which point existing policies would be ok.

so if proc is mounted anywhere other then /proc the selinux policy would 
do odd things?

No, the logic doesn't care where proc is mounted.  Only the name
relative to the root of proc is used.

-- 
Stephen Smalley
National Security Agency