On 2013-05-09 15:08:35, John Johansen wrote: > 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
The change of ->'s meaning first clicked in my head when I was moving my regression tests over to the -> notation. It just made sense to me all of a sudden. However, it isn't clicking for jdstrand or sarnold and you're now convinced that -> is wrong. So, lets drop my proposed change of ->'s meaning from the running and focus on something different (like jdstrand's suggestion of moving the permissions closer to the subject). Tyler > > > 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 > > > >
signature.asc
Description: Digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
