tcpdump in lxd container: apparmor blocks writing to stdout/stderr
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
tcpdump (Debian) |
New
|
Unknown
|
|||
tcpdump (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Undecided
|
Unassigned | ||
Jammy |
Fix Released
|
Undecided
|
Unassigned | ||
Kinetic |
Fix Released
|
Undecided
|
Unassigned | ||
Lunar |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[ Impact ]
Users that run tcpdump from an SSH session inside a container cannot
see the output because tcpdump tries to write to /dev/pts/, which is
not allowed by the AppArmor policy.
This upload fixes the bug by allowing read/write access to the devices
under /dev/pts/ in the AppArmor policy.
[ Test Plan ]
Create a lxd container. In this example we are using version 20.04,
but the issue is reproducible in all versions.
lxc launch ubuntu:20.04
SSH into the container and run the following command
tcpdump -i eth0 -nn not tcp port 22
In a different window, ping the IP of the container. Notice that
there's no output on the tcpdump window, even after you press Ctrl+C.
Check the kernel logs and you will see a DENIED message like the one
below
[ 575.438349] audit: type=1400 audit(167605529
[ Where problems could occur ]
The SRU broadens the AppArmor policy for tcpdump, so if there was
ever an exploit on tcpdump that allowed a malicious agent to
write to /dev/pts/*, this could be used to write to the
terminal. With that said, the risk of this hapenning is low.
[ Other Info ]
The SRU for bionic, focal, jammy, kinetic and lunar can be found in
https:/
Tcpdump from inside the container needs to be updated to use the
version with the fix in the AppArmor policy.
-------
[ubuntu 16.04, lxd 2.0.8 or 2.0.9, tcpdump 4.7.4 or 4.9.0]
If you ssh into an lxd container as a normal user, and inside that container run "sudo tcpdump", the tcpdump process is blocked from writing to stdout/stderr. This appears to be due to apparmor: disabling apparmor for tcpdump makes the problem go away.
ln -s /etc/apparmor.
Note: this is a different bug from #1641236. In that bug, the user did "lxc exec <container> bash" to get a shell in the container; the stdout fd was being passed from the outer host to the container. But in this case, the pty is being created entirely inside the container by sshd.
Details copied from https:/
# Steps to reproduce
1. Create two Ubuntu 16.04 lxd containers, one privileged, one not.
2. ssh into each one, and then use `sudo -s` to get root. (Do not use `lxc exec` because of issue #1641236)
3. Inside one run `tcpdump -i eth0 -nn not tcp port 22`, and ping from the other.
tcpdump in the privileged container works just fine.
tcpdump in the unprivileged container does not show any output. But if I run strace on it I see errors attempting to access stdout and stderr:
~~~
ioctl(1, TCGETS, 0x7fff97c8d680) = -1 ENOTTY (Inappropriate ioctl for device)
...
write(2, "tcpdump: verbose output suppress"..., 75) = -1 EACCES (Permission denied)
write(2, "listening on eth0, link-type EN1"..., 74) = -1 EACCES (Permission denied)
~~~
This is very weird. Even more weird: the following command *does* capture packets:
~~~
tcpdump -i eth0 -nn -w foo.pcap
~~~
The file foo.pcap grows. This proves it's nothing to do with network capture perms.
But the following command shows no output:
~~~
tcpdump -r foo.pcap -nn
~~~
And again it's because it can't write to stdout:
~~~
fstat(1, 0x7ffe2fb5eb10) = -1 EACCES (Permission denied)
read(3, "", 4096) = 0
write(1, "14:34:30.618180 IP6 fe80::c609:6"..., 1740) = -1 EACCES (Permission denied)
~~~
I had originally thought this was to do with capabilities. But if I run `capsh --print` inside both containers, they both have `cap_net_raw` and `cap_net_admin`. In fact, the unprivileged container has two additional capabilities! (`cap_mac_override` and `cap_mac_admin`)
So now I suspect that apparmor is at fault.
#### dmesg
dmesg output generated by the following steps:
* start tcpdump
* wait 5 seconds
* send 1 ping from other side
* wait 5 seconds
* stop tcpdump
~~~
[429020.685987] audit: type=1400 audit(148777433
[429020.686000] audit: type=1400 audit(148777433
[429020.686013] audit: type=1400 audit(148777433
[429020.686022] audit: type=1400 audit(148777433
[429020.716725] device eth0 entered promiscuous mode
[429020.741308] audit: type=1400 audit(148777433
[429020.741330] audit: type=1400 audit(148777433
[429021.716785] audit: type=1400 audit(148777434
[429030.630448] audit: type=1400 audit(148777434
[429030.630543] audit: type=1400 audit(148777434
[429030.630555] audit: type=1400 audit(148777434
[429030.630565] audit: type=1400 audit(148777434
[429030.630574] audit: type=1400 audit(148777434
[429030.630584] audit: type=1400 audit(148777434
[429030.630593] audit: type=1400 audit(148777434
[429030.630687] device eth0 left promiscuous mode
~~~
#### privileged container
~~~
$ lxc config show srv1-campus1
name: srv1-campus1
profiles:
- br-cnd11
config:
security.
volatile.
volatile.
volatile.
volatile.
volatile.
volatile.
devices:
root:
path: /
type: disk
ephemeral: false
root@srv1:~# capsh --print
Current: = cap_chown,
Bounding set =cap_chown,
Securebits: 00/0x0/1'b0
secure-noroot: no (unlocked)
secure-
secure-keep-caps: no (unlocked)
uid=0(root)
gid=0(root)
groups=0(root)
~~~
#### unprivileged container
~~~
$ lxc config show srv2-campus1
name: srv2-campus1
profiles:
- br-cnd11
config:
volatile.
volatile.
volatile.
volatile.
volatile.
volatile.
devices:
root:
path: /
type: disk
ephemeral: false
root@srv2:~# capsh --print
Current: = cap_chown,
Bounding set =cap_chown,
Securebits: 00/0x0/1'b0
secure-noroot: no (unlocked)
secure-
secure-keep-caps: no (unlocked)
uid=0(root)
gid=0(root)
groups=0(root)
~~~
tags: | added: canonical-bootstack |
description: | updated |
tags: |
added: verification-done verification-done-bionic verification-done-focal verification-done-jammy verification-done-kinetic removed: verification-needed verification-needed-bionic verification-needed-focal verification-needed-jammy verification-needed-kinetic |
Changed in tcpdump (Debian): | |
status: | Unknown → New |
Status changed to 'Confirmed' because the bug affects multiple users.