linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vasiliy Kulikov <segoon@openwall.com>
To: David Miller <davem@davemloft.net>
Cc: solar@openwall.com, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org, peak@argo.troja.mff.cuni.cz,
	kees.cook@canonical.com, dan.j.rosenberg@gmail.com,
	eugene@redhat.com, nelhage@ksplice.com, kuznet@ms2.inr.ac.ru,
	pekkas@netcore.fi, jmorris@namei.org, yoshfuji@linux-ipv6.org,
	kaber@trash.net
Subject: Re: [PATCH] net: ipv4: add IPPROTO_ICMP socket kind
Date: Thu, 5 May 2011 15:32:45 +0400	[thread overview]
Message-ID: <20110505113245.GA8959@albatros> (raw)
In-Reply-To: <20110412.142534.183049889.davem@davemloft.net>

On Tue, Apr 12, 2011 at 14:25 -0700, David Miller wrote:
> Third, either we trust this code or we do not.  If we are OK with a
> user application spamming whatever they wish out of a datagram UDP
> socket, they can do no more harm with this thing unless there are
> bugs.

It is true in theory, but wrong in practice.  I have a cheap router
which can be made almost fully hang up with simple ping flood.  And I
almost sure many not very widespread implementations of IPv6 would
react not very clever way on non-echo ICMPv6 flood (I'd want to make
more than ICMPv6 Echo Request/Reply types available to nonroot).

> The group range thing I also consider hackish.

Why hackish?  We'd want to leave group range sysctl.  With this thing
you may restrict icmp according to different policies:

1) 0 4294967295 - We trust all users in the system.

2) 0 0 - We don't trust users, root only.

3) 101 4294967295 - We trust real users, but don't trust daemons.

4) 109 109 - We trust a signle group.  Either /sbin/ping is g+s and
owned by this group (like in Owl) or it is a group of "network admins"
who is allowed to flood.

5) 200 300 - We trust users in this range.  Little sense because of (4),
but possible.


Minor note about sgid'ed /sbin/ping: in case of a vulnerability in
this kernel code one has to find additional bug in ping binary to exploit
this vulnerability (unless it is somehow triggerable with ping arguments
overflow or remotely).


Thank you,

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

  parent reply	other threads:[~2011-05-05 11:32 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-09 10:15 [PATCH] net: ipv4: add IPPROTO_ICMP socket kind Vasiliy Kulikov
2011-04-12  5:06 ` Solar Designer
2011-04-12 21:25   ` David Miller
2011-04-13 11:22     ` Vasiliy Kulikov
2011-05-05 11:32     ` Vasiliy Kulikov [this message]
2011-05-10 18:09     ` [PATCH v2] " Vasiliy Kulikov
2011-05-10 19:15       ` David Miller
2011-05-10 19:45         ` Vasiliy Kulikov
2011-05-13 20:01         ` [PATCH v3] " Vasiliy Kulikov
2011-05-13 20:08           ` David Miller
2011-05-13 21:30           ` Andi Kleen
2011-05-13 22:22             ` [PATCH net-next-2.6] net: ipv4: add ping_group_range documentation Eric Dumazet
2011-05-15  8:18           ` [PATCH net-next-2.6] net: ping: dont call udp_ioctl() Eric Dumazet
2011-05-15 21:30             ` Solar Designer
2011-05-15 21:44               ` David Miller
2011-05-16  7:26                 ` [PATCH net-next-2.6 v2] " Eric Dumazet
2011-05-16 12:48                   ` Vasiliy Kulikov
2011-05-16 15:50                   ` David Miller
2011-04-13 10:29 ` [PATCH] net: ipv4: add IPPROTO_ICMP socket kind Alexey Dobriyan
2011-04-13 11:32   ` Vasiliy Kulikov
2011-04-14  9:16     ` Alexey Dobriyan
2011-04-14  1:53   ` Simon Horman
  -- strict thread matches above, loose matches on Subject: below --
2011-03-18 18:00 Vasiliy Kulikov
2011-03-18 19:47 ` David Miller
2011-03-18 19:59   ` Vasiliy Kulikov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110505113245.GA8959@albatros \
    --to=segoon@openwall.com \
    --cc=dan.j.rosenberg@gmail.com \
    --cc=davem@davemloft.net \
    --cc=eugene@redhat.com \
    --cc=jmorris@namei.org \
    --cc=kaber@trash.net \
    --cc=kees.cook@canonical.com \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nelhage@ksplice.com \
    --cc=netdev@vger.kernel.org \
    --cc=peak@argo.troja.mff.cuni.cz \
    --cc=pekkas@netcore.fi \
    --cc=solar@openwall.com \
    --cc=yoshfuji@linux-ipv6.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).