<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 class="">>>> 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 class=""><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 class=""><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.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Aleksander<br>
</font></span></blockquote></div><br></div>