[13:56] <stacktoodeep> I'm having issues with apparmour blocking signals to docker containers in Ubuntu 22. I'm a bit baffled as I have two machines with fresh installs of Ubuntu, and docker installed via apt, but this only happens on one machine. Any recommendations on how to solve this?
[13:56] <stacktoodeep> This is a log from dmesg:
[13:56] <stacktoodeep> [ 3909.261432] audit: type=1400 audit(1662471984.785:48): apparmor="DENIED" operation="signal" profile="docker-default" pid=3310 comm="runc" requested_mask="receive" denied_mask="receive" signal=term peer="snap.docker.dockerd"
[14:02] <ebarretto> jjohansen, georgiag ^ 
[14:27] <georgiag> stacktoodeep: sorry, I'm not familiar on how docker apparmor policies work, but I found weird that you installed docker via apt and the peer of the log is "snap.docker.dockerd"
[14:31] <ebarretto> georgiag, I think the docker deb package was modified to install the docker snap instead, much like chromium deb
[14:46] <ahasenack> in jammy docker.io still looks like the real thing
[14:47] <ahasenack> 150Mb or so for "installed-size"
[14:47] <ahasenack> but there is a docker snap, published by canonical
[14:50] <ahasenack> docker has a default apparmor profile, from upstream, generated on the fly
[14:50] <ahasenack> https://github.com/moby/moby/blob/master/profiles/apparmor/template.go
[14:50] <ahasenack> the signal block bits are in line 27
[14:51] <ahasenack> it probably doesn't know about snaps
[14:53] <jjohansen> indeed, that looks to be it
[14:55] <jjohansen> so I don't know why this is happening on only one machine, but the issue looks to be that the docker-default profile doesn't know about snap.docker.dockerd
[14:57] <jjohansen> first thing to check is if docker-default is loaded on both systems (it obviously is on the one)
[14:57] <ahasenack> and that one machine is running the dockerd snap
[14:57] <jjohansen> sudo aa-status
[14:57] <jjohansen> yep
[14:57] <ahasenack> because the sender of the signal is snap.docker.docker
[14:57] <ahasenack> because the sender of the signal is snap.docker.dockerd
[14:57] <ahasenack> not just dockerd
[14:58] <jjohansen> and that is the next thing to look for in the output of aa-status, does the machine that is not failing have snap.docker.dockerd in its aa-status output
[14:59] <ahasenack> that profile might also only exist if there is an actual docker daemon and/or container running
[14:59] <ahasenack> exist == be loaded
[14:59] <jjohansen> right
[15:00] <stacktoodeep> jjohansen yup, on the working machine it does not have snap.docker.dockerd but it does have specific ones for each running container (eg.  /usr/local/bin/node (66090) docker-default)
[15:04] <jjohansen> stacktoodeep: what does the command
[15:04] <jjohansen> snap list
[15:04] <jjohansen> show on each system, is it the same?
[16:08] <stacktoodeep> jjohansen: On the working box docker is not via snap . The broken box is local, the working one is on AWS - so my assumption is that due to the different repos AWS instances use out of the box it didn't pull in the snap.
[16:10] <stacktoodeep> I've got docker installed from the official repo on the local machine, everything seems to work
[16:10] <jjohansen> ah, that would do it
[17:01] <ahasenack> you said the broken box is local, and then that you have upstream docker installed on the local machine and that it is working? Those statements are conflicting
[19:18] <teward> pfsmorigo: sarnold: has anyone reported problems in Ubuntu 22.04 with openssl being *unable* to extract certs from or even open pkcs12 files?
[19:26] <sarnold> teward: the closest I think I've heard is that the openssl command changed which subcommand works with (some type of file that I've forgotten) -- it's possible that what you're trying to do may have changed to a different subcommand
[19:26] <teward> sarnold: no, i don't think so, i think this is a change to 22.04's security defaults for sig algos.  Which some PKCS12 exporters still use 'old' (pfSense)
[19:27] <teward> digital envelope routines:inner_evp_generic_fetch:unsupported:../crypto/evp/evp_fetch.c:349:Global default library context, Algorithm (RC2-40-CBC : 0)
[19:27] <teward> works fine in 20.04 but this one is a perfectly fine .p12 that is no longer able to be exported
[19:27] <teward> i WONDER if this is because of default security level changes
[19:27] <teward> i'm doing some testing
[19:28] <sarnold> oof :) rc2, 40 bits.. that's not much more than rot13, heh
[19:28] <teward> yeah that explains a lot i'll have to do some stuff to make this work
[19:28] <teward> *does come chaos-fu*
[19:32] <teward> thank you old 20.04 containers.
[19:32] <teward> guess i'mma keep an old 20.04 container around for "older openssl" and open some major bugs at pfSense heh
[19:39] <teward> sarnold: any easy way to find the current default encryption algos used for p12 files in OPenSSL?
[19:39] <sbeattie> hrm, I would have hated to do it, but there was precedent for keeping an openssl1.1 in jammy for such purposes.
[19:40] <teward> sbeattie: well, in this case, i just need to know the default encryption algos and such used and then can suggest that the p12s be using a stronger mechanism
[19:40] <teward> (for pfSense)
[19:41] <teward> hmmm i wonder... *tests*
[19:41] <teward> ahah! i just have to append -legacy to the arguments and it works (per OpenSSL manpage)
[19:42] <ahasenack> teward: sarnold is it that openssl 3 (jammy) no longer ships rc2-40, or just that it was disabled via the seclevel setting? If it's the latter, the user should be able to lower the seclevel just for that one operation, no?
[19:42] <ahasenack> ah, -legacy
[19:43] <ahasenack> so it's the providers change, not seclevel specifically
[19:43] <teward[m]> ahasenack -legacy indicates that OPenSSL upstream considers the algo "dead"
[19:43] <teward[m]> ahasenack correct
[19:43] <teward[m]> but since rc2-40-cbc provides *less* security than rot13 it's basically dead and should stay dead
[19:43] <teward[m]> so -legacy needed passed.  That was a braintwister, and I only solved it by reading the upstream openssl manpages :\
[19:44] <ahasenack> there was a nice chart with all openssl options somewhere
[19:44] <ahasenack> meant as a joke
[19:46] <teward> hah
[19:46] <ahasenack> ah, here: https://smallstep.com/blog/if-openssl-were-a-gui/
[19:47] <ahasenack> and the note at the bottom: "This is incomplete. It covers about 80% of one corner of OpenSSL’s functionality. The certificate policy options have a lot more knobs that I didn’t include."
[19:47] <ahasenack> I like the slider for `fd` :)
[20:06] <tomreyn> haha, lovely. this must have taken hours to craft.
[20:12] <teward> sarnold: oh i found a bug in SOMETHING related to 22.04's network manager and openvpn... "Sep  6 16:11:49 tau-volantis nm-openvpn[53867]: OpenSSL: error:0480006C:PEM routines::no start line" even though the PEM files have start lines.  That's an unusual problem.
[20:13] <sarnold> teward: yay, thanks for reporting back the -legacy switch
[20:14] <sarnold> teward: hrmph. that "no start line" sounds vaguely familiar. try sticking another newline in there.
[20:14] <teward> at the beginning or the end?
[20:14] <sarnold> near the beginning, between the things that look like headers and the body
[20:15] <teward> E:NOHEADERS
[20:15] <teward> let me try something then
[20:15] <ahasenack> maybe also check line termination?
[20:16] <ahasenack> if it's DOS
[20:16] <ahasenack> (check EOL char is in my list of "if an error is weird")
[20:17] <teward> shouldn't be DOS because openssl opened the binary pkcs12 and exported it itself from within a UNIX environment
[20:17] <teward> also getting the *same* error when attempting to open the P12 as well (formerly worked on 20.04)
[20:18] <teward> nope same error
[20:18] <teward> hmmmmmmmmmmmmm
[20:18] <teward> why does this *feel* like an OpenSSL bug
[20:19] <tomreyn> there are no openssl bugs, there is just bad input
[20:19] <teward> tomreyn: given this file and its exported certs worked FINE in 20.04 I am going to beg to differ here
[20:20] <teward> openssl on the command line can read the files fine when they're passed in.  but network-manager-openvpn when passing options to the backend is failing...
[20:21] <tomreyn> that's what i said ;)
[20:28] <tomreyn> teward: i was joking, and that's not helping, sorry.
[20:29] <teward[m]> no it's not i was about to smack you with a fish :p
[20:29] <tomreyn> good luck there.
[20:36] <enyc> hrrm, is  thunderbird in ubuntu lagging behind on security ... ?  .11  not .13 ....?  debian is updated.  Might be missing from display on  packages.ubuntu.com  of course.
[20:50] <sarnold> enyc: it looks like some packages are being prepped in https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa/+packages -- I don't know where these are in the update preperation process, so maybe don't run these in production or anything
[21:14] <enyc> sarnold: oh yes -- thankyou for pointing that out!