Note: This affects SSH as well.. not only lxc exec. There is a currently
marked duplicate bug about the SSH part in Bug #1667016
This still persits on focal now. To workaround this for me I have to
*both* use tcpdump with -l (line buffered mode) *and* pipe the output to
cat. You also want to redirect stderr otherwise it's silently lost.
# tcpdump -lni o-hm0 2>&1|cat
The apparmor errors I get are:
[ 6414.508990] audit: type=1400 audit(1666764106.013:360): apparmor="DENIED"
operation="file_inherit"
namespace="root//lxd-juju-5062b7-2-lxd-3_<var-snap-lxd-common-lxd>"
profile="/usr/sbin/tcpdump" name="/dev/pts/2" pid=187936 comm="tcpdump"
requested_mask="wr" denied_mask="wr" fsuid=1000000 ouid=1001000
I have determined the cause, which is that tcpdump is one of the few programs
with its own restrictive apparmor profile (/etc/apparmor.d/usr.sbin.tcpdump).
As part of that it locks down /dev to read-only:
> /dev/ r,
However that also means /dev/pts is read-only, hence the error above
denies write access.
There is an abstraction #include <abstractions/consoles> which adds
access to /dev/pts and other console outputs. It's included also in the
profile for usr.bin.man.
Including this abstraction resolves the issue for me. I'll upload a
patch.
** Also affects: tcpdump (Ubuntu)
Importance: Undecided
Status: New
** Changed in: apparmor (Ubuntu)
Status: Confirmed => Invalid
** Changed in: tcpdump (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1641236
Title:
Confined processes inside container cannot fully access host pty
device passed in by lxc exec
Status in apparmor package in Ubuntu:
Invalid
Status in lxd package in Ubuntu:
Invalid
Status in tcpdump package in Ubuntu:
Confirmed
Bug description:
Now that AppArmor policy namespaces and profile stacking is in place,
I noticed odd stdout buffering behavior when running confined
processes via lxc exec. Much more data stdout data is buffered before
getting flushed when the program is confined by an AppArmor profile
inside of the container.
I see that lxd is calling openpty(3) in the host environment, using
the returned fd as stdout, and then executing the command inside of
the container. This results in an AppArmor denial because the file
descriptor returned by openpty(3) originates outside of the namespace
used by the container.
The denial is likely from glibc calling fstat(), from inside the
container, on the file descriptor associated with stdout to make a
decision on how much buffering to use. The fstat() is denied by
AppArmor and glibc ends up handling the buffering differently than it
would if the fstat() would have been successful.
Steps to reproduce (using an up-to-date 16.04 amd64 VM):
Create a 16.04 container
$ lxc launch ubuntu-daily:16.04 x
Run tcpdump in one terminal and generate traffic in another terminal (wget
google.com)
$ lxc exec x -- tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
<Packet dump>
47 packets captured
48 packets received by filter
1 packet dropped by kernel
<ctrl-c>
Note that everything above <Packet dump> was printed immediately
because it was printed to stderr. <Packet dump>, which is printed to
stdout, was not printed until you pressed ctrl-c and the buffers were
flushed thanks to the program terminating. Also, this AppArmor denial
shows up in the logs:
audit: type=1400 audit(1478902710.025:440): apparmor="DENIED"
operation="getattr" info="Failed name lookup - disconnected path"
error=-13 namespace="root//lxd-x_<var-lib-lxd>"
profile="/usr/sbin/tcpdump" name="dev/pts/12" pid=15530 comm="tcpdump"
requested_mask="r" denied_mask="r" fsuid=165536 ouid=165536
Now run tcpdump unconfined and take note that <Packet dump> is printed
immediately, before you terminate tcpdump. Also, there are no AppArmor denials.
$ lxc exec x -- aa-exec -p unconfined -- tcpdump -i eth0
...
Now run tcpdump confined but in lxc exec's non-interactive mode and note that
<Package dump> is printed immediately and no AppArmor denials are present.
(Looking at the lxd code in lxd/container_exec.go, openpty(3) is only called in
interactive mode)
$ lxc exec x --mode=non-interactive -- tcpdump -i eth0
...
Applications that manually call fflush(stdout) are not affected by
this as manually flushing stdout works fine. The problem seems to be
caused by glibc not being able to fstat() the /dev/pts/12 fd from the
host's namespace.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1641236/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
