On Fri, 2007-06-22 at 14:54 +0200, Lars Marowsky-Bree wrote: > On 2007-06-22T08:41:51, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > > Sorry, do you mean the "server" as in the "server system" or as in the > > "server daemon"? For the former, I'd agree - we would want SELinux > > policy applied on the server as well as the client to ensure that the > > data is being protected consistently throughout and that the server is > > not misrepresenting the security guarantees expected by the clients. > > Providing an illusion of confinement on each client without any > > corresponding protection on the server system would be very prone to > > bypass. For the latter, the kernel can only truly confine application > > code, not in-kernel threads, although we can subject the in-kernel nfsd > > to permission checking as a robustness check. We've always noted that > > SELinux does depend on the correctness of the kernel. > > Oh, you're saying that this threat is out-of-scope? ;-) Kernel flaws aren't something we can address (reliably and in general) via a kernel mechanism. Versus a threat that can be addressed by kernel mechanism, like providing complete mediation and unambiguous access control. There is a difference. And we aren't ignoring the kernel correctness problem - there is separate work in that space, but it requires separate mechanism outside of SELinux itself. > Note that here we've already strayed from the focus of the discussion; > we're no longer arguing "the implementation is ugly/broken", but you're > claiming "doesn't do what I need" - which I'm not disagreeing with. It > doesn't do what you want. Which is why you have SELinux, and it's going > to stay. Fine. > > If we assume that the users who run it do have a need / use case for it > which they can't solve differently, we should really get back to the > discussion of how those needs can be met or provided by Linux in a > feasible way. Part of the discussion has been whether those users' needs could be solved better via SELinux, whether via improved userspace tools (ala seedit possibly with an enhanced restorecond) or via extended kernel mechanism (ala named type transitions and some kind of inheritance model). It does however seem like there is a fundamental conflict there on renaming behavior; I do not believe that file protections should automatically change in the kernel upon rename and should require explicit userspace action. The question though is whether that renaming behavior in AA is truly a user requirement or a manufactured (i.e. made-up) one, and whether it is truly a runtime requirement or just a policy creation time one (the latter being adequately addressed by userspace relabeling). If that behavior is truly needed (a point I wouldn't concede), then the discussion does reduce down to the right implementation method. There it appears that the primary objection is to regenerating full pathname strings and matching them versus some kind of incremental matching either during lookup itself or via a reverse match as suggested. That discussion is principally one in which the vfs folks should be engaged, not me. > > > Your use case mandates complete system-wide mediation, because you want > > > full data flow analysis. Mine doesn't. > > Then yours isn't mandatory access control, nor is it confinement. > > I apologize for not using the word "confinement" in the way you expect > it to be used. I certainly don't want to imply it does do things it > doesn't. Keep in mind I'm not a native speaker, so nuances do get lost > sometimes; nor do I have long years of experience in the security > field. Thanks for clearing this up. > > So agreed, it is not confinement nor MAC. > > Would it be more appropriate if I used the word "restricts" or > "constrains"? Yes. Or simply "controls file accesses and capability usage". -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
