deny send_destination policy also blocking signals ?

Sjoerd Simons sjoerd at luon.net
Thu Jun 22 16:05:29 PDT 2006


On Thu, Jun 22, 2006 at 06:06:06PM -0400, Havoc Pennington wrote:
> 
> 
> Sjoerd Simons wrote:
> >Hi,
> >
> >  When debugging a problem with NetworkManager on debian (or rather why a
> >  certian work-around fixed the problem) we encountered a strange issue.
> >
> >  As most of you will know NM listens on the system bus to hal signal to 
> >  detect
> >  device additions and removals. For some reason it never got those signals
> >  though. Now NM also registers a service on the system bus and the policy 
> >  for
> >  that service is to only allow a certain set of users to send messages to 
> >  it
> >  (depending on your distribution)
> >  
> >  Now it seems that the policy for send_destination=<network manager 
> >  service>
> >  is also applied to signals coming from hal (which don't have a specific 
> >  destination)..  Which is kinda weird and unwanted imho..
> >
> 
> If you have <deny send_destination="foo"/> I think you could just add 
> after it <allow send_destination="foo" send_type="signal"/> to punch 
> signals through the rule.
> 
> This kind of defeats the point of the security policy though; there's 
> nothing necessarily more secure about signals than about method calls.
> So if it's OK it might also be OK to just drop the policy. You would 
> need to then audit NM to be sure it does not trust method callers / 
> signal emitters.
> 
> It is probably more correct to do
> <allow
>    receive_sender="whatever bus name hal owns"
>    send_destination="whatever network manager owns"/>
> 
> which would allow through only signals from HAL, instead of allowing any 
> user to send any signal to NM.

We're currently allowing everything from the hal user, but just signals from
the hal user would probably be even better. (So hal can't reconfigure the
network :)

I've did some little more testing to get the semantics clear for myself, so for
signals that don't have an explicit destination basically all destinations
match (as long as their applicable to the program). 

So say we have something like this (and the program owns those 2 names): 
   <deny send_destination="my name 0">
  <allow send_destination="my name 1"> 

Then methods/signals to "my name 1" are allowed, but also signals without an
explicit destination. But if those two rules would be swapped signals without
an explicit destination would be denied. Which is a side-effect i didn't
expect.

  Sjoerd
-- 
There's no sense in being precise when you don't even know what you're talking
about.
		-- John von Neumann


More information about the dbus mailing list