Bug#1032298: tcpdump: apparmor blocks writing to stdout/stderr in lxd container [PATCH]
Hello, On Mon, 2023-04-10 at 17:11 +0200, Romain Francoise wrote: > Hi, > > On Fri, Mar 3, 2023 at 9:45 AM Gianfranco Costamagna > wrote: > > + # allow printing to stdout/stderr when inside a container > > + # (LP: #1667016) > > + /dev/pts/* rw, > > Thank you for reporting this issue, and the patch. While the change is > indeed trivial, giving unfettered rw access to /dev/pts/* it is a high > price to pay in terms of weakening the sandbox for an uncommon use > case. With access to /dev/pts, an attacker can access SSH sessions and > other terminals. > > Is there any way this could be fixed on the LXD side, or made more > restrictive? > Unfortunately there's no way to make it more restrictive. Ideally we needed to at least restrict this rule to only be allowed when tcpdump is running inside a container, but this is not available on AppArmor yet. Georgia
Bug#1032298: tcpdump: apparmor blocks writing to stdout/stderr in lxd container [PATCH]
Hello Romain On Mon, 10 Apr 2023 17:11:40 +0200 Romain Francoise wrote: Hi, On Fri, Mar 3, 2023 at 9:45 AM Gianfranco Costamagna wrote: > + # allow printing to stdout/stderr when inside a container > + # (LP: #1667016) > + /dev/pts/* rw, Thank you for reporting this issue, and the patch. While the change is indeed trivial, giving unfettered rw access to /dev/pts/* it is a high price to pay in terms of weakening the sandbox for an uncommon use case. With access to /dev/pts, an attacker can access SSH sessions and other terminals. Is there any way this could be fixed on the LXD side, or made more restrictive? Sadly I don't know and I'm not aware of any. If you want, you can directly discuss on https://bugs.launchpad.net/debian/+source/tcpdump/+bug/1667016 maybe we can find a better agreement on it? G.
Bug#1032298: tcpdump: apparmor blocks writing to stdout/stderr in lxd container [PATCH]
Hi, On Fri, Mar 3, 2023 at 9:45 AM Gianfranco Costamagna wrote: > + # allow printing to stdout/stderr when inside a container > + # (LP: #1667016) > + /dev/pts/* rw, Thank you for reporting this issue, and the patch. While the change is indeed trivial, giving unfettered rw access to /dev/pts/* it is a high price to pay in terms of weakening the sandbox for an uncommon use case. With access to /dev/pts, an attacker can access SSH sessions and other terminals. Is there any way this could be fixed on the LXD side, or made more restrictive? Regards, -- Romain Francoise https://people.debian.org/~rfrancoise/
Bug#1032298: tcpdump: apparmor blocks writing to stdout/stderr in lxd container [PATCH]
Source: tcpdump Version: 4.99.3-1 tags: patch Hello, we found in Ubuntu [1] (but there is no need to think that this isn't an issue with Debian too) that from a SSH session inside a container the output can't be shown, due to apparmor denying wirtes to /dev/pts/ (something that is tried by tcpdump). To reproduce, create an lxd container, launch it, and run tcpdump -i eth0 -nn not tcp port 22 If you ping now the ip of the container, you won't be able to see output even after pressing ctrl+c. The kernel logs will instead see lots of DENIED strings from apparmor [ 575.438349] audit: type=1400 audit(1676055298.285:164): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-peaceful-rattler_" profile="/usr/sbin/tcpdump" name="/dev/pts/1" pid=7922 comm="tcpdump" requested_mask="wr" denied_mask="wr" fsuid=100 ouid=100 The patch is trivial, and in Debian packaging: diff -Nru tcpdump-4.99.1/debian/usr.bin.tcpdump tcpdump-4.99.1/debian/usr.bin.tcpdump --- tcpdump-4.99.1/debian/usr.bin.tcpdump 2022-05-08 16:24:57.0 + +++ tcpdump-4.99.1/debian/usr.bin.tcpdump 2023-02-10 18:15:53.0 + @@ -64,6 +64,10 @@ /usr/bin/tcpdump mr, + # allow printing to stdout/stderr when inside a container + # (LP: #1667016) + /dev/pts/* rw, + # Site-specific additions and overrides. See local/README for details. #include } thanks for considering it Gianfranco [1] https://bugs.launchpad.net/ubuntu/+source/tcpdump/+bug/1667016 OpenPGP_signature Description: OpenPGP digital signature