qmi-proxy running as non-root user

[Ben Chan]

cc Prathmesh


On Tue, Jan 14, 2014 at 12:28 AM, Aleksander Morgado <
aleksander at aleksander.es> wrote:

> >>> Letting the clients check whether they are allowed to open the port
> >>> before trying to use the proxy is not a good idea; you would be
> >>> relying on well-behaved clients, but that is not secure. One issue
> >>> currently is that the proxy is launched by the first process that
> >>> wants to use the port, and therefore inherits all its
> >>> uid/pid/environment. Limiting the usage to the root user was just a
> >>> quick way to make it safe, but if we can really do a proper
> >>> per-file-access-control that is secure, I'm all for it. Although not
> >>> sure exactly how that would be.
> >>>
> >>
> >> I was not suggesting that the client should perform the check. The
> qmi-proxy
> >> should probably check if a client can access the device in incoming_cb,
> but
> >> that seems tricky as you said (unless it uses a helper to impersonate
> the
> >> client credential and perform the file permissions check). That's why
> I'm
> >> looking for a compilation option to disable the check in qmi-proxy and
> have
> >> a sandbox to constrain the ModemManagr/qmi-proxy process.
> >
> > If qmi-proxy is granted the CAP_SETUID capability, it could seteuid()
> > and then check if the client process can access the device file.
> >
>
> That's an approach we could try.
>
> > If we need finer control over permissions, would it make sense to have
> > qmi-proxy running as a DBus service, such that access control can be
> > specified in the DBus configuration file. I'm not sure if the DBus
> > overheads (e.g. latency) would be too much.
> >
>
> I also thought about this, truth be told... There will be more
> overhead, but it's not like we are passing thousands of QMI messages
> around, so maybe it's a nice add-on.
>
> > Perhaps a simpler (near-term) solution to accept a client process that
> > runs as the same user as the qmi-proxy?
>
> I'm sure we're not the first ones facing this same issue; we should
> try to see what others have done in a similar situation. Anyway, if it
> is just for the sake of being able to setup test environments, I would
> be happy with a new configure option to disable the root check, as
> long as it is not default.
>
> --
> Aleksander
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libqmi-devel/attachments/20140903/95a8ba46/attachment.html>