On 05/09/2013 02:59 PM, Tyler Hicks wrote: > On 2013-05-09 14:51:38, John Johansen wrote: >> On 05/09/2013 02:39 PM, Tyler Hicks wrote: >>> On 2013-05-09 14:30:32, John Johansen wrote: >>>> On 05/09/2013 02:13 PM, Tyler Hicks wrote: >>>>> On 2013-05-09 14:04:20, Seth Arnold wrote: >>>>>> On Thu, May 09, 2013 at 01:45:04PM -0700, Tyler Hicks wrote: >>>>>>> I think that we're mostly ok. We just need to think about it a little >>>>>>> differently. Here's the current syntax: >>>>>>> >>>>>>> DBUS RULE = [ 'audit' ] [ 'deny' ] 'dbus' [ DBUS BUS ] [ ( DBUS LOCAL >>>>>>> CONDITIONS | -> DBUS REMOTE CONDITIONS ) ] [ DBUS ACCESS EXPRESSION ] >>>>>>> >>>>>> >>>>>> [ ... ] >>>>>> >>>>>>> >>>>>>> For example, to profile an application that acquires the well known name >>>>>>> com.example.service on the session bus and exports the ExampleMethod >>>>>>> method on the com.example.service interface, this would be what the dbus >>>>>>> portion of the service's profile looks like: >>>>>>> >>>>>>> dbus bus=session -> name=org.freedesktop.DBus >>>>>>> path=/org/freedesktop/DBus interface=org.freedesktop.DBus send, >>>>>>> dbus bus=session name=com.example.service acquire, >>>>>>> dbus bus=session -> name=com.example.service >>>>>>> path=/com/example/service interface=com.example.service >>>>>>> member=ExampleMethod receive, >>>>>>> >>>>>> >>>>>> [ ... ] >>>>>> >>>>>>> >>>>>>> The third rule allows messages to be sent from *any* connection to the >>>>>>> service. Note that the even though com.example.service is owned by the >>>>>>> application that we're profiling, it's address is specified in the >>>>>>> <DBUS REMOTE CONDITIONS>. I think that's acceptable. >>>>>> >>>>>> If the application acquired the interface and the application exports >>>>>> the method, why are those details placed on the 'peer' side of the >>>>>> arrow? I'm very confused here. :) >>>>> >>>>> I agree that if you think of it in terms of 'peer', it doesn't make >>>>> sense. >>>>> >>>>> For the arrow to make sense, we'd need to think of the right side of the >>>>> arrow as the destination of the message. >>>>> >>>>> Take this rule for example: >>>>> >>>>> dbus bus=session -> name=com.example.service path=/com/example/service >>>>> interface=com.example.service receive, >>>>> >>>>> If we adjust our thinking a little it could mean, "a message that flows >>>>> FROM anywhere TO com.example.service can be received under the >>>>> current profile." >>>>> >>>> maybe its just me, I see this as getting into the old to/from problem that >>>> netdomain had >>> >>> Mind explaining this a little more? I don't see netdomain in >>> apparmor.d(5) and have no idea what that problem may have been. :) >>> >> long ago there was a network extension to apparmor that did horrible >> things. It would make kernel devs cry and shake out of shear terror. >> It died on the vine because the hacks where unmaintainable, and >> would result in the kernel community hunting you down and killing you >> if you tried to submit it. :) >> >> Anyways its syntax tried to take a message flow approach with natural >> language and it ended up being confusing >> >> it went something like >> tcp receive from blah, >> tcp send to blah, >> >> tcp send from blah to blah, >> tcp send,receive from blah to blah, >> >> I don't remember the full syntax. But to/from would switch meaning based >> on whether send or receive was used and it had another problem I failing >> to remember. >> >> that is not to say your proposed syntax does this but it is flipping >> what I expect from -> and causing me to be confused. >> >> that is -> means one thing on send and other on receive > > Funny, because I see the changes that I proposed making -> mean the same > thing always. > it depends how you look at it. To me it is changing the meaning of -> of course I am now convinced that -> is just wrong and we need different syntax, because -> just seems to have too many potential different interpretations that could cause confusion
> I see it as meaning that if a message is flowing from the dbus connection > on the left to the dbus connection on the right, then here's the > permission that is allowed. > > Yes, acquire is confusing if you think about it like that. :/ > :) > > Unfortunately, I think that we're always going to have the problem of > someone interpreting complex rules like this a little differently than > what someone else may interpret them. We'll just have to pick our poison > (but hopefully one that isn't too potent) and then be explicit in the > documentation. > yep, I agree there people model/conceptualize things differently and a syntax that doesn't match what is expected is confusing. So we aren't going to please everyone -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
