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]
Message-ID: <20100706020734.GA2972@nuttenaction>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ