[apparmor] DBus rule syntax for subject and peer components

[Jamie Strandboge]

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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130612/499142b4/attachment-0001.pgp>