[09:57] <SvenKieske> mdeslaur: so 2 weeks without a patch for an exploitable bug? :/ 
[11:29] <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:33] <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:39] <JanC> from what I understand the exploit is already public
[11:39] <JanC> or semi-public at least
[11:44] <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:46] <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:47] <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:53] <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:54] <SvenKieske> JanC: a lot, like: all your webbrowsers for example
[11:54] <SvenKieske> all "rootless" container stuff
[11:57] <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:58] <JanC> the problem is more with some of the container systems where untrusted third parties are involved
[12:05] <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:06] <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:07] <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:10] <SvenKieske> amurray: I totally understand that you need proper testing etc.!
[12:11] <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:13] <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:14] <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:24] <georgiag> the userspace bits for user namespace mediation landed on kinetic and lunar
[12:27] <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:30] <SvenKieske> very nice information, thank you both!
[12:30] <SvenKieske> I fuzzyly remember reading something about this at lwn.net
[12:38] <amurray> georgiag: oh awesome - apologies for the confusion - thanks for schooling me - hopefully I remember next time
[12:41] <georgiag> amurray: no apologies needed!! it's a lot of stuff to keep track of
[21:43] <sbeattie> gpodder
[21:43] <sbeattie> bah
[21:44] <sbeattie> we should probably add the unprivileged userns mediation to the security features wiki page.
[21:52] <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)