Re: IPv6 extension header privileges

On Fri, May 27, 2016 at 10:14 AM, Hannes Frederic Sowa wrote: > Hi, > > On 27.05.2016 18:59, Tom Herbert wrote: >> On Fri, May 27, 2016 at 8:03 AM, Sowmini Varadhan >> wrote: >>> On (05/27/16 11:53), Hannes Frederic Sowa wrote: >

Re: IPv6 extension header privileges

Hi, On 27.05.2016 18:59, Tom Herbert wrote: > On Fri, May 27, 2016 at 8:03 AM, Sowmini Varadhan > wrote: >> On (05/27/16 11:53), Hannes Frederic Sowa wrote: Thinking about this some more, the per option white list is a better approach. If we allow an open

Re: IPv6 extension header privileges

On Fri, May 27, 2016 at 9:46 AM, Hannes Frederic Sowa wrote: > On Thu, May 26, 2016, at 20:42, Tom Herbert wrote: >> Thinking about this some more, the per option white list is a better >> approach. If we allow an open ended mechanism for applications to >> signal the

Re: IPv6 extension header privileges

On Fri, May 27, 2016 at 8:03 AM, Sowmini Varadhan wrote: > On (05/27/16 11:53), Hannes Frederic Sowa wrote: >> > Thinking about this some more, the per option white list is a better >> > approach. If we allow an open ended mechanism for applications to >> > signal the

Re: IPv6 extension header privileges

On Thu, May 26, 2016, at 20:42, Tom Herbert wrote: > Thinking about this some more, the per option white list is a better > approach. If we allow an open ended mechanism for applications to > signal the network with arbitrary data (like user specified hbp > options would be), then use of that

Re: IPv6 extension header privileges

On (05/27/16 11:53), Hannes Frederic Sowa wrote: > > Thinking about this some more, the per option white list is a better > > approach. If we allow an open ended mechanism for applications to > > signal the network with arbitrary data (like user specified hbp > > options would be), then use of

Re: IPv6 extension header privileges

On 26.05.2016 20:42, Tom Herbert wrote: > On Mon, May 23, 2016 at 11:11 AM, Tom Herbert wrote: >> On Sun, May 22, 2016 at 4:56 AM, Sowmini Varadhan >> wrote: >>> > Tom Herbert wrote: > If you don't mind I'll change this to make

Re: IPv6 extension header privileges

Hi, Tom Herbert wrote: > Hi, > > In ipv6_sockglue.c I noticed: > > /* hop-by-hop / destination options are privileged option */ > retv = -EPERM; > if (optname != IPV6_RTHDR && !ns_capable(net->user_ns, CAP_NET_RAW)) >break; > > Can anyone provide that rationale as to why these are

Re: IPv6 extension header privileges

On Mon, May 23, 2016 at 11:11 AM, Tom Herbert wrote: > On Sun, May 22, 2016 at 4:56 AM, Sowmini Varadhan > wrote: >> >>> > Tom Herbert wrote: >>> > If you don't mind I'll change this to make specific options are >>> > privileged and not

Re: IPv6 extension header privileges

On Sun, May 22, 2016 at 4:56 AM, 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

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

Re: IPv6 extension header privileges

> > 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

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

Re: IPv6 extension header privileges

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

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 > wrote: >> On 21.05.2016 17:19, Tom Herbert wrote: >>> On Sat, May 21, 2016 at 2:34 AM, Hannes Frederic Sowa >>> wrote: On Sat, May 21,

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 > wrote: >> On 21.05.2016 17:19, Tom Herbert wrote: >>> On Sat, May 21, 2016 at 2:34 AM, Hannes Frederic Sowa >>> wrote: On Sat, May 21,

Re: IPv6 extension header privileges

On Sat, May 21, 2016 at 8:33 AM, Hannes Frederic Sowa wrote: > On 21.05.2016 17:19, Tom Herbert wrote: >> On Sat, May 21, 2016 at 2:34 AM, Hannes Frederic Sowa >> wrote: >>> On Sat, May 21, 2016, at 03:56, Sowmini Varadhan wrote: On

Re: IPv6 extension header privileges

On 21.05.2016 17:19, Tom Herbert wrote: > On Sat, May 21, 2016 at 2:34 AM, Hannes Frederic Sowa > 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

Re: IPv6 extension header privileges

On Sat, May 21, 2016 at 2:34 AM, Hannes Frederic Sowa 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,

Re: IPv6 extension header privileges

On (05/21/16 11:34), Hannes Frederic Sowa wrote: > > 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

Re: IPv6 extension header privileges

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

Re: IPv6 extension header privileges

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

Re: IPv6 extension header privileges

On 21.05.2016 00:37, Tom Herbert wrote: > Hi, > > In ipv6_sockglue.c I noticed: > > /* hop-by-hop / destination options are privileged option */ > retv = -EPERM; > if (optname != IPV6_RTHDR && !ns_capable(net->user_ns, CAP_NET_RAW)) >break; > > Can anyone provide that rationale as

IPv6 extension header privileges

Hi, In ipv6_sockglue.c I noticed: /* hop-by-hop / destination options are privileged option */ retv = -EPERM; if (optname != IPV6_RTHDR && !ns_capable(net->user_ns, CAP_NET_RAW)) break; Can anyone provide that rationale as to why these are privileged ops? Thanks, Tom