On 06/12/2013 01:42 PM, Jamie Strandboge wrote:
> On 06/12/2013 01:40 PM, Steve Beattie wrote:
>> On Tue, Jun 11, 2013 at 02:41:03PM -0700, Tyler Hicks wrote:
<<snip>>
>>> 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).
>
hrmmm this doesn't have to be true, however the dbus code may be always
giving as the dynamic address in these cases.
That is nothing in the dbus spec prevents you from sending on from
a socket that has a well known address bound to it. And the spec doesn't
specify which will be used.
I believe currently we have always seen :X.YYY but I don't recall it
as required by the spec.
>> 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.
>
yes
>> 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
>
+1, wasn't this desire the thing that started this whole mess? :)
>>
>> 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.
>
Actually it isn't file permissions currently allow for both. That is
you can write.
/foo rw,
rw /foo,
and link is even special cased so that if you do a leading l you can
specify the pair link rule.
/foo l,
l /foo,
l /foo -> /bar,
link /foo -> /bar,
or with the file keyword
file l /foo,
file rw /foo,
This was added for apparmor 2.3 because people kept asking for leading
permissions but we never seemed to switch and then I heard enough complaints
about it that I nearly ripped out the support.
You can also think of some of the other rules keywords as being leading perm
change_profile /bin/foo -> mysnazyprofile,
which just happens to grant the change_profile permission.
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
