[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m18wtpuy04.fsf@frodo.ebiederm.org>
Date: Thu, 18 Sep 2008 11:09:31 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Stephen Smalley <sds@...ho.nsa.gov>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Paul Moore <paul.moore@...com>, jmorris@...ei.org, rjw@...k.pl,
linux-kernel@...r.kernel.org, kernel-testers@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [Bug #11500] /proc/net bug related to selinux
Stephen Smalley <sds@...ho.nsa.gov> writes:
> On Thu, 2008-09-18 at 08:38 -0400, Stephen Smalley wrote:
>> 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?
For comparison how do we handle sysfs?
How do we handle device nodes in tmpfs?
Ultimately do we want to implement xattrs and inotify on /proc?
Or is there another way that would simplify maintenance?
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists