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 14:13:29 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Sowmini Varadhan <sowmini.varadhan@...cle.com>
Cc:	Tom Herbert <tom@...bertland.com>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
Subject: Re: IPv6 extension header privileges

On 22.05.2016 13:56, 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 :-)
> 
>> On 21.05.2016 19:46, Sowmini Varadhan wrote:
>>> Do you mean this
>>>   http://www.ietf.org/mail-archive/web/spud/current/msg00365.html
> 
> On (05/22/16 03:08), Hannes Frederic Sowa wrote:
>> 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.
> 
> Tom should clarify what he meant, but perhaps he was referring to other
> threads discussing v6 EH. In any case, I dont think the way least-privileges
> for EH are implemented in an OS is directly relevant or causational for
> whether or not the kernel should be bypassed - looks like there are a lot 
> of other drafts floating around, arguing for implementing various tcp/ip
> protocols in uspace and beyond, motivated by various reasons.
> 
> Moving back to the topic here:
> 
>>> Hannes Frederic Sowa wrote:
>>>>>> A white list of certain registered IPv6 IANA-options for non-priv whould
> 
>> On 21.05.2016 19:46, Sowmini Varadhan wrote:
>>> 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.
> 
> On (05/22/16 03:08), Hannes Frederic Sowa wrote:
>> Hmm, haven't read carefully but isn't that just plain TCP in UDP? I saw
>> 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.
> 
> IANA registers internet protocol (and related) numbers. so, e.g., 
> So, for example, IP_TOS value is not really documented in iana,
> and it ends up being 1 on linux, 3 on freebsd.  Or, to take another example,
> IP_PKTINFO is "8" on linux, 0x1a on solaris and 25 in netbsd.  

Our setsockopts take the option numbers verbatim as they appear on the
wire (struct ipv6_opt_hdr). Thus we only need the numbers like
registered in the ipv6 parameter registry. API doesn't need to change
besides the privilege check. This is enough for Linux.

> but that should not stop the linux kernel (or other OS) from trying 
> to figure out the granularity of the rbac for these options and documenting 
> them in some helpful way for apps.

Just by knowing which option is interpreted in which way, we can do the
decision. I don't want to standardize APIs at all.

Bye,
Hannes