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:
> Thinking about this some more, the per option white list is a b
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 ended mechanism for application
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 network with arbitrary data (
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 network with arbitrary data (
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 mecha
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 that
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 specific options are
> privileged and not all hbh
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 p
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 all hbh and destopt. There is talk in IETF about
>>>
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 extensibility within UDP since the kernel
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
> > 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 tha
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 set
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
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, 2016, at 03:56, Sowmini Varadhan wrote:
> On (05/21/16
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, 2016, at 03:56, Sowmini Varadhan wrote:
> On (05/21/16
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 (05/21/16 02:20), Hannes Frederic Sowa wrote:
>
> T
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 depending like the jumbo
>>>
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, which should be under contro
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 s
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 cau
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 rout
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 to
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
24 matches
Mail list logo
