[Olsr-dev] including wifi stats in jsoninfo

[Ferry Huberts]

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.


> If you look at the jsoninfo plugin, its just reading olsrd internals, and reading files from the filesystem.
>
>>> One idea for making olsrd smaller is making it easy to build the plugins
>>> outside of olsrd itself, so they can be entirely separate projects.  This
>>> is a better approach IMHO than trying to limit what people do with
>>> plugins.
>>
>> IMHO this should be an external application accessing the APIs of olsrd and
>> the other binaries you want to get data from.
>
> As far as I know, that's not currently possible since there isn't a public API.  It would be nice to have a separate jsoninfo daemon that handled the network socket, reading data from olsrd, and whatever else.
>
> .hc

-- 
Ferry Huberts