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
| ||
|
Date: Sat, 21 May 2016 09:00:36 -0700 From: Tom Herbert <tom@...bertland.com> To: Hannes Frederic Sowa <hannes@...essinduktion.org> 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 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. :-( Tom > Bye, > Hannes >
Powered by blists - more mailing lists