On 11/29/2017 1:08 PM, Simon McVittie wrote: > I don't see why it isn't a MAC implementation. However, the comment about > not having a "real" security model seems valid. The way AppArmor is used > in practice is often more like hardening than a coherent security model: > when an app was not designed to be sandboxed, and an AppArmor profile > was added later without modifying app code, the profile rules that are > necessary to make it work are often loose enough to allow privilege > escalation, particularly for desktop apps that are typically written to > assume they have full desktop privileges.
Yup. That's a little frustrating. But I don't think people solved this particular problem for SELinux either, did they? It's a question of which transitions to allow and how the permission set changes then. I will point out that seccomp filters have the same problem: You need to know pretty much exactly what all of the libraries you include do. If you then happen to be a daemon that loads, say, PAM modules (or other kinds of modules) you suddenly end up with more calls that you need to allow and stuff crashes. I think at least debugging might have been facilitated recently rather than just killing off the program without an indication of what's wrong. That doesn't preclude daemon maintainers from writing such a policy but they have to be pretty careful not to break stuff. People always rant at Chromium because it bundles everything but such control also allows to write tight filters. Kind regards Philipp Kern