On 2013-06-30 03:23:43, John Johansen wrote:
> On 06/28/2013 11:55 PM, John Johansen wrote:
> > On 06/28/2013 01:57 PM, Tyler Hicks wrote:
> >> 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??
> >>
> > it can be viewed as an attribute/type of the message, but more below.
> >
> >> 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
> > It is sort of, its a matter of how tightly coupled things are
> >
> >> attribute that is specific to the subject and we're tying it to an
> >> attribute of the peer (the peer's label).
> >>
> > Well its can be viewed as a property/type of the message. And yes so can
> > addresses. Addresses are really two distinct things,
> > - the address bound to that a transport can send to/or receive on
> > - a well defined property of a message that a transport uses to
> > determine where to deliver a message.
> > The address on the message really isn't a property of sender
> > (subject) unless its the return address, in which case its again
> > both a property of the subject and a property of the letter.
> >
> > So we can mediate on well defined properties of a message, or addresses.
> > The problem with addresses is whether the address is something that
> > is reliable and can be trusted for mediation.
> >
> >> 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.
> >>
> > Hehe yes,
> > Your right that it can be viewed as a property of the subject and a
> > property of the peer, or as a property of the message. I prefer to think
> > of it like this.
> >
> > Its a property of the message (like the address on a letter) that
> > the transport (the post office) matches to the address (property) of the
> > receiver. The receiver can then choose to accept/reject the message based
> > off of the well defined data (address, message type, ..). And if it accepts
> > the message (letter) it can open it and look at its contents.
> >
> > There is a pairing to a degree in this. I am not arguing against that.
> > The question I am raising rephrased in terms of the post office, is this.
> >
> > I have 2 doors in my house, a front, and a back door. I will accept
> > messages that the postman or ups deliver at the front door. At my back door
> > I will accept messages from the postman (I am not sure what he is doing
> > at the backdoor but what ever he is a good guy, buy that ups guy though is
> > shady so I yell at him to stop trespassing) or voice message from my
> > neighbour behind me (they like to yell across the yard).
> >
> > So far all of this fits into the either model.
> >
> > Now for the finer grained pairing, I will only accept letters from Joe
> > at address X, in my letter box at my front door. If Joe sends a letter
> > from a different address (he is touring europe) or if the postman tries
> > to deliver his message to the backdoor (even if its one I would accept
> > in my letter box at the front), I won't accept it.
> >
> > So is it worth the complexity to distinguish between
> > - I can receive letters from Joe at address X at any location I accept
> > letters.
> > and
> > - I will only receive letters from Joe at address X, in my front letter
> > box. This is the explicit pairing I question whether we want to
> > deal with the complexity of.
> >
> >
> >> 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.
> >>
> > I think you are right :) But I'd like to see Steve or Seth come up with
> > an example that changes my mind. I also think it is possible to extend
> > the simplified syntax to support pairing in the future but the rules
> > that used it would be a little uglier than the pairing syntax we where
> > working towards.
> >
> > But if these rules are not commonly used, I would be willing to accept
> > them being a little uglier so that the more common rule could be
> > simplified.
> >
> > I also think that generally it makes sense when you think of things in
> > terms of messages instead of shared objects that it makes sense to
> > split the rule based on the send and receive permission, that is
> > dbus send foo,
> > dbus receive bar,
> >
> Sigh so this was supposed to be send/receive and acquire permissions
> dbus send foo,
> dbus acquire bar,
>
> Now, that this is had a couple days I will criticize the none pairing
> solution.
>
> Basically the none pairing solution treats this type of communication as
> a shared object. With everything happening through the same address. As
> such it is fairly easy to get confused about what a rule means.
>
> dbus (send, receive) foo,
>
> so is foo my target or is it my local address? That is, is (send, receive)
> (send from, receive on) or is it (send to, receive from)
>
> In this case it is both sort of, in pairing syntax.
>
> dbus (send, receive) subject=(foo) peer=(foo),
> dbus (send, receive) subject=(foo),
> dbus (send, receive) peer=(foo),
>
> there are times I am okay with this and others I go ugh, I think I want
> to be able to say only
>
> dbus (send, receive) peer=(foo),
>
> I am not so concerned with local and peer addresses colliding/overlapping
> but I think it can be confusing when thinking about things in a messaging
> context to not to be able to specify whether you are talking about
> a peers address or your local address.
>
> So I am still not convinced on the value of "pairing" but I do think
> we need from a language syntax pov. Something more than
>
> dbus (send, receive) address=foo,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. I understand that file rules allow multiple permissions but IPC rules are considerably more complex, IMO. Tyler
signature.asc
Description: Digital signature
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
