[13:56] 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] This is a log from dmesg: [13:56] [ 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] jjohansen, georgiag ^ [14:27] 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] georgiag, I think the docker deb package was modified to install the docker snap instead, much like chromium deb [14:46] in jammy docker.io still looks like the real thing [14:47] 150Mb or so for "installed-size" [14:47] but there is a docker snap, published by canonical [14:50] docker has a default apparmor profile, from upstream, generated on the fly [14:50] https://github.com/moby/moby/blob/master/profiles/apparmor/template.go [14:50] the signal block bits are in line 27 [14:51] it probably doesn't know about snaps [14:53] indeed, that looks to be it [14:55] 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] first thing to check is if docker-default is loaded on both systems (it obviously is on the one) [14:57] and that one machine is running the dockerd snap [14:57] sudo aa-status [14:57] yep [14:57] because the sender of the signal is snap.docker.docker [14:57] because the sender of the signal is snap.docker.dockerd [14:57] not just dockerd [14:58] 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] that profile might also only exist if there is an actual docker daemon and/or container running [14:59] exist == be loaded [14:59] right [15:00] 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] stacktoodeep: what does the command [15:04] snap list [15:04] show on each system, is it the same? [16:08] 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] I've got docker installed from the official repo on the local machine, everything seems to work [16:10] ah, that would do it [17:01] 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] 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] 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] 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] 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] works fine in 20.04 but this one is a perfectly fine .p12 that is no longer able to be exported [19:27] i WONDER if this is because of default security level changes [19:27] i'm doing some testing [19:28] oof :) rc2, 40 bits.. that's not much more than rot13, heh [19:28] yeah that explains a lot i'll have to do some stuff to make this work [19:28] *does come chaos-fu* [19:32] thank you old 20.04 containers. [19:32] guess i'mma keep an old 20.04 container around for "older openssl" and open some major bugs at pfSense heh [19:39] sarnold: any easy way to find the current default encryption algos used for p12 files in OPenSSL? [19:39] hrm, I would have hated to do it, but there was precedent for keeping an openssl1.1 in jammy for such purposes. [19:40] 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] (for pfSense) [19:41] hmmm i wonder... *tests* [19:41] ahah! i just have to append -legacy to the arguments and it works (per OpenSSL manpage) [19:42] 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] ah, -legacy [19:43] so it's the providers change, not seclevel specifically [19:43] ahasenack -legacy indicates that OPenSSL upstream considers the algo "dead" [19:43] ahasenack correct [19:43] but since rc2-40-cbc provides *less* security than rot13 it's basically dead and should stay dead [19:43] so -legacy needed passed. That was a braintwister, and I only solved it by reading the upstream openssl manpages :\ [19:44] there was a nice chart with all openssl options somewhere [19:44] meant as a joke [19:46] hah [19:46] ah, here: https://smallstep.com/blog/if-openssl-were-a-gui/ [19:47] 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] I like the slider for `fd` :) [20:06] haha, lovely. this must have taken hours to craft. [20:12] 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] teward: yay, thanks for reporting back the -legacy switch [20:14] teward: hrmph. that "no start line" sounds vaguely familiar. try sticking another newline in there. [20:14] at the beginning or the end? [20:14] near the beginning, between the things that look like headers and the body [20:15] E:NOHEADERS [20:15] let me try something then [20:15] maybe also check line termination? [20:16] if it's DOS [20:16] (check EOL char is in my list of "if an error is weird") [20:17] shouldn't be DOS because openssl opened the binary pkcs12 and exported it itself from within a UNIX environment [20:17] also getting the *same* error when attempting to open the P12 as well (formerly worked on 20.04) [20:18] nope same error [20:18] hmmmmmmmmmmmmm [20:18] why does this *feel* like an OpenSSL bug [20:19] there are no openssl bugs, there is just bad input [20:19] tomreyn: given this file and its exported certs worked FINE in 20.04 I am going to beg to differ here [20:20] 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] that's what i said ;) [20:28] teward: i was joking, and that's not helping, sorry. [20:29] no it's not i was about to smack you with a fish :p [20:29] good luck there. [20:36] 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] 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] sarnold: oh yes -- thankyou for pointing that out!