On 06/12/2013 01:28 PM, Jamie Strandboge wrote: > 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. > yes where there is a specified component that makes the rule ambiguous with respect to a none specified component we should throw a semantic error
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
