Re: DBus - Sessionbus rights
On Sun, 2008-04-06 at 15:32 -0400, Michael Stone wrote: On Sun, Apr 06, 2008 at 01:11:55AM -0400, Polychronis Ypodimatopoulos wrote: The SystemBus is used for communication between processes that belong to different users. By default, /etc/dbus-1/system.conf says ...Deny everything then punch holes Why do we forbid the default user (olpc) by default from advertising processes under a well known name? Simple inertia combined with the fact that the authors of most processes running as uid 500 have considered their software to be session software rather than system software. If you feel differently, please consider suggesting a policy that you think is a better fit for our dvision of responsibility. (Though take into account the fact that we are presently trying to get Sugar and its dependencies running on non-OLPC systems.) What's wrong with user processes making their presence known on SystemBus? My suspicion is that it's an anti-spoofing measure, but that's merely a guess. Have you considered asking on one of the dbus mailing lists? 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. In any case the session bus is what you want to use to create services other apps (in the session) can use. I don't know if OLPC's security model allows you to write to the local autostart directory but if it did you could even use that facility. I would suggest OLPC however restrict names to the application's own namespace and reserve certain namespaces (like org.laptop) for signed bundles. -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DBus - Sessionbus rights
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? 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.| thx p. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DBus - Sessionbus rights
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 [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DBus - Sessionbus rights
John (J5) Palmieri wrote: I can't think of a reason to want a system process invoking methods on a user process. Well, in my case, the system process is the only one having access to the network and provides network connections and events to all user processes. Sending signals to user processes is a bad choice (although this is what I'm doing right now), because it breaks the privacy between user processes. All is not lost. User processes do not necessarily have to allocate a well known name, as long as it is possible to export a method from a numeric bus address. Is this possible? Example? Thx, Pol ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DBus - Sessionbus rights
On Mon, 2008-04-07 at 11:43 -0400, Polychronis Ypodimatopoulos wrote: John (J5) Palmieri wrote: I can't think of a reason to want a system process invoking methods on a user process. Well, in my case, the system process is the only one having access to the network and provides network connections and events to all user processes. Sending signals to user processes is a bad choice (although this is what I'm doing right now), because it breaks the privacy between user processes. All is not lost. User processes do not necessarily have to allocate a well known name, as long as it is possible to export a method from a numeric bus address. Is this possible? Example? No, this is part of the security profile. Signals can be sent to specific addresses though so as to not break privacy. That I would ask on the D-Bus list. I can't remember what the syntax for that is in python. As for getting network connections user processes should be able to do that. If you are in need of secure ports I would strongly recommend working with the core OLPC developers to make sure it isn't bypassing the security framework. -- John (J5) Palmieri [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DBus - Sessionbus rights
On Sun, Apr 06, 2008 at 01:11:55AM -0400, Polychronis Ypodimatopoulos wrote: The SystemBus is used for communication between processes that belong to different users. By default, /etc/dbus-1/system.conf says ...Deny everything then punch holes Why do we forbid the default user (olpc) by default from advertising processes under a well known name? Simple inertia combined with the fact that the authors of most processes running as uid 500 have considered their software to be session software rather than system software. If you feel differently, please consider suggesting a policy that you think is a better fit for our dvision of responsibility. (Though take into account the fact that we are presently trying to get Sugar and its dependencies running on non-OLPC systems.) What's wrong with user processes making their presence known on SystemBus? My suspicion is that it's an anti-spoofing measure, but that's merely a guess. Have you considered asking on one of the dbus mailing lists? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
DBus - Sessionbus rights
I've been fiddling with DBus quite a bit lately and I don't really understand its default security policy. The SystemBus is used for communication between processes that belong to different users. By default, /etc/dbus-1/system.conf says ...Deny everything then punch holes Why do we forbid the default user (olpc) by default from advertising processes under a well known name? What's wrong with user processes making their presence known on SystemBus? -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
