[Olsr-dev] privilege separation for olsrd

Hans-Christoph Steiner (spam-protected)
Thu Oct 4 20:16:51 CEST 2012

Attached is my current patch used in the Debian package to enable
hardening.  It forces a couple of things (-O2 and -Wl,-z,now) and allows
the Debian CFLAGS and LDFLAGS to work.

Here's what Debian uses for its hardening flags:

I think that -O2 should be set by default on all linux and Android
builds, at the very least.  That'll automatically enable the
-D_FORTIFY_SOURCE=2 stuff.  Then it should be easy for platforms like
OpenWRT to override the -O2 with -Os.  Anyone have a clear idea how to
do that?


On 10/03/2012 06:32 PM, Henning Rogge wrote:
> I would also like to continue the discussion...
> Routing setup and socket creation are the main operations that need
> root... and I think routing setup needs always root, not only when we
> create the netlink socket.
> On Wed, Oct 3, 2012 at 9:37 PM, Hans-Christoph Steiner
> <(spam-protected)> wrote:
>> Makes sense to me. I'm going to focus on the gcc hardening flags for
>> now, and get them incorporated into the Debian package.  Then I think we
>> should consider adding them to the relevant Makefiles in olsrd.
> Good idea...
> if there are any bugs when we run with -O2, just post them here...
> should be trivial to fix.
> The new framework already compiles on -Os and -O2/-O3, so it should be
> easy to move this code to "hardened".
> Henning
>> For something like OpenWRT, I don't think the hardening is so important
>> since an OpenWRT mesh node is very unlikely to contain other data on
>> them.  For olsrd running on people's laptops and phones, then it makes
>> it a much more appealing target.
>> .hc
>> On 10/03/2012 02:54 PM, Ferry Huberts wrote:
>>> I discussed all of this with Henning on multiple occasions and we always
>>> came to the conclusion that (to us) it's not worth the effort for olsrd v1.
>>> For olsrd v2 we maybe want to have it but the focus is on getting things
>>> up and running.
>>> That said, if anyone wants to implement it then they're welcome to do
>>> so. Just be warned that it has to be on a branch (since it's a major
>>> change) and that it will be closely scrutinised once proposed for merging.
>>> On 03-10-12 19:47, Roar Bjørgum Rotvik wrote:
>>>> On 10/03/2012 06:07 PM, Hans-Christoph Steiner wrote:
>>>>> I was just poking around OpenSSH for ideas for how olsrd could be a lot
>>>>> more secure.  The main issue right now is that olsrd does everything as
>>>>> root, even though it only needs root privileges for specific things
>>>>> (opening the socket on port 698 and editing the routing table).
>>>>> OpenSSH is a daemon that needs privileges for opening a socket on port
>>>>> 22, but then it does very little else as root.  It does this without
>>>>> using threads, but relies on multiple processes instead.  Here's two
>>>>> overviews of how openssh does it:
>>>>> http://www.citi.umich.edu/u/provos/ssh/privsep.html
>>>>> http://www.openbsd.org/papers/openssh-measures-asiabsdcon2007-slides.pdf
>>>> I understand that my suggestion is Linux-only, but what about posix
>>>> capabilites?
>>>> http://www.linux-tutorial.info/modules.php?name=ManPage&sec=7&manpage=capabilities
>>>> http://www.friedhoff.org/posixfilecaps.html
>>>> (and many other sites)
>>>> Capabilites divides root power in smaller pieces. For olsrd, it may work
>>>> to let olsrd drop all caps without CAP_NET_BIND_SERVICE/CAP_NET_ADMIN
>>>> (needed for priviledged network operations like take interface up/down,
>>>> I think this also work for netlink sockets). Or set caps in file
>>>> attribute in the filesystem.
>>>> But as I said, don't know if/how this is supported on other platforms.
>>>> Regards,
>>>> Roar Bjørgum Rotvik
>> --
>> Olsr-dev mailing list
>> (spam-protected)
>> https://lists.olsr.org/mailman/listinfo/olsr-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 310-hardening-fixes.patch
Type: text/x-patch
Size: 1554 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20121004/60b07166/attachment.bin>

More information about the Olsr-dev mailing list