Since rsyslog ships its own apparmor profile, I'm adding rsyslog as the
affected package and marking apparmor as invalid.
** Also affects: rsyslog (Ubuntu)
Importance: Undecided
Status: New
** Changed in: apparmor
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/2098148
Title:
Cannot log to bindmounted syslog socket within a container due to
rsyslogd profile
Status in AppArmor:
Invalid
Status in rsyslog package in Ubuntu:
New
Bug description:
We run haproxy in a container using podman. Haproxy wants to log
directly to syslog. To accomplish this we create
/var/lib/haproxy/dev/log via this rsyslogd configuration:
"$AddUnixListenSocket /var/lib/haproxy/dev/log". Then we bind mount
/var/lib/haproxy/dev/log to /dev/log in the haproxy container. Finally
we configure haproxy to log to that syslog socket via: "log /dev/log
local0". The expecation is that haproxy running in a container will be
able to log to rsyslogd running on the host. Unfortunately this breaks
with this audit message:
kernel: audit: type=1400 audit(1739405468.722:168):
apparmor="DENIED" operation="sendmsg" class="file" info="Failed name
lookup - disconnected path" error=-13 profile="rsyslogd"
name="var/lib/haproxy/dev/log" pid=60555 comm="haproxy"
requested_mask="r" denied_mask="r" fsuid=0 ouid=0
This is odd because the rsyslogd profile shouldn't be applied to our
container. apparmor_status seems to confirm that it isn't. It shows
these relevant processes and their profiles:
/usr/local/sbin/haproxy (60450) containers-default-0.57.4-apparmor1
/usr/local/sbin/haproxy (60555) containers-default-0.57.4-apparmor1
/usr/sbin/rsyslogd (60180) rsyslogd
In #ubuntu-security sarnold mentions that "apparmor is applying a
*cross check* between both policies because this is a socket, similar
to signals" and suggested applying flags=(attach_disconnected) to the
profile in /etc/apparmor.d/usr.sbin.rsyslogd. Doing so then running
`apparmor_parser -r /etc/apparmor.d/usr.sbin.rsyslogd` then restarting
both rsyslogd.service and the haproxy container gets the syslog logs
flowing.
It does seem like containers should be able to log to a rsyslogd
running outside of their namespace on the host, but I'm not entirely
sure what the security implications are for applying this globally to
all rsyslogd profiles. In any case it was suggested I file this bug so
that further discussion could be tracked.
To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/2098148/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
