qmi-proxy running as non-root user

[Prathmesh Prabhu Chromium]

(All discussion here applies equally to mbim-proxy and qmi-proxy)

Reviving this thread since ChromeOS needs to relax the root requirement in
order to use mbim-proxy.

I discussed this somewhat widely here, and it seems that the simplest
linux-footed solution is to use user/group membership.
So, instead of forcing clients that connect with the proxy to be root, we
can force them to have the same group id.

This keeps the current behavior (when mbim-proxy is indeed launched as
root) unchanged (uid(proxy) == gid(proxy) == uid(client) == gid(client) ==
0)
It introduces no new security vulnerabilities. If mbim-proxy is launched
with insufficient rights to access the modem device, any attempt to open
the device will simply fail.

Those systems that want to sandbox the modemmanager/proxy process better
can then do so using groups.

I'll submit a patch separately for mbim-proxy for this approach.

What do you think?


On Wed, Sep 3, 2014 at 4:43 PM, Ben Chan <benchan at chromium.org> wrote:

> 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/20140923/02374a47/attachment-0001.html>