Thanks, Simon, I must have missed it.
When I use --mode=non-interactive on lxc and -l on tcpdump, I don't see the
issue at all.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
@georgiag, the behaviour changes when you tell tcpdump to do line
buffering (`-l`).
--
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
I tried reproducing the issue on a 22.04 VM with a 22.04 container and I
got some weird behavior, not consistent to what was reported in the
comments, so I appreciate if anyone can also take a look.
What I found is that I can only reproduce the issue when running tcpdump
in
name="apparmor/.null" is used to remove access to an already open file
that is being inherited and should no longer be available. Whether
because policy doesn't allow it. AppArmor can't just close the file
because the fd for the file might have meaning and closing the file
would free up the fd
A few comments and explanations:
> 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.
The rule for /dev/ only allows reading the directory listing of /dev/.
It doesn't say or allow anything
The above analysis is true for SSH, but, I realise it's different for
the PTY passed in by lxc exec.
So my analysis is true maybe, but I am going to move this SSH fix over
to Bug #1667016 so this bug can stay open for the general PTY/buffering
issue.
There is a gap in my explanation of: It's not
** Changed in: apparmor (Ubuntu)
Status: Invalid => 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
** Changed in: tcpdump (Ubuntu)
Importance: Undecided => High
--
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
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
> apparmor_parser -R /etc/apparmor.d
-R means to unload profiles, in this case all profiles in
/etc/apparmor.d/. That's probably a bit ;-) too much...
I'd guess you want to unload only the tcpdump profile, which would be done with
apparmor_parser -R /etc/apparmor.d/usr.bin.tcpdump
An
Ahyes, that fixes things on Ubuntu/Jammy as well:
mkdir -p /etc/apparmor.d/disable
# (did not exist, over here)
ln -s /etc/apparmor.d/usr.bin.tcpdump /etc/apparmor.d/disable
# (note, no sbin, but bin)
apparmor_parser -R /etc/apparmor.d
# (this is indeed needed, instead of an apparmor restart)
This affects Ubuntu 18.04 LXD containers as well.
As per previous mentions for tcpdump:
a) using script does not change anything
b) connecting via ssh and not lxc exec has no effect
c) disabling apparmour for tcpdump does work:
i.e.
/bin/ln -s /etc/apparmor.d/usr.sbin.tcpdump
I've been able to re-create this using fresh install of Ubuntu 18.04
without using LXC or LXD, but just using network namespaces.
Setup 2 namespaces with IPVLAN:
ip netns add ns1
ip link add name ipv1 link enp0s3 type ipvlan mode l3s
ip link set dev ipv1 netns ns1
ip netns exec ns1 ip addr add
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: apparmor (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.
On Tue, Jan 31, 2017 at 11:34:43AM +0100, Christian Brauner wrote:
> I've reproduced this on a fresh standard xenial instance with LXD
> 2.0.8 and also on a xenial instance with a patched glibc that reports
> ENODEV on ttyname{_r}() on a pty fd that does not exist:
>
> root@x:~#
I've reproduced this on a fresh standard xenial instance with LXD
2.0.8 and also on a xenial instance with a patched glibc that reports
ENODEV on ttyname{_r}() on a pty fd that does not exist:
root@x:~# ./enodev_on_pty_in_different_namespace
ttyname(): The pty device might exist in a different
Marking the LXD side of this as Invalid since there's unfortunately
nothing we can really do about this.
** Changed in: lxd (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in
Getting openpty called in the container would solve a lot of problems
for us but it's not possible to do in a safe way as it'd effectively
rely on the container's filesystem which the container user can change
or fake at will, allowing for attacks on the host's C library and LXD
itself.
** Also
18 matches
Mail list logo
