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

Groups > linux.debian.bugs.dist > #1026222 > unrolled thread

Bug#970827: ping: socket: Operation not permitted while apt dist-upgrade is in progress

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#970827: ping: socket: Operation not permitted while apt dist-upgrade is in progress Witold Baryluk <witold.baryluk@gmail.com> - 2020-09-24 04:30 +0200
    Bug#970827: ping: socket: Operation not permitted while apt dist-upgrade is in progress Noah Meyerhans <noahm@debian.org> - 2020-09-24 05:00 +0200
      Bug#970827: ping: socket: Operation not permitted while apt dist-upgrade is in progress Witold Baryluk <witold.baryluk@gmail.com> - 2020-09-24 21:00 +0200

#1026222 — Bug#970827: ping: socket: Operation not permitted while apt dist-upgrade is in progress

Package: iputils-ping
Version: 3:20200821-2
Severity: normal
X-Debbugs-Cc: witold.baryluk@gmail.com


I noticed this weird thing:

1) ping is working
2) start apt dist-upgrade
3) at some point new ping stops working with ping: socket: Operation not permited
  for minutes.
4) apt dist-upgrade finishes
5) ping works again


That is not nice.

Looking at dpkg.log I see this:

2020-09-24 01:34:40 upgrade iputils-ping:amd64 3:20190709-3 3:20200821-2
2020-09-24 01:34:40 status half-configured iputils-ping:amd64 3:20190709-3
2020-09-24 01:34:40 status unpacked iputils-ping:amd64 3:20190709-3
2020-09-24 01:34:40 status half-installed iputils-ping:amd64 3:20190709-3
2020-09-24 01:34:40 status unpacked iputils-ping:amd64 3:20200821-2
...
...
2020-09-24 01:45:28 configure iputils-ping:amd64 3:20200821-2 <none>
2020-09-24 01:45:28 status unpacked iputils-ping:amd64 3:20200821-2
2020-09-24 01:45:28 status half-configured iputils-ping:amd64 3:20200821-2
2020-09-24 01:45:28 status installed iputils-ping:amd64 3:20200821-2



So I suspect there is something critical in configure that prevent ping
from working during this intermitent period.


Wish it could be fixed somehow.


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.7.0-1-amd64 (SMP w/32 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages iputils-ping depends on:
ii  libc6        2.31-3
ii  libcap2      1:2.43-1
ii  libcap2-bin  1:2.43-1
ii  libidn2-0    2.3.0-1

iputils-ping recommends no packages.

iputils-ping suggests no packages.

-- no debconf information

[toc] | [next] | [standalone]

#1026223

Control: severity -1 minor

> 1) ping is working
> 2) start apt dist-upgrade
> 3) at some point new ping stops working with ping: socket: Operation not permited
>   for minutes.
> 4) apt dist-upgrade finishes
> 5) ping works again

The ping process requires the ability to open a raw network socket,
which is a privileged operation.  The ping binary contained within the
package is completely unprivileged, so when it's initially installed it
can only be executed by the root user or some other user that has
retained the cap_net_raw capability.  Later in the installation process,
the package's post-install script tries to add the cap_net_raw
file-based capability to the binary as that's the safest (least
privileged) way to grant users the ability to run ping.  If that fails,
probably because the system is configured with some unusual filesystem
that doesn't support file-based capabilities, then the script sets the
suid bit on the binary, granting unprivileged users the ability to run
ping with a slight reduction in the security posture.

I'm not sure of a practical way to avoid this situation.  If .deb files
could contain files with capabilities set on them, then this would
likely improve the situation for most users, but I believe it's still
the case that this isn't possible.

You can see the script in question at
https://salsa.debian.org/debian/iputils/-/blob/master/debian/iputils-ping.postinst

noah

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

#1026308

Thanks Noah.

I was not sure if ping is using suid as in the past, or the capabilities.

You are of course right:

root@debian:~# ls -l `which ping`
-rwxr-xr-x 1 root root 77432 Aug 23 19:08 /usr/bin/ping
root@debian:~# getcap `which ping`
/usr/bin/ping cap_net_raw=ep
root@debian:~#


This looks like a limitation that would only be possible to solve by
dpkg and extending tar / cpio probably.

From what I found it is possible to do this with tar and
--xattrs-include='security.capability'  when packing and unpacking.

There is some hacky non-standard patches for cpio,
https://github.com/initlove/cpio/commit/531cabc88e9ecdc3231fad6e4856869baa9a91ef
, but afaik not upstreamed.
And even more hacky support in kernel for initramfs uses:
https://lists.gnu.org/archive/html/bug-cpio/2019-05/msg00001.html

I didn't see any real updates on this topic, last one is from middle of 2019.

I agree it is hard.

Cheers.

On Thu, 24 Sep 2020 at 02:51, Noah Meyerhans <noahm@debian.org> wrote:
>
> Control: severity -1 minor
>
> > 1) ping is working
> > 2) start apt dist-upgrade
> > 3) at some point new ping stops working with ping: socket: Operation not permited
> >   for minutes.
> > 4) apt dist-upgrade finishes
> > 5) ping works again
>
> The ping process requires the ability to open a raw network socket,
> which is a privileged operation.  The ping binary contained within the
> package is completely unprivileged, so when it's initially installed it
> can only be executed by the root user or some other user that has
> retained the cap_net_raw capability.  Later in the installation process,
> the package's post-install script tries to add the cap_net_raw
> file-based capability to the binary as that's the safest (least
> privileged) way to grant users the ability to run ping.  If that fails,
> probably because the system is configured with some unusual filesystem
> that doesn't support file-based capabilities, then the script sets the
> suid bit on the binary, granting unprivileged users the ability to run
> ping with a slight reduction in the security posture.
>
> I'm not sure of a practical way to avoid this situation.  If .deb files
> could contain files with capabilities set on them, then this would
> likely improve the situation for most users, but I believe it's still
> the case that this isn't possible.
>
> You can see the script in question at
> https://salsa.debian.org/debian/iputils/-/blob/master/debian/iputils-ping.postinst
>
> noah
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web