[apparmor] IPC syntax - again

[Tyler Hicks]

I had to trim this down and focus on one section that has been bothering
me. It is based upon the idea that we can do away with pairing. While I
mostly agree, DBus intricacies were making it difficult for me to
understand what exactly we would be doing away with.

On 2013-06-26 11:00:52, John Johansen wrote:

<snip>

> It is confusing to specify these local permissions in a rule that also
> specifies a peer address. That is to say it does not make a lot of sense
> to specify bind/acquire et al in rules with a peer address.
> 
> So a profile will require ipc rules without peer addresses. In this
> case specifying the subject is redundant.  Though it may be worth doing
> for consistancy, if we have rules that specify both subject and peer at
> the same time.
> 
> For rules that specify a peer address the major permissions involved are
> read/write/send/receive. In this case the permission means that the
> subject can read FROM the peer, write TO the peer.
> 
> If we also throw in a subject address the meaning of the permission
>   r subject=(addres=foo) peer=(address=bar),
> means read on subject address=foo from peer address=bar.
> 
> This pairs the local address/handle to a specific peer address handle.
> 
> The question is how useful is this compared to not allowing pairing in
> rules. That is the rule address subject/peer is infered from the
> permissions on the rule.
> 
> eg. which is easier to understand
>   aquire subject=(address=foo),
>   rw subject=(address=foo) peer=(address=bar),
> 
> or
>   aquire address=foo,
>   rw address=bar,
> 
> the second case can simplify the syntax because it doesn't care about
> tying the comminication with the peer to a specific address on the subject.
> Admittedly we can simplify the rules from the pair syntax example to
> have the same semantics as the 2nd example.
>   aquire subject=(address=foo),
>   rw peer=(address=bar),
>   
> and it is not a lot more complicated. The question is, is this small
> increase in syntax complexity worth it for that extra restrictions it
> can give us.
> 
> So where is pairing possible?
> - It is not reasonable possible for dbus rules

After speaking with John in IRC, the bullet point above is too strongly
worded. Pairing is possible for DBus rules, we're just trying to determine if
it is worth the complexity.

IIUC, taking away pairing would affect two types of rules:

 1. send/receive rules where you want to specify the subject's connection name
    - You would only do this if a process ownls multiple DBus connection names
      and you want to allow certain operations on one, but not the other
 2. receive rules where you want to specify the local address attributes (path,
    interface, or member)
    - You would only do this if you want to divvy up access to DBus objects
      exported by a single process
      + Maybe you don't want to grant one peer access to a certain method
      + Maybe the subject has multiple, somewhat unrelated interfaces that
        shouldn't all be accessible by a peer
      + Maybe the subject creates a new path for each logged in user and you
        want to leverage AppArmor user conditionals (future work)

I think #1 has little importance and we won't miss that level of mediation. I
think #2 has the potential to be very important and we'll need to determine if
we can do without it.


What clouds all of this is in my mind is that it really depends on one's
definition of the term "pairing". From talking with you in IRC
yesterday, your definition is "the tying of subject attributes to peer
attributes, so that both set of conditions must be true before the
permissions in the rule are granted." This is a fair definition and
aligns with what I understood it to be after reading this email.
However, I think our definition of pairing needs a little tweak.

Lets shift to signal rules and think about a hypothetical screen locker.
A session manager starts the screen locker and the screen locker *must*
stay alive even if the user accidentally runs an untrusted, unconfined
application that tries to kill it. Only the session manager should be
able to kill it. So, the screen locker's profile may look like this:

/usr/bin/screenlocker {
  signal receive kill label=/usr/bin/sessionmanager,
}

That seems sane. Pairing isn't needed. Or is it? Is the signal type
SIGKILL an attribute of the subject or the object? It doesn't really
feel like it since there are a set of well defined signals and their
names don't differ from application to application. But what exactly is
the signal type an attribute of??

Now, lets imagine that the screen locker has a DBus interface, with a
Kill method, that some other session manager uses to kill the screen
locker instead of a SIGKILL signal:

/usr/bin/screenlocker {
  signal receive kill label=/usr/bin/sessionmanager,
  dbus receive member=Kill label=/usr/bin/othersessionmanager,
}

The dbus rule feels like it is using pairing. The Kill DBus method is an
attribute that is specific to the subject and we're tying it to an
attribute of the peer (the peer's label).

So lets add another twist to the profile. The screen locker only locks.
It launches a screen saver application that displays mesmerizing 3D
pipes that rapidly grow in every direction. The screen locker must kill
the screen saver when a user presses a button or moves the mouse. It
does this over DBus by calling the screen saver's Kill method.

/usr/bin/screenlocker {
  signal receive kill label=/usr/bin/sessionmanager,
  dbus receive member=Kill label=/usr/bin/othersessionmanager,
  dbus send member=Kill label=/usr/bin/screensaver,
}

member=Kill is an attribute of the peer in the third rule, despite member=Kill
being an attribute of the subject in the second rule. Confusing, but
manageable. DBus path, interface, and member shift between being a subject or
peer attribute depending on the access (send or receive). But maybe we
shouldn't think of those attributes as being attributes of the subject
or peer. Maybe we should think of them as being attributes of the DBus
message being passed, just like the specific signal type SIGKILL is an
attribute of the signal and not an attribute of the subject sending the
signal or the peer receiving the signal. 

Long story short, I think we can do away with pairing if we adjust our
thinking a little. Certain attributes aren't subject attributes or peer
attributes, they're just attributes of the signal, message, buffer,
shared memory, etc., that is being shared over the given IPC mechanism.

Tyler
-------------- 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/20130628/3a8a984b/attachment.pgp>