netdev - Re: [PATCH] net: add sysctl allow_so_priority for SO

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:	Fri, 21 Oct 2011 23:49:00 -0700
From:	Maciej Żenczykowski <zenczykowski@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] net: add sysctl allow_so_priority for SO_PRIORITY setsockopt

2011/10/21 David Miller <davem@...emloft.net>:
> From: Maciej Żenczykowski <zenczykowski@...il.com>
> Date: Fri, 21 Oct 2011 15:22:05 -0700
>
>> From: Maciej Żenczykowski <maze@...gle.com>
>>
>> This change adds a sysctl (/proc/sys/net/core/allow_so_priority)
>> with a default of true (1), as such it does not change the default
>> behaviour of the Linux kernel.
>>
>> This sysctl can be set to false (0), this will result in non
>> CAP_NET_ADMIN processes being unable to set SO_PRIORITY socket
>> option.
>>
>> This is desireable if we want to rely on socket/skb priorities
>> being inferred from TOS/TCLASS bits.
>>
>> Signed-off-by: Maciej Żenczykowski <maze@...gle.com>
>
> The socket layer is not the place to enforce this.
>
> The ingress into your MPLS/RSVP cloud that actually provides the
> quality of service is where you control and mangle the TOS as needed.
>
> Sorry, I'm not applying anything like this.  Any machine on your
> network can spit out any TOS it wants, and if you have control over
> the apps change it's behavior there.  If you don't have control over
> the apps then filter and mangle.

Hmm, so I already have container (cgroup) limits on what TOS settings,
a process is allowed to set (query: would you be interested in accepting a patch
for that at some point in the future?).

Normally setting IP_TOS also automatically sets sock->sk_priority
(based on a mapping), which
gets inherited into skb->priority, which can then be used for stuff
like hardware
priority queue dispatch (basically xps + skb->priority queue selection).
Either via an XPS like mechanism, or a QDISC like mechanism (preferred), or
an in-driver mechanism (currently have a hack which does this).

However, processes can also manually override the sk_priority by calling
SO_PRIORITY directly, at which point their IP_TOS and SO_PRIORITY no
longer match.

This patch allows you to disable this ability.  It's not affecting the
on-the-wire bits
in any way, it's really only affecting packet classification at the
qdisc and in the driver.

As you can see this patch isn't about TOS, it's about the kernel
internal skb priority setting.

On a related note, while setting IP_TOS sets sk_priority, setting
IPV6_TCLASS does not
set sk_priority.  I'd like to see this behaviour be consistent. As
such was planning on
sending you a patch to add sk_priority = rt_tos2priority(val) to the
IPV6_TCLASS setsockopt
code path.  Is that ok?

- Maciej
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html