| Unit193 | That CVE (https://github.com/yt-dlp/yt-dlp/security/advisories/GHSA-79w7-vh3h-8g4j) looks more Windows based. | 00:06 |
|---|---|---|
| === chris14_ is now known as chris14 | ||
| rbasak | mdeslaur or sarnold maybe: please could you see if you have an opinion on bug 2065915 or could otherwise help out? It seems like a couple of community contributors are trying to fix up quite a bit of a mess in relation to apparmor, possibly related to userns. I'm also not sure what to make of it from an SRU review perspective and would appreciate your opinion. | 12:43 |
| -ubottu:#ubuntu-security- Bug 2065915 in tellico (Ubuntu Noble) "[SRU] Fix hard coded path in apparmor profiles." [Undecided, New] https://launchpad.net/bugs/2065915 | 12:43 | |
| rbasak | Or jjohansen maybe? ^ | 12:44 |
| mdeslaur | hrm https://launchpadlibrarian.net/738546122/plasma-welcome_5.27.11-0ubuntu3_5.27.11-0ubuntu4.diff.gz | 12:47 |
| mdeslaur | that looks weird, I don't now what that is solving | 12:48 |
| mdeslaur | related bug: https://bugs.launchpad.net/ubuntu/+source/akregator/+bug/2064492 | 12:48 |
| -ubottu:#ubuntu-security- Launchpad bug 2064492 in tellico (Ubuntu Noble) "failed to execvp: /usr/lib/aarch64-linux-gnu/qt5/libexec/QtWebEngineProcess" [High, Fix Committed] | 12:48 | |
| mdeslaur | I'll let sarnold and jjohansen comment | 12:49 |
| rbasak | AIUI, it's trying to solve that bug you linked. See comments in the 915 bug. | 12:49 |
| rbasak | Thanks | 12:49 |
| === Jozo_ is now known as Jozo | ||
| === jozo_ is now known as Jozo | ||
| georgiag | rbasak: it seems that the packages from the SRU use userns and to make it work they created a profile based on what was done for plasmashell https://git.launchpad.net/apparmor/tree/profiles/apparmor.d/plasmashell which doesn't really make sense for those applications. it seems that what they actually wanted in the first place was an unconfined profile similar to epiphany https://git.launchpad.net/apparmor/tree/profiles | 13:22 |
| georgiag | /apparmor.d/epiphany which is what the SRU is proposing... now we have to decide what's worse: fix only the @{multiarch} aspect and leave an apparmor policy that is overly broad and doesn't make sense for the package but confined nonetheless or use the flags=(unconfined) which I believe should have been the initial policy and makes it consistent with what we're doing in the apparmor package but now makes the | 13:22 |
| georgiag | application unconfined | 13:22 |
| rbasak | georgiag: ah that's a helpful analysis thanks. | 13:24 |
| rbasak | If the multiarch paths are fixed, then that would be a minimal safe change that we can have confidence in. The risk is that there are other code paths not being exercised that will continue to fail I suppose, but it might be reasonable to wait for such a bug report before deciding to go fully unconfined. | 13:27 |
| rbasak | OTOH if we have a few examples of where the confinement is a problem in other cases, then that would provide some justification towards dropping the confinement altogether across these packages. | 13:27 |
| rbasak | Perhaps that will help make a decision? If the security team reaches a (documented) conclusion of the preferred path with sgmoore in the bug, then I see no reason why the SRU team would want to do something different. | 13:28 |
| jjohansen | rbasak: dropping confinement is going to be really problematic going forward. unconfined profiles are just a temporary place holder as well. Those will get transitioned to real profiles | 13:30 |
| jjohansen | multiarch is looser than we like but it will get tightened. Fixing conditionals so they can be applied to variables is on the todo list | 13:31 |
| jjohansen | then multiarch will be able to be specific to distro and even runtime platform | 13:32 |
| jjohansen | for the SRU: | 13:36 |
| jjohansen | - new profiles can be flags=(unconfined) | 13:36 |
| jjohansen | - new profiles should have a non-path based name, and the attachment can use the multiarch var | 13:36 |
| jjohansen | - existing profiles should just be adjusted to use multiarch | 13:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!