| 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" | 13:56 |
| ebarretto | jjohansen, georgiag ^ | 14:02 |
| 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:27 |
| ebarretto | georgiag, I think the docker deb package was modified to install the docker snap instead, much like chromium deb | 14:31 |
| ahasenack | in jammy docker.io still looks like the real thing | 14:46 |
| ahasenack | 150Mb or so for "installed-size" | 14:47 |
| ahasenack | but there is a docker snap, published by canonical | 14:47 |
| 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:50 |
| ahasenack | it probably doesn't know about snaps | 14:51 |
| jjohansen | indeed, that looks to be it | 14:53 |
| 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:55 |
| 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:57 |
| 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:58 |
| 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 | 14:59 |
| 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:00 |
| jjohansen | stacktoodeep: what does the command | 15:04 |
| jjohansen | snap list | 15:04 |
| jjohansen | show on each system, is it the same? | 15:04 |
| 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:08 |
| 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 | 16:10 |
| 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 | 17:01 |
| 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:18 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:32 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| ahasenack | there was a nice chart with all openssl options somewhere | 19:44 |
| ahasenack | meant as a joke | 19:44 |
| teward | hah | 19:46 |
| ahasenack | ah, here: https://smallstep.com/blog/if-openssl-were-a-gui/ | 19:46 |
| 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` :) | 19:47 |
| tomreyn | haha, lovely. this must have taken hours to craft. | 20:06 |
| 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:12 |
| sarnold | teward: yay, thanks for reporting back the -legacy switch | 20:13 |
| 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:14 |
| teward | E:NOHEADERS | 20:15 |
| teward | let me try something then | 20:15 |
| ahasenack | maybe also check line termination? | 20:15 |
| ahasenack | if it's DOS | 20:16 |
| ahasenack | (check EOL char is in my list of "if an error is weird") | 20:16 |
| 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:17 |
| teward | nope same error | 20:18 |
| teward | hmmmmmmmmmmmmm | 20:18 |
| teward | why does this *feel* like an OpenSSL bug | 20:18 |
| 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:19 |
| 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:20 |
| tomreyn | that's what i said ;) | 20:21 |
| tomreyn | teward: i was joking, and that's not helping, sorry. | 20:28 |
| teward[m] | no it's not i was about to smack you with a fish :p | 20:29 |
| tomreyn | good luck there. | 20:29 |
| 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:36 |
| 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 | 20:50 |
| enyc | sarnold: oh yes -- thankyou for pointing that out! | 21:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!