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
