[Olsr-dev] including wifi stats in jsoninfo

[Hans-Christoph Steiner]

On Jun 9, 2012, at 11:01 AM, Ferry Huberts wrote:

> 
> 
> On 09-06-12 16:23, Hans-Christoph Steiner wrote:
>> 
>> On Jun 9, 2012, at 7:15 AM, Clemens Hopfer wrote:
>> 
>>> Hi,
>>> 
>>> On Wednesday 06 June 2012 16:20:35 Hans-Christoph Steiner wrote:
>>>> [...]
>>>> I agree we should not put everything into olsrd.  The stuff I'm talking
>>>> about is entirely in the jsoninfo plugin, so people don't need to use it
>>>> all.  The jsoninfo plugin would not be larger than pud or tas with iwinfo
>>>> in it.
>>> 
>>> keep in mind, that the plugin will be running with the same privileges as the
>>> olsrd, since it's just a loaded library. And since olsrd must be running as
>>> root, its a _very_bad_ idea to be able to call binaries from the plugin.
>>> 
>>> Also, since olsrd is basically not threaded, it will block (pls correct me if
>>> I'm wrong) while processing data for the plugin communication.
>>> 
>>> So being able to acces, and thus attack a olsrd plugin is directly attacking
>>> the olsrd itself, which is the core element of your infrastructure.
>> 
>> This is a weakness of olsrd for sure.  Ideally, it would be structured so that only the parts that need root would have it, I think just the part that edits the routing table and to claim port 698.  The rest would run as nobody or some very unprivileged user.
>> 
> 
> I think you have a very basic misunderstanding of how things work.
> olsrd is a single process (threading is irrelevant in this case), the plugins are libraries that are loaded into olsrd.
> 
> It is _impossible_ for a single process to run as multiple users.
> You _can_ drop privileges, but we'd still need CAP_NETADMIN to adjust the routing table, and this privilege is still very close to root privileges.

It is entirely clear to me that olsrd currently runs as a single process with root privileges.  I was describing how I think olsrd should work, now how it does work.  Having a single process running as root is bad form when this process only needs root access for very few things.  Separating things based on what privileges are needed is what sshd does, for example, and many other daemons.

It would be nice to even use a non-privileged port, so that root is only ever needed for accessing the routing tables.  Then for changing the routing table, there would be a tiny chunk of code running as root with a very simple, limited protocol.  Then everything else including plugins would run as a very unprivileged user.

.hc