[apparmor] IPC syntax - again

[John Johansen]

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.

> Why, if that's the approach we're going with, wouldn't you use label=X
> here, if you only want to receive messages on \0foo from X?
> 
why would I want to?  I know the address I want to interact with why
do you want to force me to go through the pain of setting and splitting
a label?

Sure we can do that but that argument is no different than saying why
don't you label a file instead of mediating it based on its pathname?
Its easier for the policy author. The fact is, all that using addresses,
and names does is move the labeling work into the compiler and back
end and let the author deal with objects in terms they are comfortable
with. So if a label is the right solution great, if not great

Now as to the X label question, here is another reason. Our labels don't
dominate so there is always a cross check, so not only do I need to
have the permissions to talk to X, X must have the permission to talk
to me.  This is no better or worse than using the address it just
changes the set of semantic information that is carried by the rule.

> Really, though, if I were writing the policy for it, I'd probably
> want to assign an explicit label to the \0foo socket and grant access
> to that socket+label to those policies that I want talking via that
> socket, particularly if this is a daemon service I'm providing (think
> pulseaudio). [0]
> 
Again if that makes sense for you great. Please feel free to label
the file system as well.


> Also, while I'm not convinced one or the other here, I think using a
> unix(7) abstract socket doesn't really help your example because there
> is only one "address"; if I want to talk to your process via it, I need
hehe you noticed :) In fact I didn't do a more complicated example
because of that. I was just trying to say, that the case where I have
bound an address is the one that I find most compelling for pairing.

> to use the same name/address for the socket. Is there another local
> IPC mechanism where the endpoints are distinct and predictably named?
> Because that would likely be a significantly more compelling example.
> 
chose almost any of networking address families, binder can do so.
Most of the others don't. Even with networking we often don't have
reliable addresses, except for servers. Everyone else is getting
an address from DHCP

> To me, and this may be me misunderstanding what is meant by "pairing"
> in this discussion, but pairing is only useful if the communication
> medium has two distinct endpoints that are distinctly known/predictable
> (dbus messages have two address endpoints, but one endpoint is never
not so. Just most useful. You could also pair a local address to
a remote label (again address is just a way of deriving a label).

> reliably predictable). This is why IMHO it can be useful in non-local
> networking (e.g. I only want to allow hosts on that class C network
> to talk to my webserver via local ports 80 and 443 *and* implicitly I
> want to not allow any other policy to bind to those ports and prevent
> my webserver from binding to other ports like 22), but I'm not seeing
> another multiple endpoint IPC mechanism where that's appropriate,
> and even for common network protocol usage, because one endpoint is
> frequently anonymous/unpredictable, specifying both endpoints is of
> limited use there as well. But I grant that I am by no means am even
> reasonably knowledgeable about the various forms of IPC available.
> 
heh me neither.

> Networking also falls under the rubric that, in the common case, we
> can't assume/discern a policy or label that is applied to the peer
> endpoint's process.
> 
not always. If its off machine likely but there are still several
cases where you can. Machine local, set of reliable lan addresses,
ipsec.

> But maybe I'm misunderstanding what you mean by pairing, and are
> instead referring to any attribute of the peer, including label/policy,
> pid, uid instead of just message endpoint addresses.
> 
yes its making a rule conditional on both endpoints data instead of
from just one.

So if we don't have pairing we essentially have two sets of rules.
Check against the local endpoint, and then if everything works out
check against the remote endpoint.  We still end up checking both
but there is no way of tying the two together to get a more complex
condition.

In the case where we are just dealing with labels to make the decision
then pairing somewhat implicit in that its the local subject label
to the peer.

> [0] There's a question here about how unconfined should be handled;
>     would an explicit deny rule be needed to prevent unconfined from
>     communicating via \0foo in either approach?
> 
No, our labels don't dominate so while unconfined is free to communicate
with anyone, X must be allowed to communicate with unconfined before
said communication is allowed.