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]

Date:	Sun, 22 May 2016 03:08:10 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Sowmini Varadhan <sowmini.varadhan@...cle.com>,
	Tom Herbert <tom@...bertland.com>
Cc:	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
Subject: Re: IPv6 extension header privileges

On 21.05.2016 19:46, Sowmini Varadhan wrote:
> Tom Herbert wrote:
>>>>> 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 :-)
> 
> Do you mean this
>   http://www.ietf.org/mail-archive/web/spud/current/msg00365.html
> 
> Maybe I misunderstood that rather long thread, but the author of that
> draft seems to be arguing for reinventing tcp congavoid and windowing 
> on top of udp to bypass kernel? ;-)

Hmm, haven't read carefully but isn't that just plain TCP in UDP? I saw
extension headers mentioned but haven't grasped why they deem necessary.

> Hannes Frederic Sowa wrote:
>>>> A white list of certain registered IPv6 IANA-options for non-priv whould
> 
> Problem is that APIs are not IANA'ed. 
> Even RFC 3542 is just Informationaal. 
> 
> And even the classic socket API's that come down from BSD are not 
> ietf'ed or iana'ed.

I think I don't completely understand this. IANA is numbering registry
and if we have the proper option number allocated we can make sensible
decisions and put options on the white list or provide a more complete
sensible implementation of the specification in the kernel.

E.g. if an option for encapsulation is going to be specified, normal
users should not be able to set those, like with CALIPSO or some VNI
inside hop-by-hop options. That should probably be controlled by a
routing table or a flow matching subsystem, in the kernel.

Congestion and windowing information need to be settable and receivable
from user space.

Unassigned option, we don't know anything about them so far and should
probably being blocked for the time being, as we don't know which spec
would use the number.

I think it is also in favor of the IETF to get those numbers specified
and allocated in a proper way, otherwise security won't be manageable at
all any more.

> Hannes Frederic Sowa wrote:
>> Can you give some more details about the planned new options? I think we
>> can also open the API up for all options where the fourth bit is set,
>> which AFAIK denotes the experimental option space. And only have a
>> blacklist for the fourth bit == 0 case. Otherwise this is something IETF
>> people probably know more about what an impact this change could have.
> 
> I think it would be ok for some options to be privileged, others to not.
> We certainly have precedent for that from the classic socket APIs..
> and man pages etc can document any restrictions, as we do with other
> ioctls/sockopts etc.

Sure, we can make options unprivileged, we just need to know which one
and find out the details how they mix with each other. Also user space
should only be allowed to query the options it is allowed to set, too,
and not the whole option blocks.

Bye,
Hannes