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

Groups > linux.debian.kernel > #85064 > unrolled thread

Bug#1092591: linux-image-6.12.6-amd64: SO_PEERSEC fails with ENOPROTOOPT with AppArmor enabled

Started byGuido Berhoerster <guido+debian@berhoerster.name>
First post2025-01-09 14:10 +0100
Last post2025-01-17 19:30 +0100
Articles 6 — 4 participants

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

Contents

  Bug#1092591: linux-image-6.12.6-amd64: SO_PEERSEC fails with ENOPROTOOPT with AppArmor enabled Guido Berhoerster <guido+debian@berhoerster.name> - 2025-01-09 14:10 +0100
    Bug#1092591: linux-image-6.12.6-amd64: SO_PEERSEC fails with ENOPROTOOPT with AppArmor enabled Guido Berhoerster <guido+debian@berhoerster.name> - 2025-01-16 14:30 +0100
      Bug#1092591: linux-image-6.12.6-amd64: SO_PEERSEC fails with ENOPROTOOPT with AppArmor enabled Bastian Blank <waldi@debian.org> - 2025-01-17 19:30 +0100
        Bug#1092591: linux-image-6.12.6-amd64: SO_PEERSEC fails with ENOPROTOOPT with AppArmor enabled Guido Berhoerster <guido+debian@berhoerster.name> - 2025-01-20 13:10 +0100
          Bug#1092591: linux-image-6.12.6-amd64: SO_PEERSEC fails with ENOPROTOOPT with AppArmor enabled Salvatore Bonaccorso <carnil@debian.org> - 2025-01-31 07:00 +0100
    Processed: Re: Bug#1092591: linux-image-6.12.6-amd64: SO_PEERSEC  fails with ENOPROTOOPT with AppArmor enabled "Debian Bug Tracking System" <owner@bugs.debian.org> - 2025-01-17 19:30 +0100

#85064 — Bug#1092591: linux-image-6.12.6-amd64: SO_PEERSEC fails with ENOPROTOOPT with AppArmor enabled

FromGuido Berhoerster <guido+debian@berhoerster.name>
Date2025-01-09 14:10 +0100
SubjectBug#1092591: linux-image-6.12.6-amd64: SO_PEERSEC fails with ENOPROTOOPT with AppArmor enabled
Message-ID<K30sp-6TAG-3@gated-at.bofh.it>
Package: src:linux
Version: 6.12.6-1
Severity: normal
X-Debbugs-Cc: guido+debian@berhoerster.name


SO_PEERSEC always fails with ENOPROTOOPT instead of reporting the peer's
security context even if AppArmor is enabled and in enforcing mode.
This affects e.g. DBus, a minimal example for reproducing the issue is
included below:

---- 8< ----
/*
 * compile:
 * gcc -std=c99 -o atest atest.c
 *
 * run:
 * ./atest
 * socat - UNIX-CONNECT:atest.sock
 */
#define	_GNU_SOURCE

#include <err.h>
#include <errno.h>
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <unistd.h>

#define	SOCK_PATH	"atest.sock"

int
main(int argc, char *argv[]) {
	int		connfd, listenfd;
	struct sockaddr_un addr = { .sun_family = AF_UNIX };
	char		buf[NAME_MAX];
	socklen_t	len = NAME_MAX;

	if ((unlink(SOCK_PATH) < 0) && (errno != ENOENT)) {
		err(1, "unlink");
	}

	if ((listenfd = socket(AF_UNIX, SOCK_STREAM, 0)) < 0) {
		err(1, "socket");
	}

	strncpy(addr.sun_path, SOCK_PATH, sizeof(addr.sun_path) - 1);
	if (bind(listenfd, (const struct sockaddr *)&addr, sizeof (addr)) < 0) {
		err(1, "bind");
	}

	if (listen(listenfd, 10) < 0) {
		err(1, "listen");
	}

	for (;;) {
		if ((connfd = accept(listenfd, NULL, NULL)) < 0) {
			err(1, "accept");
		}
		if (getsockopt(connfd, SOL_SOCKET, SO_PEERSEC, &buf, &len) < 0) {
			warn("getsockopt SO_PEERSEC failed");
		} else {
			printf("%.*s\n", (int)len, buf);
		}
		close(connfd);
	}

	exit(0);
}
---- >8 ----

-- Package-specific info:
** Version:
Linux version 6.12.6-amd64 (debian-kernel@lists.debian.org) (x86_64-linux-gnu-gcc-14 (Debian 14.2.0-11) 14.2.0, GNU ld (GNU Binutils for Debian) 2.43.50.20241215) #1 SMP PREEMPT_DYNAMIC Debian 6.12.6-1 (2024-12-21)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.12.6-amd64 root=UUID=c47f1501-8cab-4407-9584-e4afd073a2f1 ro quiet console=tty1 console=ttyS0

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: QEMU
product_name: Standard PC (Q35 + ICH9, 2009)
product_version: pc-q35-7.2
chassis_vendor: QEMU
chassis_version: pc-q35-7.2
bios_vendor: EFI Development Kit II / OVMF
bios_version: 0.0.0
board_vendor: LinuxContainers
board_name: Incus
board_version: pc-q35-7.2

** Loaded modules:
intel_rapl_msr
intel_rapl_common
kvm_amd
binfmt_misc
ccp
kvm
nls_ascii
9p
nls_cp437
vfat
fat
virtio_gpu
9pnet_virtio
crct10dif_pclmul
ghash_clmulni_intel
virtio_dma_buf
sha512_ssse3
9pnet
drm_shmem_helper
sha256_ssse3
sha1_ssse3
iTCO_wdt
netfs
drm_kms_helper
aesni_intel
intel_pmc_bxt
iTCO_vendor_support
gf128mul
crypto_simd
watchdog
vmw_vsock_virtio_transport
cryptd
vmw_vsock_virtio_transport_common
pcspkr
virtio_balloon
vsock
virtio_input
virtio_console
button
evdev
joydev
sg
cfg80211
serio_raw
rfkill
drm
efi_pstore
configfs
nfnetlink
efivarfs
qemu_fw_cfg
virtio_rng
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
xhci_pci
xhci_hcd
ahci
sd_mod
libahci
libata
virtio_scsi
usbcore
scsi_mod
virtio_net
psmouse
crc32_pclmul
i2c_i801
crc32c_intel
net_failover
i2c_smbus
lpc_ich
failover
scsi_common
usb_common

** PCI devices:
not available

** USB devices:
not available


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.12.6-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 linux-image-6.12.6-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.145
ii  kmod                                    33+20240816-2
ii  linux-base                              4.11

Versions of packages linux-image-6.12.6-amd64 recommends:
ii  apparmor  3.1.7-1+b3

Versions of packages linux-image-6.12.6-amd64 suggests:
pn  debian-kernel-handbook  <none>
pn  firmware-linux-free     <none>
ii  grub-efi-amd64          2.12-5
pn  linux-doc-6.12          <none>

Versions of packages linux-image-6.12.6-amd64 is related to:
pn  firmware-amd-graphics      <none>
pn  firmware-atheros           <none>
pn  firmware-bnx2              <none>
pn  firmware-bnx2x             <none>
pn  firmware-brcm80211         <none>
pn  firmware-cavium            <none>
pn  firmware-cirrus            <none>
pn  firmware-intel-graphics    <none>
pn  firmware-intel-misc        <none>
pn  firmware-intel-sound       <none>
pn  firmware-ipw2x00           <none>
pn  firmware-ivtv              <none>
pn  firmware-iwlwifi           <none>
pn  firmware-libertas          <none>
pn  firmware-marvell-prestera  <none>
pn  firmware-mediatek          <none>
pn  firmware-misc-nonfree      <none>
pn  firmware-myricom           <none>
pn  firmware-netronome         <none>
pn  firmware-netxen            <none>
pn  firmware-nvidia-graphics   <none>
pn  firmware-qcom-soc          <none>
pn  firmware-qlogic            <none>
pn  firmware-realtek           <none>
pn  firmware-samsung           <none>
pn  firmware-siano             <none>
pn  firmware-ti-connectivity   <none>
pn  xen-hypervisor             <none>

-- no debconf information

[toc] | [next] | [standalone]

#85164

FromGuido Berhoerster <guido+debian@berhoerster.name>
Date2025-01-16 14:30 +0100
Message-ID<K5y6B-9mFR-1@gated-at.bofh.it>
In reply to#85064
From my superficial reading of the code the error seems to come from here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/security/apparmor/lsm.c?h=v6.12.6#n1313

It appears that AppArmor SO_PEERSEC support for unix domain sockets bound to a filesystem path name is missing from the upstream kernel and is only enabled as a side effect of a patch distributed with AppArmor: https://gitlab.com/apparmor/apparmor/-/blob/692e6850ba90582105713a683bed753bad696aab/kernel-patches/v4.17/0002-apparmor-af_unix-mediation.patch
Ubuntu kernels contain a rebased variant of the patch which is likely why SO_PEERSEC works on Ubuntu.

The reason I stumbled on this issue is that we (ubports-team) are currently packaging lomiri-content-hub which implicitly relies on SO_PEERSEC through the DBus daemon to get the AppArmor profile of a process requesting to export a file. Without this it is not possible to confine Lomiri/Ubuntu Touch apps running on Debian.
-- 
Guido Berhoerster

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

#85177

FromBastian Blank <waldi@debian.org>
Date2025-01-17 19:30 +0100
Message-ID<K5Zgt-9HwT-3@gated-at.bofh.it>
In reply to#85164
Control: tags -1 upstream
Controm: forwarded -1 https://gitlab.com/apparmor/apparmor/-/blob/692e6850ba90582105713a683bed753bad696aab/kernel-patches/v4.17/0002-apparmor-af_unix-mediation.patch

On Thu, Jan 16, 2025 at 02:16:18PM +0100, Guido Berhoerster wrote:
> From my superficial reading of the code the error seems to come from here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/security/apparmor/lsm.c?h=v6.12.6#n1313

Yes, it does.

> It appears that AppArmor SO_PEERSEC support for unix domain sockets bound to a filesystem path name is missing from the upstream kernel and is only enabled as a side effect of a patch distributed with AppArmor: https://gitlab.com/apparmor/apparmor/-/blob/692e6850ba90582105713a683bed753bad696aab/kernel-patches/v4.17/0002-apparmor-af_unix-mediation.patch
> Ubuntu kernels contain a rebased variant of the patch which is likely why SO_PEERSEC works on Ubuntu.

This comes from the addition of apparmor_unix_stream_connect.  Without
it the peer context is never set.

> The reason I stumbled on this issue is that we (ubports-team) are currently packaging lomiri-content-hub which implicitly relies on SO_PEERSEC through the DBus daemon to get the AppArmor profile of a process requesting to export a file. Without this it is not possible to confine Lomiri/Ubuntu Touch apps running on Debian.

So someone needs to properly submit this support upstream.

Bastian

-- 
Too much of anything, even love, isn't necessarily a good thing.
		-- Kirk, "The Trouble with Tribbles", stardate 4525.6

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

#85232

FromGuido Berhoerster <guido+debian@berhoerster.name>
Date2025-01-20 13:10 +0100
Message-ID<K6YLn-aroU-7@gated-at.bofh.it>
In reply to#85177
Am 17.01.25 um 19:16 schrieb Bastian Blank:
> Control: tags -1 upstream
> Controm: forwarded -1 https://gitlab.com/apparmor/apparmor/-/blob/692e6850ba90582105713a683bed753bad696aab/kernel-patches/v4.17/0002-apparmor-af_unix-mediation.patch
> 
> On Thu, Jan 16, 2025 at 02:16:18PM +0100, Guido Berhoerster wrote:
>> From my superficial reading of the code the error seems to come from here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/security/apparmor/lsm.c?h=v6.12.6#n1313
> 
> Yes, it does.
> 
>> It appears that AppArmor SO_PEERSEC support for unix domain sockets bound to a filesystem path name is missing from the upstream kernel and is only enabled as a side effect of a patch distributed with AppArmor: https://gitlab.com/apparmor/apparmor/-/blob/692e6850ba90582105713a683bed753bad696aab/kernel-patches/v4.17/0002-apparmor-af_unix-mediation.patch
>> Ubuntu kernels contain a rebased variant of the patch which is likely why SO_PEERSEC works on Ubuntu.
> 
> This comes from the addition of apparmor_unix_stream_connect.  Without
> it the peer context is never set.
> 
>> The reason I stumbled on this issue is that we (ubports-team) are currently packaging lomiri-content-hub which implicitly relies on SO_PEERSEC through the DBus daemon to get the AppArmor profile of a process requesting to export a file. Without this it is not possible to confine Lomiri/Ubuntu Touch apps running on Debian.
> 
> So someone needs to properly submit this support upstream.

From my understanding the AppArmor project has kept this as an out-of-tree
patch because it will have to be reworked when/if LSM stacking lands
(see [1]). I don't follow kernel development closely but LSM-stacking has
been under discussion for more than a decade now with no end in sight.
Would you consider including this patch into Debian? The patch itself is
very likely to be maintained by Ubuntu as they also make use of SO_PEERSEC.


[1] https://lwn.net/Articles/804906/

-- 
Guido Berhoerster

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

#85327

FromSalvatore Bonaccorso <carnil@debian.org>
Date2025-01-31 07:00 +0100
Message-ID<KaSel-dexM-17@gated-at.bofh.it>
In reply to#85232
Hi

On Mon, Jan 20, 2025 at 01:06:00PM +0100, Guido Berhoerster wrote:
> Am 17.01.25 um 19:16 schrieb Bastian Blank:
> > Control: tags -1 upstream
> > Controm: forwarded -1 https://gitlab.com/apparmor/apparmor/-/blob/692e6850ba90582105713a683bed753bad696aab/kernel-patches/v4.17/0002-apparmor-af_unix-mediation.patch
> > 
> > On Thu, Jan 16, 2025 at 02:16:18PM +0100, Guido Berhoerster wrote:
> >> From my superficial reading of the code the error seems to come from here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/security/apparmor/lsm.c?h=v6.12.6#n1313
> > 
> > Yes, it does.
> > 
> >> It appears that AppArmor SO_PEERSEC support for unix domain sockets bound to a filesystem path name is missing from the upstream kernel and is only enabled as a side effect of a patch distributed with AppArmor: https://gitlab.com/apparmor/apparmor/-/blob/692e6850ba90582105713a683bed753bad696aab/kernel-patches/v4.17/0002-apparmor-af_unix-mediation.patch
> >> Ubuntu kernels contain a rebased variant of the patch which is likely why SO_PEERSEC works on Ubuntu.
> > 
> > This comes from the addition of apparmor_unix_stream_connect.  Without
> > it the peer context is never set.
> > 
> >> The reason I stumbled on this issue is that we (ubports-team) are currently packaging lomiri-content-hub which implicitly relies on SO_PEERSEC through the DBus daemon to get the AppArmor profile of a process requesting to export a file. Without this it is not possible to confine Lomiri/Ubuntu Touch apps running on Debian.
> > 
> > So someone needs to properly submit this support upstream.
> 
> >From my understanding the AppArmor project has kept this as an out-of-tree
> patch because it will have to be reworked when/if LSM stacking lands
> (see [1]). I don't follow kernel development closely but LSM-stacking has
> been under discussion for more than a decade now with no end in sight.
> Would you consider including this patch into Debian? The patch itself is
> very likely to be maintained by Ubuntu as they also make use of SO_PEERSEC.

WE had a short discussion on that in our team. BAsically, we won't
pick a change which is not going to land in upstream. That means the
support needs to go upstream in one or the other acceptable form from
Apparmor upstream.

I see and understand the problem you mention that in the related work
upstream there is ongoing discussion since years.

Regards,
Salvatore

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

#85176 — Processed: Re: Bug#1092591: linux-image-6.12.6-amd64: SO_PEERSEC fails with ENOPROTOOPT with AppArmor enabled

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2025-01-17 19:30 +0100
SubjectProcessed: Re: Bug#1092591: linux-image-6.12.6-amd64: SO_PEERSEC fails with ENOPROTOOPT with AppArmor enabled
Message-ID<K5Zgt-9HwT-7@gated-at.bofh.it>
In reply to#85064
Processing control commands:

> tags -1 upstream
Bug #1092591 [src:linux] linux-image-6.12.6-amd64: SO_PEERSEC fails with ENOPROTOOPT with AppArmor enabled
Added tag(s) upstream.

-- 
1092591: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1092591
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

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

csiph-web