On 06/12/2013 01:40 PM, Steve Beattie wrote: > On Tue, Jun 11, 2013 at 02:41:03PM -0700, Tyler Hicks wrote: >>> * Proposal 3 - Grouping of subject and peer address components >>> >>> Based on Steve's suggestion[4] and refined by Jamie[5]. It groups the >>> connection attributes together based on whether it is the subject's >>> connection >>> attributes or the peer's. >>> >>> dbus [<bus>] [subj=(<subject>)] [acquire], >>> dbus [<bus>] [subj=(<subject>)] [peer=(<peer>)] [send | receive], >>> ... >> I like Proposal 3 the best. I'd also be fine with dropping the '=' chars >> from "peer=()" and "subj=()". > > Is there a reason to go all 1970s creat() or should we spell out > 'subject' entirely? I mean, other than using 'subj' makes rules line > up in vertical columns nicely. >
I proposed subj= simply because it seemed to look cleaner with peer=.
subject= is fine by me.
>> Proposal 3 seems to be the clear leader at this point. Speak up soon if
>> you're not a fan of Proposal 3.
>>
>> As a side note, one thing that I'm not real happy about is the asymmetry
>> of send and receive rules.
>>
>> When writing a send rule, it doesn't make sense to have a path,
>> interface, or member specified in the subject address grouping.
>>
>> When writing a receive rule, it doesn't make sense to have a path,
>> interface, or member specified in the peer address grouping.
>>
>> This is because you simply send a message through your connection, which
>> only consists of a connection name and a connection label. When you
>> receive, you receive messages according to the path, interface, and
>> member.
>>
>> So, a rule like this wouldn't really translate to anything that made
>> sense:
>>
>> dbus bus=session subj=(path=/org/gnome/ScreenSaver
>> interface=org.gnome.ScreenSaver)
>> peer=(path=/com/canonical/indicator/session/session
>> interface=com.canonical.indicator.session) (send receive),
>>
>> But these two rules do makes sens:
>>
>> dbus bus=session subj=(path=/org/gnome/ScreenSaver
>> interface=org.gnome.ScreenSaver) receive,
>> dbus bus=session peer=(path=/com/canonical/indicator/session/session
>> interface=com.canonical.indicator.session) send,
>>
>> If we distill that down a little bit, it means that the only subj
>> conditionals that make sense with send are name and label and the only
>> peer conditionals that make sense with receive are name and label.
>
>> It seems like we should be able use that to come up with a syntax that
>> is simpler, but I haven't been able to think of one.
>
> Are there ever situations where one would write {send,receive} for
> the same set of paths/interfaces/dests, that isn't merely a case of
> being sloppy/lazy?
>
AIUI, no, the other end of the connection is always of the form :X.YYY
so it should never match (please correct me if I am wrong).
> You *could* make the argument that, since you would only ever specify
> a peer or a subj in a rule, you wouldn't need to specify either and
> the context would let you distinguish. My fear is that the implicit
> nature of whether you are referring to the subject's address or the
> peer's would be confusing to rule writers.
>
So a send is always for a peer and a receive for a subj so we could drop
the peer= and subj= altogether? Personally, I don't like this for the
reasons you mention and it is inconsistent with other IPC, like in your
later example:
tcp send subj=(iface=tun* port=7979) peer=(addr=192.168.2.0/24 port=22),
I think it probably makes sense for the parser to warn/error for dbus
rules that don't make sense.
> Also, something to keep in mind is that, while dbus uses what you
> might consider an anonymous endpoint for one end of each connection,
> other forms of IPC won't necessarily do so, e.g. networking. We'd
> ideally like to have a consistent language pattern across the IPC
> mechanisms we mediate, such that there's not too much cognitive
> dissonance when writing rules for multiple types of IPC.
+1
>
> So while I could kind of see reversing the permission and modifier
> ordering to be something like:
>
> dbus bus=session acquire dest=org.gnome.ScreenSaver,
> dbus bus=session receive subj=(path=/org/gnome/ScreenSaver
> interface=org.gnome.ScreenSaver),
> dbus bus=session send peer=(path=/com/canonical/indicator/session/session
> interface=com.canonical.indicator.session),
>
> or even:
>
> dbus acquire bus=session dest=org.gnome.ScreenSaver,
> dbus receive bus=session subj=(path=/org/gnome/ScreenSaver
> interface=org.gnome.ScreenSaver),
> dbus send bus=session
> peer=(path=/com/canonical/indicator/session/session
> interface=com.canonical.indicator.session),
>
> would it make it too confusing for e.g.:
>
> # in this profile, allow ssh portforwarding via port 7979 on a tun
> # device to the ssh port of a class rage of hosts
> tcp send subj=(iface=tun* port=7979) peer=(addr=192.168.2.0/24 port=22),
>
> (I guess with this ordering I start to see why people have wanted
> to have the file permissions first before file paths, as the
> send/receive/acquire bits get lost visually, at least without syntax
> highlighting.)
>
I don't think this is confusing at all. It is a bit inconsistent with
file permissions, but it might be worth it.
--
Jamie Strandboge http://www.ubuntu.com/
signature.asc
Description: OpenPGP digital signature
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
