[apparmor] IPC syntax - again

[Steve Beattie]

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.
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?

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]

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
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.

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
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.

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.

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.

[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?

-- 
Steve Beattie
<sbeattie at ubuntu.com>
http://NxNW.org/~steve/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130702/4f2dc6e2/attachment.pgp>