| rlee287 | How are you applying the profile to the container? | 00:00 |
|---|---|---|
| clarkb | I'm not doing anything explicit to apply the profile to the container. The container is run by podman which I think applies its own profile | 00:00 |
| sarnold | clarkb: aha okay, so it's not just aa-genprof made something silly, but something i gotta think harder about ;) | 00:01 |
| rlee287 | I don't know what podman's default profiles are but you might find the info at https://gitlab.com/apparmor/apparmor/-/wikis/docker to be somewhat helpful | 00:01 |
| clarkb | rlee287: apparmor_status shows these mappings: /usr/local/sbin/haproxy (60450) containers-default-0.57.4-apparmor1 and /usr/sbin/rsyslogd (60180) rsyslogd for processes in enforce mode | 00:02 |
| clarkb | oh and /usr/local/sbin/haproxy (60555) containers-default-0.57.4-apparmor1 which matches the pid in the log line pasted above | 00:02 |
| clarkb | haproxy has two process a control process and then the child process that handles all the network connections. Seems the child is the one trying to log to the syslog socket | 00:03 |
| rlee287 | haproxy running in the container is thus running under the containers-default-0.57.4-apparmor1 profile | 00:04 |
| rlee287 | Is rsyslog running solely outside the container or is there a different instance of rsyslog inside the container | 00:05 |
| clarkb | there is a single rsyslogd process and its parent is init 1 running outside the container in the host system | 00:05 |
| sarnold | clarkb, rlee287; my current guess, but it's hard for me to track it down in the sources, is that apparmor is applying a *cross check* between both policies because this is a socket, similar to signals | 00:05 |
| sarnold | clarkb, rlee287, and thus for haproxy to send a message to rsyslogd, the rsyslogd policy has to be allowed to receive it from rsyslogd in addition to haproxy being able to send it to rsyslogd | 00:06 |
| rlee287 | Well the other fun thing that's going on here is the disconnected path log info | 00:06 |
| rlee287 | See the wiki page I linked above for some more info on that | 00:06 |
| sarnold | clarkb, rlee287, and then the different namespaces kick dirt in everybody's eyes, and this object is guaranteed to be disconnected from one or both of the namespaces :) | 00:06 |
| rlee287 | Yep :upside_down_smile: | 00:07 |
| sarnold | clarkb, rlee287, if I'm right, it'll be enough to add the flags=(attach_disconnected) to the rsyslogd profile, reload it, put a clove of garlic on the keyboard, and try again | 00:07 |
| clarkb | I did try that though its possible I did it incorrectly or maybe I need to restart the haproxy processes and the rsyslogd processes in addition to reloading the rsyslogd profile so all the processes so the new stuff? | 00:08 |
| clarkb | "profile rsyslogd /usr/sbin/rsyslogd {" should be come "profile rsyslogd /usr/sbin/rsyslogd flags=(attach_disconnected) {" ? then apparmor_parser -r /etc/apparmor.d/usr.sbin.rsyslogd then finally restart rsyslog and haproxy? | 00:09 |
| clarkb | the podman container profile does appear to already set the attach_disconnected flag as is documented by the docker wiki | 00:10 |
| clarkb | I'll try this again just to make sure I'm not doing anything wrong to break the fixup | 00:11 |
| clarkb | hey that did it | 00:13 |
| clarkb | so either I typoed somethign the first time I tried or restarting all the services was necessary | 00:13 |
| clarkb | this was helpful thanks! I guess I should ask is this something that should go into the packaged profile for rsyslog or is this considered enough of a corner case and enoguh of a security risk that I should just update things locally and accept the delta? | 00:14 |
| clarkb | for the vast majority of services we configure docker or podman to log to journald which only works if processes write to stdout. haproxy is a bit of a corner case in that it wants to log to a socket or a udp address and do fire and forget syslog directly. But it also seems reasonable to want to have containers log to host syslog if it doesn't undermine the security apparmor is trying to | 00:17 |
| clarkb | enforce | 00:17 |
| rlee287 | I'll pass this conversation on to the AppArmor team | 00:17 |
| rlee287 | (as a member of said team) | 00:17 |
| clarkb | that would be great thanks! | 00:17 |
| rlee287 | But attach_disconnected is a hacky workaround that has lived in AppArmor for far longer than we would have liked, and it keeps popping up in container contexts like this | 00:18 |
| rlee287 | We're currently working out a design for object delegation which should allow more fine-grained object passing around to resolve cases like this | 00:18 |
| clarkb | one last question: if I want to make this edit on the haproxy servers do I have to edit /etc/apparmor.d/usr.sbin.rsyslogd in place because the flags apply to the profile as a whole or is there some way to make the edit in /etc/apparmor.d/local/usr.sbin.rsyslogd? | 00:20 |
| clarkb | though now that I look at /etc/apparmor.d/usr.sbin.rsyslogd more closely the line to include /etc/apparmor.d/local/usr.sbin.rsyslogd is commetned out so I'd have to edit that either way | 00:20 |
| clarkb | or are #include lines evaluated and not comments? | 00:21 |
| sarnold | clarkb: awesome! | 00:23 |
| sarnold | clarkb: a bug report is a good idea, if you've got time / ability / etc | 00:23 |
| sarnold | clarkb: argh. afaik this change has to be done in the "main" /etc/apparmor.d/usr.sbin.rsyslogd profile. it'd be nice if it were otherwise. :( | 00:24 |
| clarkb | should the report go to https://bugs.launchpad.net/apparmor ? | 00:24 |
| clarkb | and thanks for confirming the location of the edit | 00:24 |
| sarnold | heh, there's too many places to report bugs :) I was thinking of https://bugs.launchpad.net/ubuntu/+source/apparmor/+filebug but your link might be less annoying | 00:27 |
| rlee287 | clarkb: for historical reasons, #include lines are evaluated even though # is usually the character for comments | 00:27 |
| sarnold | "it's just like cpp! people are familiar with that" :) oof | 00:28 |
| rlee287 | y e p | 00:28 |
| sarnold | apologies for that | 00:28 |
| clarkb | heh cpp doesn't do //include :) | 00:28 |
| sarnold | lol | 00:29 |
| sarnold | this reminds me of one of my earlier ubuntu bug reports https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1163129 | 00:30 |
| -ubottu:#ubuntu-security- Launchpad bug 1244578 in lightdm (Ubuntu Vivid) "lightdm-session runs xrdb with -nocpp option" [Medium, Fix Released] [duplicate: 1163129] | 00:30 | |
| clarkb | we hit another issue with noble and podman and apparmor where `podman kill -s HUP` doesn't work. The reason appear to be that the container profile podman applies has an explicit list of allowed signals that can be sent | 00:32 |
| sarnold | odd, I wonder why they did that? | 00:32 |
| clarkb | HUP isn't one of them. I filed/updated issues against libpod and upstream yesterday for that. But working around that is easy with kill(1) as it just works | 00:32 |
| clarkb | sarnold: I think they didn't realize the bidirectional behavior you pointed out above exists | 00:32 |
| clarkb | so they allowedany signal on one side but then limit it for the other and boom | 00:33 |
| clarkb | but we got through that simply rewriting things to lookup the pid for the process in the container from podman then run kill -s HUP against it instead | 00:33 |
| clarkb | https://bugs.launchpad.net/ubuntu/+source/libpod/+bug/2089664 is the issue with pointers to upstream stuff | 00:34 |
| -ubottu:#ubuntu-security- Launchpad bug 2089664 in libpod (Ubuntu) "podman AppArmor policy still too restrictive" [Undecided, Confirmed] | 00:34 | |
| sarnold | oh man, no traction since november? :( | 00:37 |
| sarnold | clarkb: https://github.com/containers/common/pull/2228#pullrequestreview-2613556531 hopefully that'll help move it along | 00:40 |
| -ubottu:#ubuntu-security- Pull 2228 in containers/common "update apparmor profile to allow podman to send any signal" [Open] | 00:40 | |
| clarkb | sarnold: rlee287 https://bugs.launchpad.net/apparmor/+bug/2098148 | 00:43 |
| -ubottu:#ubuntu-security- Launchpad bug 2098148 in AppArmor "Cannot log to bindmounted syslog socket within a container due to rsyslogd profile" [Undecided, New] | 00:43 | |
| rlee287 | ack | 00:43 |
| clarkb | thanks again for all the help this was really useful for figuring out how to get this working | 00:43 |
| sarnold | lovely bug report, thanks :) | 00:44 |
| === nishit_0 is now known as nishit_ | ||
| === Juesto is now known as Juest | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!