There are several examples of packages installing files to[snip]
/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.
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]
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/ .
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 thatPlease don't. There are already way too many debconf questions and this
the package installs in the sysctl.d/ directory.
Other than that, I think making ping not setuid is a great idea.ping is (generally) not setuid.
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
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:
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 anReal life DoS attacks from unpriviledged account are made with udp.pl
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 300 |
Nodes: | 16 (2 / 14) |
Uptime: | 22:08:12 |
Calls: | 6,707 |
Calls today: | 1 |
Files: | 12,239 |
Messages: | 5,351,989 |