DBus - Sessionbus rights

[John (J5) Palmieri]

On Mon, 2008-04-07 at 10:57 -0400, Polychronis Ypodimatopoulos wrote:
> John (J5) Palmieri wrote:
> > Luckily all mail with DBus in the header gets filtered into a single
> > folder ;)  Yes spoofing is the answer here (it is sort of like asking
> > why can't users create applications that run from /usr/bin though not
> > quite exact).  If we allowed users to grab names on the system bus that
> > aren't marked as allowed to be used by users they could spoof HAL, the
> > datastore or even the bus itself.  Since applications running as root
> > also access these services it could be used as an exploit to gain root
> > privileges.
> This sounds to me like we should not allow the user to run a server on 
> _any_ TCP port, because he may spoof an SSH/POP/DNS.... server. Instead, 
> the solution was simply to not allow the user to run servers on ports 
> lower than 1000. Even if we fixed this on the XO, my ubuntu distribution 
> has the same security policy, so maybe a bug should be filed against DBus?

Just because they are communications layers doesn't mean they have the
same security profiles.  This is not a bug. If you want some name to be
able to be owned you need to add a security policy for it.  If you want
to take your analogy further, it is akin to having to punch holes in the
firewall.  You still need access to root to do that.

> >  In any case the session bus is what you want to use to
> > create services other apps (in the session) can use. 
> >   
> In my case, user processes need to have a two-way communication with a 
> system process, like having a system process listening on a well-known 
> port and user processes register themselves with the system process, 
> stating on which port they are listening for data. The user processes 
> need not necessarily use a well-known dbus name like 'org.laptop....', 
> but I could not publish a method (from a user process) on the system bus 
> from an address like| ":0-31".|

I can't think of a reason to want a system process invoking methods on a
user process.  More likely you want the system process to send signal
and have the user process listening for them.  As long as the system
process has a security profile to allow the user process to listen for
those signals.  You can send signals to specific unique names if you
need to.  I would suggest you run your system process with a little
privileges as needed.

BTW. you can't install system processes on the OLPC unless they get into
a build or the user takes steps to install as root.  I would encourage
you to discuss your design on the list more to see if you can't figure
out a better way to run your app as the user only.

-- 
John (J5) Palmieri <johnp at redhat.com>