Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #106716 > unrolled thread

setting sysctl net.ipv4.ping_group_range

Back to article view | Back to linux.debian.devel

Contents

  setting sysctl net.ipv4.ping_group_range Noah Meyerhans <noahm@debian.org> - 2023-01-02 21:30 +0100
    Re: setting sysctl net.ipv4.ping_group_range Peter Pentchev <roam@ringlet.net> - 2023-01-02 21:50 +0100
      Re: setting sysctl net.ipv4.ping_group_range Marco d'Itri <md@Linux.IT> - 2023-01-02 22:20 +0100
        Re: setting sysctl net.ipv4.ping_group_range Noah Meyerhans <noahm@debian.org> - 2023-01-02 22:50 +0100
    Re: setting sysctl net.ipv4.ping_group_range Marco d'Itri <md@Linux.IT> - 2023-01-02 22:20 +0100
      Re: setting sysctl net.ipv4.ping_group_range Noah Meyerhans <noahm@debian.org> - 2023-01-02 23:00 +0100
        Re: setting sysctl net.ipv4.ping_group_range Marco d'Itri <md@Linux.IT> - 2023-01-03 00:50 +0100
          Re: setting sysctl net.ipv4.ping_group_range Adam Borowski <kilobyte@angband.pl> - 2023-01-03 01:40 +0100
            Re: setting sysctl net.ipv4.ping_group_range Marco d'Itri <md@Linux.IT> - 2023-01-03 03:30 +0100
              Re: setting sysctl net.ipv4.ping_group_range Steve Langasek <vorlon@debian.org> - 2023-01-08 02:10 +0100
                Re: setting sysctl net.ipv4.ping_group_range Ansgar <ansgar@43-1.org> - 2023-01-08 13:40 +0100
        Re: setting sysctl net.ipv4.ping_group_range Ángel <debian-devel@debian.16bits.net> - 2023-01-15 02:40 +0100
          Re: setting sysctl net.ipv4.ping_group_range Bastian Blank <waldi@debian.org> - 2023-01-15 11:40 +0100
    Re: setting sysctl net.ipv4.ping_group_range Helmut Grohne <helmut@subdivi.de> - 2023-04-12 18:10 +0200
      Re: setting sysctl net.ipv4.ping_group_range Marco d'Itri <md@Linux.IT> - 2023-04-12 21:40 +0200

#106716 — setting sysctl net.ipv4.ping_group_range

There are several examples of packages installing files to
/usr/lib/sysctl.d, but I haven't found any specific guidance on policies
about what's appropriate for them.  Since sysctl variables change the
system behavior in a way that's not limited to the package changing the
setting, and since the package in question (iputils-ping) is Priority:
important and part of the default install, I won't want to make any
changes without consulting here first.

See bug #1008281 for context. [1]

The proposal is to install /usr/lib/sysctl.d/iputils-ping.conf with the
following content:
net.ipv4.ping_group_range="0 2147483647"

With that in place, unprivileged users are able to excute ping for both
IPv4 and IPv6 targets without cap_net_raw (currently set as either a
file-based attribute on the ping binary or acquired via setuid).  But
since that applies system-wide, not just to the ping binary, there may
be objections.

After applying this change, I believe it'd be appropriate to drop ping's
setcap/setuid settings from postinst altogether, though I'd be open to
other options. [2]

noah

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008281
2. https://salsa.debian.org/debian/iputils/-/blob/master/debian/iputils-ping.postinst

[toc] | [next] | [standalone]

#106717

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jan 02, 2023 at 12:01:54PM -0800, Noah Meyerhans wrote:
> There are several examples of packages installing files to
> /usr/lib/sysctl.d, but I haven't found any specific guidance on policies
> about what's appropriate for them.  Since sysctl variables change the
> system behavior in a way that's not limited to the package changing the
> setting, and since the package in question (iputils-ping) is Priority:
> important and part of the default install, I won't want to make any
> changes without consulting here first.
[snip]
> After applying this change, I believe it'd be appropriate to drop ping's
> setcap/setuid settings from postinst altogether, though I'd be open to
> other options. [2]

I personally would prefer giving the administrator a way to change that.
Maybe add a low priority debconf question with a "ping is not setuid"
default, then mention that debconf setting in a comment in the file that
the package installs in the sysctl.d/ directory.

Other than that, I think making ping not setuid is a great idea.

G'luck,
Peter

-- 
Peter Pentchev  roam@ringlet.net roam@debian.org pp@storpool.com
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

[toc] | [prev] | [next] | [standalone]

#106719

[Multipart message — attachments visible in raw view] — view raw

On Jan 02, Peter Pentchev <roam@ringlet.net> wrote:

> I personally would prefer giving the administrator a way to change that.
> Maybe add a low priority debconf question with a "ping is not setuid"
> default, then mention that debconf setting in a comment in the file that
> the package installs in the sysctl.d/ directory.
Please don't. There are already way too many debconf questions and this 
one would be totally pointless: anybody who cares to change the default
can just locally override the /usr/lib/sysctl.d/ file with a drop-in in 
/etc/sysctl.d/ .

> Other than that, I think making ping not setuid is a great idea.
ping is (generally) not setuid.

-- 
ciao,
Marco

[toc] | [prev] | [next] | [standalone]

#106720

On Mon, Jan 02, 2023 at 10:11:38PM +0100, Marco d'Itri wrote:
> On Jan 02, Peter Pentchev <roam@ringlet.net> wrote:
> 
> > I personally would prefer giving the administrator a way to change that.
> > Maybe add a low priority debconf question with a "ping is not setuid"
> > default, then mention that debconf setting in a comment in the file that
> > the package installs in the sysctl.d/ directory.
> Please don't. There are already way too many debconf questions and this 
> one would be totally pointless: anybody who cares to change the default
> can just locally override the /usr/lib/sysctl.d/ file with a drop-in in 
> /etc/sysctl.d/ .

+1. I don't have any desire to add debconf to iputils-ping.  I'd suggest
the /etc/sysctl.d/ approach for admin overrides as well.

noah

[toc] | [prev] | [next] | [standalone]

#106718

[Multipart message — attachments visible in raw view] — view raw

On Jan 02, Noah Meyerhans <noahm@debian.org> wrote:

> With that in place, unprivileged users are able to excute ping for both
> IPv4 and IPv6 targets without cap_net_raw (currently set as either a
> file-based attribute on the ping binary or acquired via setuid).  But
> since that applies system-wide, not just to the ping binary, there may
> be objections.
I do not think that the submitter made clear why this would be 
preferable, so I had to research it myself. See:

https://fedoraproject.org/wiki/Changes/EnableSysctlPingGroupRange
https://github.com/systemd/systemd/pull/13141

Since this is one of the systemd sysctl defaults (of which I think that 
we should adopt more, especially the network-related ones!) I agree with 
changing this.
I would just do it in the systemd package package to allow all packages 
to benefit from it without having to care if ping is installed.

-- 
ciao,
Marco

[toc] | [prev] | [next] | [standalone]

#106721

On Mon, Jan 02, 2023 at 10:09:44PM +0100, Marco d'Itri wrote:
> > With that in place, unprivileged users are able to excute ping for both
> > IPv4 and IPv6 targets without cap_net_raw (currently set as either a
> > file-based attribute on the ping binary or acquired via setuid).  But
> > since that applies system-wide, not just to the ping binary, there may
> > be objections.
> I do not think that the submitter made clear why this would be 
> preferable, so I had to research it myself. See:
> 
> https://fedoraproject.org/wiki/Changes/EnableSysctlPingGroupRange
> https://github.com/systemd/systemd/pull/13141
> 
> Since this is one of the systemd sysctl defaults (of which I think that 
> we should adopt more, especially the network-related ones!) I agree with 
> changing this.
> I would just do it in the systemd package package to allow all packages 
> to benefit from it without having to care if ping is installed.

I'm entirely happy to reassign this request to systemd and have the
setting applied more broadly.  The question that arises then is what to
do about the file-level capabilities on the ping binary.  Ideally we
drop them entirely (including the setuid fallback), but when?

I could leave things completely decoupled, and simply wait until systemd
makes the change and then upload iputils and assume that anybody
upgrading iputils is also upgrading systemd.  That seems to be what
Fedora did, according to the fedoraproject.org wiki cited above.
Alternatives would seem to involve some level of versioned dependency,
which doesn't feel right.

noah

[toc] | [prev] | [next] | [standalone]

#106722

[Multipart message — attachments visible in raw view] — view raw

On Jan 02, Noah Meyerhans <noahm@debian.org> wrote:

> I'm entirely happy to reassign this request to systemd and have the
> setting applied more broadly.  The question that arises then is what to
> do about the file-level capabilities on the ping binary.  Ideally we
> drop them entirely (including the setuid fallback), but when?
Some options:
- conflict with systemd < version_with_the_new_default
- wait for a full release and then just drop it
- when sysctl in postinst reports the new default
- a mix of the last two options

I suggest that you improve the ping error message to also mention the 
sysctl (or maybe an appropriate writeup in README.Debian?).

-- 
ciao,
Marco

[toc] | [prev] | [next] | [standalone]

#106723

On Tue, Jan 03, 2023 at 12:43:31AM +0100, Marco d'Itri wrote:
> On Jan 02, Noah Meyerhans <noahm@debian.org> wrote:
> > I'm entirely happy to reassign this request to systemd and have the
> > setting applied more broadly.
> Some options:
> - conflict with systemd < version_with_the_new_default
> - wait for a full release and then just drop it
> - when sysctl in postinst reports the new default
> - a mix of the last two options

Debian's default sysctl settings should reside in procps (as it owns
/sbin/sysctl and /etc/sysctl* settings) rather than some unrelated
package.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#106726

[Multipart message — attachments visible in raw view] — view raw

On Jan 03, Adam Borowski <kilobyte@angband.pl> wrote:

> Debian's default sysctl settings should reside in procps (as it owns
> /sbin/sysctl and /etc/sysctl* settings) rather than some unrelated
> package.
Nowadays systemd is a source of common sysctl settings among different 
distributions.

-- 
ciao,
Marco

[toc] | [prev] | [next] | [standalone]

#106774

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jan 03, 2023 at 03:26:37AM +0100, Marco d'Itri wrote:
> On Jan 03, Adam Borowski <kilobyte@angband.pl> wrote:

> > Debian's default sysctl settings should reside in procps (as it owns
> > /sbin/sysctl and /etc/sysctl* settings) rather than some unrelated
> > package.
> Nowadays systemd is a source of common sysctl settings among different 
> distributions.

Debian still supports other init systems in the archive besides systemd. 
Should ping fail to run on a Debian system that is not using systemd?

We also recently ran into a bug with systemd in Ubuntu because the "common
sysctl settings among different distributions" that they had added clobbered
settings that had been shipped for years already in the Ubuntu procps
package.  No thank you.

  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962038

What would really be a great place for shipping common sysctl settings among
different distributions would be in the Linux kernel, instead of diverging
from the kernel defaults in userspace and representing this as "common".

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                   https://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[toc] | [prev] | [next] | [standalone]

#106779

On Sat, 2023-01-07 at 16:55 -0800, Steve Langasek wrote:
> On Tue, Jan 03, 2023 at 03:26:37AM +0100, Marco d'Itri wrote:
> 
> > Nowadays systemd is a source of common sysctl settings among different 
> > distributions.
> 
> Debian still supports other init systems in the archive besides systemd. 

Not really: we only support exploring and developing alternative init
systems. That doesn't mean full support and random things might not
work correctly (and that is accepted).

> Should ping fail to run on a Debian system that is not using systemd?

Why not? It's not different from other software where we allow this?

> We also recently ran into a bug with systemd in Ubuntu because the "common
> sysctl settings among different distributions" that they had added clobbered
> settings that had been shipped for years already in the Ubuntu procps
> package.  No thank you.
> 
>   https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962038
> 
> What would really be a great place for shipping common sysctl settings among
> different distributions would be in the Linux kernel, instead of diverging
> from the kernel defaults in userspace and representing this as "common".

I think I read somewhere that linux upstream is not enthusiastic about
choosing more appropriate defaults and leaves that to downstream.
Diverting those is only possible in userspace as we still support using
self-built kernels (which can come from upstream) ;-)

If you want some other "common" ground, I guess it would need to be
created and adopted instead of the current one first.

Ansgar

[toc] | [prev] | [next] | [standalone]

#106824

On 2023-01-02 at 13:55 -0800, Noah Meyerhans wrote:
> I'm entirely happy to reassign this request to systemd and have the
> setting applied more broadly.  The question that arises then is what
> to
> do about the file-level capabilities on the ping binary.  Ideally we
> drop them entirely (including the setuid fallback), but when?
> 
> I could leave things completely decoupled, and simply wait until
> systemd
> makes the change and then upload iputils and assume that anybody
> upgrading iputils is also upgrading systemd.  That seems to be what
> Fedora did, according to the fedoraproject.org wiki cited above.
> Alternatives would seem to involve some level of versioned
> dependency,
> which doesn't feel right.
> 
> noah


Currently iputils-ping's postinst does (at configure):


>     if command -v setcap > /dev/null; then
>         if setcap cap_net_raw+ep /bin/ping; then
>             chmod u-s /bin/ping
>         else
>             echo "Setcap failed on /bin/ping, falling back to setuid" >&2
>             chmod u+s /bin/ping
>         fi
>     else
>         echo "Setcap is not installed, falling back to setuid" >&2
>         chmod u+s /bin/ping
>     fi


I would change that to:


    if sysctl -n net.ipv4.ping_group_range | grep -q -v '^1      0$'; then # N.B. this is a tab
        # No need for elevated rights for ping when ping_group_range feature is in use
        setcap '' /bin/ping 2> /dev/null || true
        chmod u-s /bin/ping
    elif command -v setcap > /dev/null; then
        # If we have setcap is installed, try setting cap_net_raw+ep,
        # which allows us to install our binaries without the setuid
        # bit.

        if setcap cap_net_raw+ep /bin/ping; then
            chmod u-s /bin/ping
        else
            echo "Setcap failed on /bin/ping, falling back to setuid" >&2
            chmod u+s /bin/ping
        fi
    else
        echo "No ping_group_range and setcap is not installed, falling back to setuid" >&2
        chmod u+s /bin/ping
    fi



if ping_group_range is set ("1<tab>0" is the value when disabled, so
anything else means that the feature is configured for some groups),
then it disables capabilities and setuid. 
Else it goes the existing route.

It is checking it *in the running kernel*, so if both iputils-ping and 
procps (or whatever package is dropping the sysctl) are upgraded at the
same time, it would not detect until the *next* iputils upgrade after the
system is upgraded.

One might additionally check if there is a sysctl file there to enable the feature
(the problem would still bepresent if it is upgraded at the same time with
iputils-ping being upgraded *before* procps), but I think it's undesirable to leave
a non-working program after the update (for some reason, procps postinst doesn't seem
to automatically apply the newly dropped settings).

This code would also do the right thing™ if the existing kernel lacked support for the
feature, although this seems moot, as it has been there for more than a decade [1]. It 
might happen on kFreeBSD, if it's a non-standard kernel where such feature was kept out
(which doesn't make much sense), or procps is not installed (despite being an 'important'
package).

Regards


1- https://lwn.net/Articles/422330/

[toc] | [prev] | [next] | [standalone]

#106825

On Sun, Jan 15, 2023 at 02:35:06AM +0100, Ángel wrote:
> I would change that to:

Please don't.  If we change the distribution default for
net.ipv4.ping_group_range, then ping should refrain from ever trying to
check for it and never make the executable privileged.

Bastian

-- 
There is a multi-legged creature crawling on your shoulder.
		-- Spock, "A Taste of Armageddon", stardate 3193.9

[toc] | [prev] | [next] | [standalone]

#107607

Hi,

On Mon, Jan 02, 2023 at 12:01:54PM -0800, Noah Meyerhans wrote:
> See bug #1008281 for context. [1]
> 
> The proposal is to install /usr/lib/sysctl.d/iputils-ping.conf with the
> following content:
> net.ipv4.ping_group_range="0 2147483647"
> 
> With that in place, unprivileged users are able to excute ping for both
> IPv4 and IPv6 targets without cap_net_raw (currently set as either a
> file-based attribute on the ping binary or acquired via setuid).  But
> since that applies system-wide, not just to the ping binary, there may
> be objections.

As much as I like unprivileged operation, I think this change may expand
privileges beyond what we expect. At present, ping limits an
unprivileged user to a minimum spacing of 2ms and prevents a flood ping.
Of course a user can just run multiple ping processes in parallel to
overcome this limitation.

I'm posting this, because I think this argument as been missed in the
discussion. I consider this argument to be vaguely weak and not
significantly affecting the course of action.

Helmut

[toc] | [prev] | [next] | [standalone]

#107608

[Multipart message — attachments visible in raw view] — view raw

On Apr 12, Helmut Grohne <helmut@subdivi.de> wrote:

> As much as I like unprivileged operation, I think this change may expand
> privileges beyond what we expect. At present, ping limits an
> unprivileged user to a minimum spacing of 2ms and prevents a flood ping.
> Of course a user can just run multiple ping processes in parallel to
> overcome this limitation.
Real life DoS attacks from unpriviledged account are made with udp.pl 
and they are already quite damaging, so I do not believe that adding an
ICMP option would make the situation worse.

-- 
ciao,
Marco

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.devel

csiph-web