| === chris14_ is now known as chris14 | ||
| === ChanServ changed the topic of #ubuntu-security to: Twitter: @ubuntu_sec || https://usn.ubuntu.com || https://wiki.ubuntu.com/SecurityTeam || https://wiki.ubuntu.com/Security/Features || Community: leosilva | ||
| ahasenack | hi, just going to float an idea here, brainstorm a bit | 18:33 |
|---|---|---|
| ahasenack | I'm working on the apparmor profile for rsyslog, and all its subpackages (rsyslog-mysql, -pgsql, etc) | 18:33 |
| ahasenack | originally I thought about parsing the rsyslog.conf file, checking for om<plugins>, and then generating an apparmor profile snippet for it dynamically | 18:34 |
| ahasenack | and call that script in ExecStartPre | 18:34 |
| ahasenack | that works | 18:34 |
| ahasenack | but then I thought it would perhaps be easier and less magical to have each subpackage (rsyslog-mysql, -pgsql, etc) to include the apparmor profile snippet it needs to work | 18:34 |
| ahasenack | and have the main rsyslog apparmor profile just use "include if exist" for all these possibilities | 18:35 |
| ahasenack | this looks like it will work too, and I can still use the script for some corner cases perhaps | 18:35 |
| ahasenack | but how do I reload the rsyslog apparmor profile (which has the include) when, say, rsyslog-mysql is installed? There are many ways, | 18:35 |
| ahasenack | I thought of using a trigger on /etc/apparmor.d/rsyslog/, the directory I chose to place these snippets in | 18:36 |
| ahasenack | I don't know if there is precedence for that | 18:36 |
| ahasenack | another way is of course to reload the profile in postinst, but I don't see a way to use dh_apparmor for that, and I fear having to do that handling manually when dh_apparmor does it so nicely | 18:36 |
| teward | uh, question to the security team, and a major one: default 22.04/22.10 installations are now saying you need an ESM subscription to update Universe regardless of ESM or not. I think that's a usability flaw? see the notes in https://askubuntu.com/a/1452498/10616 where this is a current problem | 19:04 |
| teward | if nobody can just go `sudo apt update` without it blaring thayt it needs ESM Apps enabled then Ubuntu is no longer "free to use" if ESM is now required, and that's its own security snafu | 19:05 |
| mdeslaur | teward: huh? no, universe is still universe | 19:06 |
| teward | mdeslaur: ther's been a flurry of posts on Ask Ubuntu about 22.10 new installs when running apt update saying "The following apps need ESM Apps enabled to get updates" | 19:07 |
| teward | for things in universe like imagemagick which SHOULD be updated anyways | 19:07 |
| mdeslaur | teward: because those updates aren't in universe, they are in esm only | 19:08 |
| mdeslaur | teward: no community volunteer updated imagemagick in universe | 19:08 |
| teward | mdeslaur: i think then that Security needs to make a notice, or Canonical, that *some* applications are only updated in ESM Apps while some are not there and have no updates in Universe | 19:08 |
| teward | the point is it's for more than just imagemagick from what people're complaining about | 19:08 |
| mdeslaur | teward: I don't understand, we've never supported universe | 19:08 |
| teward | mdeslaur: i think the confusion is ESM vs. non-ESM again and how that impacts the current non-ESM rotation of systems | 19:09 |
| teward | and which do you actually need for proper security patches/updates | 19:09 |
| mdeslaur | teward: the short answer: if you don't buy ESM, nothing has changed | 19:09 |
| teward | either way it seems like an issue when the system whines and doesn't explain it. | 19:09 |
| mdeslaur | if you do buy ESM, you get more updates | 19:09 |
| teward | or enroll in free Ubuntu Pro for end-users at home (5 systems free) | 19:10 |
| teward | i'l make a post on Ask Ubuntu to try and stop the flurry of questions | 19:11 |
| mdeslaur | I'd try and explain esm and ubuntu pro, but I am completely confused myself | 19:11 |
| teward | mdeslaur: i think i know it | 19:11 |
| teward | Ubuntu Pro is what Ubuntu Advantage used to be, esm-apps and esm-imfra are part of the ESM program that is offered as part of Ubuntu Pro (previously UA) | 19:12 |
| teward | i've had back and forth wtih Canonical Marketing and Tech about this back when ESM was first a chaos | 19:12 |
| mdeslaur | so you understand it better than me | 19:12 |
| teward | mdeslaur: yeah, only marginally | 19:12 |
| mdeslaur | so I guess Ubuntu Pro isn't an Advantage anymore? ;) | 19:14 |
| sdeziel | is there anything that prevents someone from subscribing to ESM to get updated source packages to then propose them as community provided updates to -universe? | 19:18 |
| mdeslaur | nope | 19:18 |
| sdeziel | alright, I needed to ask ;) | 19:18 |
| ahasenack | that's the centos way, no? | 19:18 |
| mdeslaur | sdeziel: hehe :) | 19:19 |
| teward | sdeziel: yeah there's nothing stopping it, except security review because I see a lot of full version bumps in esm-apps and such that bring the concerns in :P | 19:19 |
| teward | and you know how SRUs can be so expand that by 10000% for sec review | 19:19 |
| mdeslaur | hrm, there shouldn't be full version bumps there | 19:19 |
| teward | though i will have to consider that for torbrowser-launcher - incompatible changes with no way to nitpick the differences between 0.35 ane 0.36 | 19:20 |
| teward | well i say 'full version bumps' and I mean MRE-style bumps | 19:20 |
| mdeslaur | except for certain exceptions | 19:20 |
| mdeslaur | it should be the same as the maintenance we do in the archive | 19:20 |
| teward | i'm running on one coffee and 5 hours sleep so :P | 19:20 |
| mdeslaur | With Ubuntu Pro, you will gain access to a second coffee and two more hours of sleep! | 19:25 |
| * arraybolt3 tries to imagine the amount of work needed to backport Ubuntu Pro to Universe... | 19:27 | |
| mainek00n | Hi, I was looking at OVAL (https://security-metadata.canonical.com/oval/oci.com.ubuntu.focal.cve.oval.xml.bz2) and noticed a problem. | 19:33 |
| mainek00n | The problem is such a case... https://pastebin.ubuntu.com/p/2wWXmRz2Tv/ | 19:33 |
| mainek00n | test(oval:com.ubuntu.focal:tst:201245420000370) for linux-meta-azure-5.15 references object(oval:com.ubuntu.focal:obj: 201245420000360) for linux-meta-azure-5.13 . | 19:33 |
| mainek00n | Is OVAL generation failing? | 19:33 |
| ebarretto | hi mainek00n, let me take a look, but we are planning on removing meta and signed kernels from oval | 19:41 |
| ebarretto | mainek00n, what exactly is the issue? | 19:42 |
| teward | mdeslaur: until I see that guarantee from Mark and a check in my hands for those coffees (i'm up to 5 a day now) i don't believe it :P | 19:47 |
| mdeslaur | hehehe :) | 19:49 |
| mainek00n | ebarretto, I have asked these questions before... (https://irclogs.ubuntu.com/2023/01/20/%23ubuntu-security.html) | 19:56 |
| mainek00n | If the Ubuntu CVE Tracker and future OVALs do not define vulnerabilities for -signed and -meta packages, how do I manage vulnerabilities in packages with -signed and -meta packages such as linux-signed-azure-5.13 and linux-meta-azure-5.13? | 19:56 |
| teward | mdeslaur: do you know if it's possible to disable apt notifications about `esm-*` so it's not default stating info that will confuse new users? I have a feeling it's some kind of apt config option | 19:59 |
| mdeslaur | teward: sorry, no idea | 19:59 |
| teward | no worries i'll just email -devel | 19:59 |
| teward | and get my answer ;P | 19:59 |
| mdeslaur | doesn't the message say how to disable it? I thought it used to | 20:00 |
| teward | it does on the boot up login shell message | 20:00 |
| teward | the apt messages are new | 20:00 |
| mdeslaur | https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1992026 | 20:01 |
| -ubottu:#ubuntu-security- Launchpad bug 1992026 in ubuntu-advantage-tools (Ubuntu) "Ubuntu Pro APT integration is a bit much" [Critical, In Progress] | 20:01 | |
| ebarretto | mainek00n, linux-meta-azure-5.13 and linux-signed-azure-5.13 comes from linux-azure-5.13, you will have only the linux-azure-5.13 check | 20:02 |
| ebarretto | mainek00n, linux-meta-* and linux-signed-* are not real source packages, so we don't track them in our tracker, they are instead generated on top of actual source packages such as I mentioned above | 20:03 |
| teward | mdeslaur: thanks, I"ve made a comment with my opinion from the "Community Observation" that I do with my CC hat on in general as my own personal recommendation to tone down the apt integration and stuff, it's excessive and causing user strife | 20:03 |
| mdeslaur | teward: thanks | 20:04 |
| mainek00n | ebarretto, For example, suppose the running kernel binary package is linux-image-5.15.0-1026-aws and the source package of this package is linux-signed-aws-5.15. In this case, is it correct to consider linux-signed-aws-5.15 as linux-aws-5.15 and detect the vulnerability? | 20:07 |
| ebarretto | mainek00n, you only need to check linux-image-5.15.0-1026-aws | 20:15 |
| ebarretto | mainek00n, you need to care about the actual binaries that are created from a source package. You won't have linux-aws-5.15 in your dpkg output | 20:16 |
| mainek00n | ebarretto, But there is no entry in the Ubuntu CVE Tracker for linux-image-5.15.0-1026-aws, right? | 20:17 |
| ebarretto | mainek00n, the Ubuntu CVE Tracker tracks source packages, not binaries | 20:18 |
| ebarretto | mainek00n, for OVAL we track binaries from source packages | 20:18 |
| ebarretto | it can be confusing, but there's a translation from one to the other | 20:18 |
| ebarretto | so for our own sake the Ubuntu CVE Tracker has source package names only, because you will patch a source, and verify that source code. But when we are checking running systems, then we need to check actual binary names and from that we get the binaries for each source package | 20:19 |
| ebarretto | for that* | 20:20 |
| mainek00n | ebarretto, But if future OVALs don't define -signed or -meta entries for the Source Package, won't it be impossible to check down to the binary package? | 20:28 |
| arraybolt3 | teward: Pretty sure there's a "sudo pro configure" something that will fix it. | 20:30 |
| arraybolt3 | "sudo pro config set apt_news=false" | 20:30 |
| ebarretto | mainek00n, the binary from all of them boils down to some linux-image-... binaries, so they will be covered. The thing with the current state of linux-meta and linux-signed is that they create false positives right now because different linux-meta-* source packages might generate a binary with the same name | 20:36 |
| mainek00n | ebarretto, For example, consider the following machine: https://pastebin.ubuntu.com/p/yfr66fNvr2/ | 20:51 |
| mainek00n | From the results of the command, the running binary package is linux-image-5.15.0-58-generic and its source package is linux-signed. | 20:51 |
| mainek00n | Can't I just replace linux-signed with linux and use the Ubuntu CVE Tracker information to detect the vulnerability in the linux package? | 20:51 |
| mainek00n | Do I have to look at the OVAL and check the source package and the binary package of the source package as well? | 20:51 |
| mainek00n | What if I can only use the information from the Ubuntu CVE Tracker? | 20:51 |
| ebarretto | mainek00n, linux-image-5.15.0-58-generic comes from linux: https://launchpad.net/ubuntu/+source/linux/5.15.0-58.64 As I said, linux-signed is not an actual source package, hopefully someone can explain it better than me. | 20:58 |
| ebarretto | mainek00n, perhaps I'm not understanding what is your current issue. I know you contribute (perhaps maintain?) to some golang packages that contain CVE information. Are you hitting something specific while doing it? | 20:59 |
| ebarretto | we are open to suggestions and improvements on our OVAL for sure. The meta thing is something currently in the works as we know users hitting some false positives | 21:01 |
| teward | mainek00n: i think we have to trace to a more basic question than you're asking first, which is "What is the difference between source packages and binary packages". If you understand the distinction then you can figure out from that which to use (CVE tracker vs. OVAL) to identify your vulnerable packages, etc. | 21:08 |
| teward | with the exception of the meta things being worked on of course | 21:08 |
| teward | and with -signed that doesn't actually *exist* and isn't a source package, so how you're equating linux-image-5.15.0-58-generic to its source package is flawed | 21:09 |
| teward | oh wait a second | 21:10 |
| teward | ebarretto: i think there's an issue then at how the source is shown in apt in this case | 21:10 |
| teward | ebarretto: wrt linux-image-5.15.0-58-generic the source `Source: ` output in apt show on the package *is* linux-signed | 21:10 |
| teward | even if that's a metapackage or a Provides: line, that might be part of the confusion here | 21:10 |
| teward | mainek00n: better question is: how're you determining the "Source" in your example? | 21:11 |
| teward | are you basing that off of `apt show` information or similar? | 21:11 |
| teward | ebarretto: see https://pastebin.ubuntu.com/p/3JcPV4QGYD/ which might be the 'source' confusion here | 21:12 |
| teward | `apt show` output | 21:12 |
| teward | ebarretto: it wouldn't be that the linux source package has a Provides for linux-signed in it somewhere would it? | 21:13 |
| teward | or some other bit that confuses apt vs. how we actually determine the Source packages of a given binary? | 21:13 |
| ebarretto | teward, yeah, that goes in line with: https://launchpad.net/ubuntu/+source/linux-signed/5.15.0-58.64 ... so same binary, two different "sources" perhaps. sbeattie perhaps you can again re-clarify the -meta and -signed packages. | 21:15 |
| teward | ebarretto: i think that's the confusion then, because "same binary, different sources" which is confusing how they're parsing APT data | 21:16 |
| teward | which may explain the confusion between linux-signed and straight linux | 21:16 |
| ebarretto | this confuses me every time too | 21:17 |
| teward | because it seems that linux-signed is the only one visible for that binary package in apt (for Jammy anyways) | 21:17 |
| teward | it may be that mainek00n simply has to assume that for linux-{signed,meta} to refer to the base linux source pkg instead | 21:17 |
| teward | but again this is one of those confusing points | 21:18 |
| teward | (this said I don't rely on just OVAL to determine things, I pay Rapid7 for IVM which has an agent that parses Ubuntu CVE data, OVAL, etc. and determines the proper package matchups, don't ask me how they do it I just know they do xD) | 21:18 |
| mainek00n | ebarretto, teward: I understood from reading scripts/generate_oval and scripts/kernel_lib.py that linux-signed* and linux-meta* in OVAL are generated from linux*. https://git.launchpad.net/ubuntu-cve-tracker/tree/scripts/kernel_lib.py#n129 | 21:28 |
| ebarretto | mainek00n, exactly | 21:29 |
| teward | which goes back to what ebarretto and I were talking about - same binary package produced from multiple sources | 21:30 |
| teward | so "source" might be a misleading thing at points | 21:31 |
| mainek00n | So, I was thinking, when detecting vulnerabilities, is it OK for linux-signed* and linux-meta* to use the data from the source linux*? | 21:36 |
| teward | until sbeattie chimes in on -meta I think for -signed the answer could be "yes" but don't quote me on that | 21:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!