On 07/03/2013 12:40 AM, John Johansen wrote: > On 07/02/2013 11:45 PM, Steve Beattie wrote: >> I'm coming into this thread a bit late, so my apologies if I'm being >> truly dense here. >> >> On Mon, Jul 01, 2013 at 09:08:23PM -0700, John Johansen wrote: >>> On 07/01/2013 05:35 PM, Tyler Hicks wrote: >>>> What about only allowing a single permission per rule? That would ensure >>>> that the rule is clearly written in the context of that permission and >>>> there is no confusion. >>>> >>> Does it? >>> network bind unix address=\0foo, >>> >>> well this is clear, as bind is a local address only operation >>> >>> network send unix address=\0foo, >>> is that send from, or send to? Like send to as well we care about who >>> we are sending to and not the port/address we are sending from. >>> Again this would be some of the argument against "pairing", as most >>> of the time I might just care about the type of communication and who >>> I am sending too. >>> >>> network receive unix address=\0foo, >>> >>> This one is a little harder as the receive side is the case where I see >>> pairing as most useful. I may want to say I am only receive message on >>> my bound address \0foo from X >> >> With the implicit labeling scheme, labels and policies are conflated. > pfft, I beg to differ. Labels are labels, policy is policy. Every label > can have a policy associated with it. Its treating them as different > that is confusing :) Sorry I spent a lot of time fiddling and trying to > get things to work the other way, and abolishing the distinction just > cleared things up. >
So just to clarify this in a slightly less snarky way. Our policy is written from the pov of the subject, so subject labeling is implied. Doing so makes it natural to think there is a type split between the subject labeling and object labeling and this is what DTE does. TE does not naturally have a split between domain and object type, though some TE systems have made the distinction, because policy is written at a global level. The problem with a subject, object split is that objects are used as subjects in several places. This isn't a problem for TE that doesn't make that distinction. DTE (ignoring some of its other unique changes) is just a way of splitting up TE rules, so they are grouped by subject type. This allows for reducing the size of the table that needs to be searched for any given subject. And allows for compressing the table as the subject type is now stored implicitly. Notice this mapping does not actually require a conceptual distinction between domain types and object types. We have the split because of an implementation detail. The DTE types and rules can just as easily be mapped back to a TE table with subject, object, perm, with no distinction between the subject and object type. In a sense that is all we are doing. We threw away the distinction, and now objects can act as subjects (which is required in the Linux kernel) but we still keep the DTE style of encoding the rules on the type. -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
