| SvenKieske | mdeslaur: so 2 weeks without a patch for an exploitable bug? :/ | 09:57 |
|---|---|---|
| amurray | SvenKieske: what security bug isn't exploitable? I agree 2 weeks is not ideal but the kernel team handles over 80 different kernel variants by my rough count - it is not trivial to prepare, test and release that many kernels - so really it is a wonder that they are that fast IMO | 11:29 |
| SvenKieske | amurray: well this specific bug will have a working exploit being posted publicly by next monday, so that's a little special I suppose. also it's a local priv escalation in the default install afaik, so these seem a higher severity than other bugs. | 11:33 |
| JanC | from what I understand the exploit is already public | 11:39 |
| JanC | or semi-public at least | 11:39 |
| SvenKieske | it's on the closed distro list and will be published - according to list policy - next monday. I don't know of any leaks yet. the comments on HN which say it's public don't understand the distro list, it seems. | 11:44 |
| amurray | local priv esc bugs in the kernel seem to be found at least once a month - the kernel team has a regular cadence of kernel releases specifically to roll in these sorts of fixes - but unfortunately it is just not realistic to expect them to have to disrupt that cycle so often | 11:46 |
| amurray | my understanding is they reserve the 'drop everything an spin an emergency kernel' for the kinds of issues that are remotely exploitable etc | 11:47 |
| JanC | how many things depend on user namespaces nowadays? | 11:53 |
| SvenKieske | yeah sure, I understand that; I just disagree with this old fashioned interpretation of "remotely exploitable", because in modern systems design running code as a local unpriv. user is often exposed to untrusted end users directly and thus remotely reachable. take most cloud businesses as an example, be it a webhoster or whatever. | 11:53 |
| SvenKieske | JanC: a lot, like: all your webbrowsers for example | 11:54 |
| SvenKieske | all "rootless" container stuff | 11:54 |
| JanC | well, those webbrowsers are not going to exploit this, and are mostly used on "single user" systems whose users have no reason to exploit it | 11:57 |
| JanC | the problem is more with some of the container systems where untrusted third parties are involved | 11:58 |
| amurray | SvenKieske: fwiw I don't disagree with you that this is a serious bug but there are practical issues to preparing and releasing kernel updates for Ubuntu - we need to ensure these are high quality and appropriately tested etc and that takes a certain amount of time and planning, hence the regular cadence | 12:05 |
| amurray | also this is also why we are looking at trying to restrict unprivileged user namespaces by default in future ubuntu releases to only those things that need it | 12:06 |
| JanC | in the mean time, it might be useful to indicate what users can/should disable the exploited feature, or otherwise prevent it from being exploited (and how)... | 12:07 |
| SvenKieske | amurray: I totally understand that you need proper testing etc.! | 12:10 |
| SvenKieske | amurray: very encouraging to hear that you look into restrict the namespacing, but afaik upstream denied that this should get merged? I'm only aware of the currently available global on/off switch and IIRC finer grained controls were denied upstream? but I might remember that wrong. | 12:11 |
| amurray | the lunar kernel has some patches that aren't upstream (but may get there..) for apparmor to restrict the use of user namespaces via its policy - so you can flick a more finer-grained switch so that apparmor will block the user of user namespaces if a process is not confined by apparmor with a policy that allows the use of it | 12:13 |
| amurray | unfortunately I don't think the userspace bits landed so you would need a custom apparmor parser to be able to actually use this (hence why we don't really advertise it anywhere) but it shows the direction we are hoping to go with this | 12:14 |
| georgiag | the userspace bits for user namespace mediation landed on kinetic and lunar | 12:24 |
| georgiag | in the downstream kernel there are some finer-grained sysctl restriction options. there are more details here https://gitlab.com/apparmor/apparmor/-/wikis/unprivileged_userns_restriction | 12:27 |
| SvenKieske | very nice information, thank you both! | 12:30 |
| SvenKieske | I fuzzyly remember reading something about this at lwn.net | 12:30 |
| amurray | georgiag: oh awesome - apologies for the confusion - thanks for schooling me - hopefully I remember next time | 12:38 |
| georgiag | amurray: no apologies needed!! it's a lot of stuff to keep track of | 12:41 |
| sbeattie | gpodder | 21:43 |
| sbeattie | bah | 21:43 |
| sbeattie | we should probably add the unprivileged userns mediation to the security features wiki page. | 21:44 |
| JanC | and maybe someone at Canonical can write a blog about it (and how it can help protect against issues like the CVE discussed earlier today) | 21:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!