netdev - Re: IPv6 extension header privileges

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3dddad94-f567-9bca-2e1e-c557e27ab945@stressinduktion.org>
Date:	Sat, 21 May 2016 18:28:37 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Tom Herbert <tom@...bertland.com>
Cc:	Sowmini Varadhan <sowmini.varadhan@...cle.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
Subject: Re: IPv6 extension header privileges

On 21.05.2016 18:00, Tom Herbert wrote:
> On Sat, May 21, 2016 at 8:33 AM, Hannes Frederic Sowa
> <hannes@...essinduktion.org> wrote:
>> On 21.05.2016 17:19, Tom Herbert wrote:
>>> On Sat, May 21, 2016 at 2:34 AM, Hannes Frederic Sowa
>>> <hannes@...essinduktion.org> wrote:
>>>> On Sat, May 21, 2016, at 03:56, Sowmini Varadhan wrote:
>>>>> On (05/21/16 02:20), Hannes Frederic Sowa wrote:
>>>>>>
>>>>>> There are some options inherently protocol depending like the jumbo
>>>>>> payload option, which should be under control of the kernel, or the
>>>>>> router alert option for igmp, which causes packets to be steered towards
>>>>>> the slow/software path of routers, which can be used for DoS attacks.
>>>>>>
>>>>>> Setting CALIPSO options in IPv6 on packets as users would defeat the
>>>>>> whole CALIPSO model, etc.
>>>>>>
>>>>>> The RFC3542 requires at least some of the options in dst/hop-by-hop
>>>>>
>>>>> "requires" is a strong word. 3542 declares it as a  "may" (lower case).
>>>>> The only thing required strongly is IPV6_NEXTHOP itself.
>>>>>
>>>>> I suspect 3542 was written at a time when hbh and dst opt were loosely
>>>>> defined and the "may" is just a place-holder (i.e., it's not even a MAY)
>>>>
>>>> My wording directly from the RFC was too strong, true, but given that
>>>> there is a CALIPSO patch already floating around for the kernel and
>>>> those options are strictly controlled by selinux policy and build the
>>>> foundation for the networking separation we can't make it simply
>>>> non-priv.
>>>>
>>> If you don't mind I'll change this to make specific options are
>>> privileged and not all hbh and destopt. There is talk in IETF about
>>> reinventing IP extensibility within UDP since the kernel APIs don't
>>> allow setting EH. I would like to avoid that :-)
>>
>> Hehe, certainly.
>>
>> A white list of certain registered IPv6 IANA-options for non-priv whould
>> certainly fly in my opinion. That is what I meant with "More
>> fine-grained parsing and setting of those options has never been
>> implemented." from my first mail.
>>
>> I am not that certain about a blacklist though, but haven't thought
>> about that enough. I didn't yet get around to review other options, but
>> basically people could use private options in some proprietary settings
>> and we could break their assumptions by such a change.
>>
>> Would a white list be sufficient?
>>
> Probably not. The "kernel is the problem" community always seem to be
> looking for even the slightest API or implementation deficiency to
> justify bypassing the kernel entirely. :-(

Another issue, which could come up also is the ordering options during
the merge of kernel policy and user space provided options, hmpf...

Maybe a way out of it is to use some kind of sysctl, capability, or
whatever, depending on the use cases?

Bye,
Hannes