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:
99% of all code does NOT WANT the user namespace thing, and it's been
a big new attack surface for the kernel getting thing
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 Tue, 5 Jul 2022 at 16:22 Philippe Cerfon wrote:
> Say welcome to CVE-2022-32250, the next root security hole which
would
apparently have been mitigated if Debian were to ship sane defaults.
I'm sorry that you didn't read the actual CVE. This wasn't a bug with
user namespaces, but rather a b
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 were to
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
On Mon, 2022-06-13 at 17:46 +0200, Diederik de Haas wrote:
> On Monday, 13 June 2022 16:56:35 CEST Ben Hutchings wrote:
> > We made the decision that the benefits of sandboxing with user
> > namespaces are likely to outweigh the risks, on most systems. Nothing
> > you've said convinces me to alter
On Monday, 13 June 2022 16:56:35 CEST Ben Hutchings wrote:
> We made the decision that the benefits of sandboxing with user
> namespaces are likely to outweigh the risks, on most systems. Nothing
> you've said convinces me to alter that assessment.
I don't really/fully understand this topic, but
Control: tag -1 wontfix
On Thu, 2022-06-09 at 01:57 +0200, Philippe Cerfon wrote:
[...]
> It rather seems that this feature is only of special use, namely for
> those people who use user namespaces with containers or similar - by
> far no default on a average server or desktop.
[...]
This is wron
Processing control commands:
> tag -1 wontfix
Bug #1012547 [src:linux] linux: disable user namespaces per default
Added tag(s) wontfix.
--
1012547: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012547
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
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
12 matches
Mail list logo
