On 3/1/21 1:00 AM, [email protected] wrote: > > 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. >
Well I am not fond of the exception from a consistency pov, it was added at the request of distros. The issue comes down to to many people have profiles that end up breaking ptrace from unconfined debugging, as well blocking that was the default. It was causing a lot of bugs/issues and it was better to add the exception than have people recommending to just turn it off. > 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. > think of it as a cross check on policy consistency. AppArmor policy tends to be at least partially developed, packaged and even distributed by multiple parties. Ideally a linting tool would warn if the rules are in disagreement. >> 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 think you might have to go back to some of the work pre upstream merge. The AppArmor kernel module was rewritten a couple of times trying to get something that could be upstreamed and what eventually made it upstream was a very stripped down bare bones implementation. > 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 [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
