Here we go, another one, it seems:
CVE-2022-2588 (https://seclists.org/oss-sec/2022/q3/115)
Seems I'm not the only one who's quite concerned about the ongoing
security impact of user namspaces, as the recent/current discussion
about some LSM patches for 6.1 shows:
https://lwn.net/ml/linux-kernel
Apparently it's already Christmas:
The next two holes that likely allow privilege escalation and that
would have been mitigated by unprivileged user namespaces being
disabled:
CVE-2022-1015, CVE-2022-1016
Cheers,
Phiippe
On Tue, Jul 19, 2022 at 12:20 PM wrote:
> I'm sorry that you didn't read the actual CVE.
Well I did... which is why I haven't written "the next security hole
in user ns" but "the next one that have been mitigated if Debian were
to ship sane defaults".
> Do correct me if I'm wrong, though.
In t
On Thu, Jun 16, 2022 at 6:19 PM Philippe Cerfon wrote:
> Well I guess the 6 or so root security holes, and counting
And here we go already, faster than even I'd have expected:
Say welcome to CVE-2022-32250, the next root security hole which would
apparently have been mitigated if Debian
On Mon, Jun 13, 2022 at 4:56 PM Ben Hutchings wrote:
> This is wrong.
Well quite apparently not.
> On the desktop, browsers and Flatpak rely on user
> namespaces for sandboxing (with an alternative being to install more
> programs setuid-root).
At least firefox doesn't seem to need it, neither
Source: linux
Version: 5.17.11-1
Severity: normal
Tags: security
Hi.
Some time ago, Debian decided to enable user namespaces per default.
Since then we've had numerous security holes which would have been
prevented when user namespaces were disabled.
I vaguely recall at least around 6-7 such ho
6 matches
Mail list logo
