Thanks for the response. I understand and agree with your points. Your approach is spot on for a newly designed system, but in my opinion not for customers where connman is added late. The difficulty is that we are adding connman (connectivity) for a customer with an existing HMI that want to add some connectivity apps. This unfortunately gives us little to no control over the QT/HTML5 applications design as it is already established. We might be able to get them to make a call to identify the application so we can properly setup session via some proxy, but having them run as a specific user, or group for each app is something less palatable to them. I am currently in the process of better understanding what the connman can give us in the way of sessions so I can evaluate what we can and cannot do for both the connman and the customer applications. Thanks again.
Tysen On Thu, Nov 7, 2013 at 2:38 AM, Patrik Flykt <[email protected]>wrote: > > Hi, > > On Wed, 2013-11-06 at 13:19 -0500, Tysen Moore wrote: > > > We have a situation where we think we may need to proxy the session > > creation for the applications so we can provide extended filtering > > capabilities, etc. The session proxy is planned to play an > administrative > > role for the applications to further abstract session creation among > other > > things. > > Interesting. Why is it hard for the applications to request a Session > over D-Bus as they also will be opening sockets and do other networking > related actions? What would the use case be where a proxy entity looks > like a viable solution? > > > However, it seems if we use the session-policy plug-in we have no > > way to proxy the session creation for an application because the uid is > not > > optionally specified over a CreateSession DBus API but rather requested > > from DBus daemon itself. I wasn't sure if the design was to provide > > security by making use of the DBus uid API or if this was somewhat > > unintended. > > As the session API is intended as a notification mechanism to notify and > wake up applications when a network connection is available, the easiest > reliable way of figuring out the UID is to ask it from D-Bus. > > > It also seems to force clients onto the system bus, was this > > also intended? > > With ConnMan being a system daemon it only uses the system bus. Session > buses are user specific entities and are thus out of question. > > > What I am pondering is the ability to specify the uid or gid within the > > CreateSession API. This uid/gid then would become part of the > > "creation_data" that gets passed to the plug-in's create handler > > (policy_local_create). This would then allow the plug-in to use the user > > specified uid/gid instead of the DBus daemon uid/gid. > > The security implications of believing UID numbers supplied over D-Bus > are quite obvious. The number needs to be checked by a policy plugin > with respect to the sender's UID obtained from D-Bus itself. I'd bet > most of the session policy plugins would miss this, thereby opening up > an unneeded security hole. > > > If security is the > > main concern for the original implementation, then a couple possibilities > > come to mind: > > 1. The Create/DestroySession calls could be removed from the Manager > > interface and go into a new Session interface. This session interface > > could then be "locked-down" in the DBus system.conf so that only a > specific > > user, in our use case the "session proxy", could access that interface. > It > > would then be the task of the session proxy to authenticate the client > > application if needed. > > The Session API is intended to be used by applications that will receive > notifications in response. As the Session objects are created with > variable path names, the creation and destruction need to happen in a > well-known location on D-Bus, therefore the Manager API is currently > used. > > Any platform or system is always free to figure out a suitable set of > D-Bus rules needed, so this is anyway a "distro" issue. > > > 2. The CreateSession would accept a uid or gid "override" value only > from a > > specified uid/gid that is configured in the connman config file. > > See above, it's more complicated to try to follow a supplied uid/gid > field where the first step is to check against the sender's real uid/gid > before making a decision on the supplied field. Also other ids like GID > and SELinux contexts need the same kind of cheking. > > > Do any of these suggestions to my problem seem reasonable and/or match > with > > the design intent/direction of the connman? Or, is there a better way to > > solve this problem, I am still very new to the connman. With my current > > understanding of the connman it seems like the ability to proxy session > > creation and management outside of the applications may have some > > benefit--at least in our current system. > > I don't really see any benefits of having Sessions created through a > proxy. The Session creation replies are sent back to the proxy object, > which then responds back to the original application. ConnMan needs to > do the policy check and so does the proxy entity. Thus you'll end up > with two RPC calls and two policy checks. It's quite a waste of > resources with no benefit. It is much easier and efficient to write a > proper policy plugin for ConnMan and have the logic in there instead of > in a separate proxy entity. > > A well-behaving (socket) middleware abstraction such as Qt could > implement ConnMan Session support for its connectivity notifications, so > could GNetworkMonitor if it had persistent objects. This approach would > simply work, as the applications use for example the Qt layer as a > library and thus get their UIDs, GIDs and SELinux contexts correctly set > at exec(). Any mappings from one identifier to another means the system > architecture is most likely wrong. > > > Cheers, > > Patrik > _______________________________________________ > connman mailing list > [email protected] > https://lists.connman.net/mailman/listinfo/connman > _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
