<div dir="ltr">[Crossing streams. I didn't have access to libqmi-devel. Registering there as well now.]</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 23, 2014 at 3:37 PM, Prathmesh Prabhu Chromium <span dir="ltr"><<a href="mailto:pprabhu@chromium.org" target="_blank">pprabhu@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>(All discussion here applies equally to mbim-proxy and qmi-proxy)</div><div><br></div>Reviving this thread since ChromeOS needs to relax the root requirement in order to use mbim-proxy.<div><br></div><div>I discussed this somewhat widely here, and it seems that the simplest linux-footed solution is to use user/group membership.</div><div>So, instead of forcing clients that connect with the proxy to be root, we can force them to have the same group id.</div><div><br></div><div>This keeps the current behavior (when mbim-proxy is indeed launched as root) unchanged (uid(proxy) == gid(proxy) == uid(client) == gid(client) == 0)</div><div>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.</div><div><br></div><div>Those systems that want to sandbox the modemmanager/proxy process better can then do so using groups.</div><div><br></div><div>I'll submit a patch separately for mbim-proxy for this approach.</div><div><br></div><div>What do you think?<br><div><br></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 3, 2014 at 4:43 PM, Ben Chan <span dir="ltr"><<a href="mailto:benchan@chromium.org" target="_blank">benchan@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">cc Prathmesh</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 14, 2014 at 12:28 AM, Aleksander Morgado <span dir="ltr"><<a href="mailto:aleksander@aleksander.es" target="_blank">aleksander@aleksander.es</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>>>> Letting the clients check whether they are allowed to open the port<br>
>>> before trying to use the proxy is not a good idea; you would be<br>
>>> relying on well-behaved clients, but that is not secure. One issue<br>
>>> currently is that the proxy is launched by the first process that<br>
>>> wants to use the port, and therefore inherits all its<br>
>>> uid/pid/environment. Limiting the usage to the root user was just a<br>
>>> quick way to make it safe, but if we can really do a proper<br>
>>> per-file-access-control that is secure, I'm all for it. Although not<br>
>>> sure exactly how that would be.<br>
>>><br>
>><br>
>> I was not suggesting that the client should perform the check. The qmi-proxy<br>
>> should probably check if a client can access the device in incoming_cb, but<br>
>> that seems tricky as you said (unless it uses a helper to impersonate the<br>
>> client credential and perform the file permissions check). That's why I'm<br>
>> looking for a compilation option to disable the check in qmi-proxy and have<br>
>> a sandbox to constrain the ModemManagr/qmi-proxy process.<br>
><br>
> If qmi-proxy is granted the CAP_SETUID capability, it could seteuid()<br>
> and then check if the client process can access the device file.<br>
><br>
<br>
</div>That's an approach we could try.<br>
<div><br>
> If we need finer control over permissions, would it make sense to have<br>
> qmi-proxy running as a DBus service, such that access control can be<br>
> specified in the DBus configuration file. I'm not sure if the DBus<br>
> overheads (e.g. latency) would be too much.<br>
><br>
<br>
</div>I also thought about this, truth be told... There will be more<br>
overhead, but it's not like we are passing thousands of QMI messages<br>
around, so maybe it's a nice add-on.<br>
<div><br>
> Perhaps a simpler (near-term) solution to accept a client process that<br>
> runs as the same user as the qmi-proxy?<br>
<br>
</div>I'm sure we're not the first ones facing this same issue; we should<br>
try to see what others have done in a similar situation. Anyway, if it<br>
is just for the sake of being able to setup test environments, I would<br>
be happy with a new configure option to disable the root check, as<br>
long as it is not default.<span><font color="#888888"><br>
<span><font color="#888888"><br>
--<br>
Aleksander<br>
</font></span></font></span></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>