On Fri, 2007-06-22 at 13:37 +0200, Lars Marowsky-Bree wrote: > On 2007-06-22T07:19:39, Stephen Smalley <[EMAIL PROTECTED]> wrote: > > > > > Or can access the data under a different path to which their profile > > > > does give them access, whether in its final destination or in some > > > > temporary file processed along the way. > > > Well, yes. That is intentional. > > > > > > Your point is? > > > > It may very well be unintentional access, especially when taking into > > account wildcards in profiles and user-writable directories. > > Again, you're saying that AA is not confining unconfined processes. > That's a given. If unconfined processes assist confined processes in > breeching their confinement, yes, that is not mediated.
The issue arises even for a collection of collaborating confined processes with different profiles, and the collaboration may be intentional or unintentional (in the latter case, one of the confined processes may be taking advantage of known behavior of another process and shared access by both to some resource in order to induce a particular behavior in that process). And remember that confinement isn't just about limiting untrusted processes but also about protecting trusted processes; limiting the inputs and outputs of a trusted process can be just as important to preventing exploitation. > You're basically saying that anything but system-wide mandatory access > control is pointless. Mandatory access control as historically understood has always meant system-wide. As well as always being based on the security properties of the data (so that global and persistent protection of the data is possible). You can't actually use the terms 'mandatory access control' or 'confinement' for AppArmor unless you redefine them. > If you want to go down that route, what is your reply to me saying that > SELinux cannot mediate NFS mounts - if the server is not confined using > SELinux as well? The argument is really, really moot and pointless. Yes, > unconfined actions can affect confined processes. 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. > > > That is an interesting argument, but not what we're discussing here. > > > We're arguing filesystem access mediation. > > IOW, anything that AA cannot protect against is "out of scope". An easy > > escape from any criticism. > > I'm quite sure that this reply is not AA specific as you try to make it > appear. Every time we've noted an issue with AA, the answer has been that it is out of scope. Yet the public documentation for AA misrepresents the situation and its comparisons with SELinux conveniently ignore its limitations. > > > Yes. Your use case is different than mine. > > My use case is being able to protect data reliably. Yours? > > I want to restrict certain possibly untrusted applications and > network-facing services from accessing certain file patterns, because as > a user and admin, that's the mindset I'm used to. I might be interested > in mediating other channels too, but the files are what I really care > about. I'm inclined to trust the other processes. > > 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. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
