netdev - Re: setsockopt(IP_TOS) being privileged or distinct capability?

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:	Tue, 6 Jul 2010 04:07:34 +0200
From:	Hagen Paul Pfeifer <hagen@...u.net>
To:	Philip Prindeville <philipp_subx@...fish-solutions.com>
Cc:	Alexander Clouter <alex@...riz.org.uk>, netdev@...r.kernel.org
Subject: Re: setsockopt(IP_TOS) being privileged or distinct capability?

* Philip Prindeville | 2010-07-05 12:04:31 [-0600]:

>I understand that.  That's part of the reason that I've submitted
>patches for APR, Apache, Thunderbird, Firefox, Proftpd, Curl, wget,
>etc.  There is pressure within certain technical groups to get ISP's
>to voluntarily implement RFC-4594... that's the carrot.  The stick
>being FCC heavy-handed regulation of the ISP's if they don't.

Where is the _real_ advantage if setsockopt(IP_TOS) where a privileged
operation? At the end the user/service is still required to set his service
class, but this time with CAP_NET_ADMIN. Do you think that Service
Providers/Transit Providers trust (and this is the critical aspect) customers
based on some IP flags - this is extreme unlikely. 99% of users have
effective CAP_NET_ADMIN capabilities - and you cannot stop using them.

Service Providers/Transit Providers will trust customers who pays more and
then they will accept their DIFFSERV suggestion signaled via IP DSCP. All
other customers will be treated normal, with zeroed DSCP. It makes no sense
for ISP's to shift the trust aspect to the customer side.

HGN

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