On 06/12/2013 02:13 PM, Tyler Hicks wrote: > On 2013-06-11 23:30:58, John Johansen wrote: >> On 06/11/2013 03:04 PM, Jamie Strandboge wrote: >>> On 06/11/2013 04:41 PM, Tyler Hicks wrote: >>> >>> ... >>> >>>> 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. >>>> >>>> This isn't a blocker and we shouldn't spend much time on it, but if a >>>> light bulb flipped on for anyone while reading that, I'd love to hear >>>> their idea. >>>> >>> >>> I see what you are saying but we need all of subj with receive and all >>> of peer with send, so trying to come up with a syntax to accommodate >>> subj-only, peer-only and a reduced subj/peer seems rather complicated (I >>> couldn't come up with something else either). The parser is in a >>> position to warn/fail on subj/peer combinations that don't make sense >>> though-- maybe that is a reasonable compromise? >>> >> >> so I agree that dealing with this asymmetry at the syntax level is the >> wrong place. It will needlessly complicate the syntax, and is the type >> of check that is handled by a semantic check. > > I'm fine with that, but I'd like to be clear on what we will allow. > > For "complex" rules, I'd like to propose that we require one and only > one access. No implied accesses, no combined accesses. By complex rules, > I'm talking about anything that includes a subj or peer conditional. > > For example, this rule is ambiguous without an explicit access: > > dbus bus=session subj=(path=/org/gnome/ScreenSaver > interface=org.gnome.ScreenSaver), > > and adding in a combined access also makes it ambiguous: > > dbus bus=session subj=(path=/org/gnome/ScreenSaver > interface=org.gnome.ScreenSaver) (send receive), > > the only valid form of the rule is with the receive access: > > dbus bus=session subj=(path=/org/gnome/ScreenSaver > interface=org.gnome.ScreenSaver) receive, > > > Sure, there are conditionals that work with implied accesses: > > dbus bus=session subj=(name=org.gnome.ScreenSaver), > > but does that mean (send receive) or (send receive acquire)? It is still > ambiguous. > > That rule also makes sense with a combined acccess: > > dbus bus=session subj=(name=org.gnome.ScreenSaver) (acquire receive), > > But now documentation becomes convoluted because you have situations > where combined accesses work with some address conditionals but not all > of them. > > > So the only rules that could contain implied or combined accesses would > be rules in this basic form: > > dbus [<bus>] [<access>], > > What do you think? I think that it reduces complexity and makes policy > easier to read, at the expense of making policy a few lines longer. >
I'm inclined to agree with you, but want to here from others. -- Jamie Strandboge http://www.ubuntu.com/
signature.asc
Description: OpenPGP digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
