Hi, > The exception of the tracee not being able to block unconfined is special and > there may be a flag in the future to allow the tracee profile rule to > override that.
This sounds like a sharp double-edged sword to me: allowing tracees to block introspection sound slightly rootkit-ish. On the other hand, when a host is (mostly) constrained then the policies should be under full control and carefully designed for correct setup ... famous last words. Here, AppArmor has its special architectural treat in that it breaks up the (typically?) single rule "tracer process (subject) traces tracee process (object)" into two AND'ed rules: - "tracer process (subject) traces tracee process (object)" - AND "tracee process (object) tacedby tracer process (object)". Personally, I find this unexpected and I'm still struggling to see usecases beyond modularization. The downside to me is the "unexpectedness", as the second half of the combined rules basically means "object passive-action subject" which inverses the common "subject action object" rule mindset. > I should note that we can use different terminology if its easier. The tracer > profile, is the subject type and the tracee profile is the object type. The > profile it self is the same it just switches role depending on whether it is > the task doing the tracing. As for /proc/ accesses, the task is always in the > subject role. To me, the "tracer/tracee" terminology is fine, as it maps the high abstraction of "subject" and "object" to concrete roles. I was asking primarily to make sure that I'm not missing something else important to "tracer/tracee" beyond being a concrete expression of "subject/object". This doesn't seem to be the case here. > you are right the only carte blanche is now the same thread group, I would > have to dig way back into history to say anymore. That statement certainly > could be tightened up. Elixir :) ... I immediately assumed the same (things DO have reasons) and had checked back to 2.6something but it seems to be present now for a long time, but then, AppArmor is also around for quite some time now. Anyway, that's lost in the mists of time and due for "(Kernel) Time Team" to excavate in a three-day spree... I'm glad you can confirm here, because if the old behavior would still be present, it would have quite some ramifications on, say, using AppArmor with containers. Of course, I tried in a simple busybox container with "--pid host", and was dissatisfied that it doesn't work as advertised :) to read and kill root, but then also relieved. With best regards, Harald -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
