qmi-proxy running as non-root user

[Prathmesh Prabhu Chromium]

[Crossing streams. I didn't have access to libqmi-devel. Registering there
as well now.]

On Tue, Sep 23, 2014 at 3:37 PM, Prathmesh Prabhu Chromium <
pprabhu at chromium.org> wrote:

> (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/093f8227/attachment.html>