lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 05 Jul 2018 12:36:13 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Christian Brauner <christian@...uner.io>
Cc:     viro@...iv.linux.org.uk, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, seth.forshee@...onical.com,
        serge@...lyn.com, containers@...ts.linux-foundation.org
Subject: Re: [PATCH] Revert "vfs: Allow userns root to call mknod on owned filesystems."

ebiederm@...ssion.com (Eric W. Biederman) writes:

> Nacked-by: "Eric W. Biederman" <ebiederm@...ssion.com>
>
> Your description is usesless.
>
> It needs to detail exactly what breaks, what regressions and why.
> All I see below is hand waving.
>
> We need to know why this does not work so someone does not come in and try
> this again.  Or so that someone can fix this and then try again.
>
> You do not include that kind of information in your commit log.
>
> Calling mknod to create device nodes can not be widespread.  There are
> not that many privileged processes and calling mknod outside of being
> a specialed process like udev is broken.
>
> Therefore I refute your assertion that this is a widespread issue.
>
>
> I expect somewhere there is a reasonable argument for reverting this
> change on the basis that it causes a regression. You have not made it.
>
> Until that time I am going to oppose this revert because your
> justfication for the revert is lacking.
>
>
> It has never been the case that mknod on a device node will guarantee
> that you even can open the device node.  The applications that regress
> are broken.  It doesn't mean we shouldn't be bug compatible, but we darn
> well should document very clearly the bugs we are being bug compatible
> with.
>

Further from what I have seen of this issue, there is a compelling case
that what the applications that are broken what what is enabled by
allowing mknod to succeed.  So we absolutely need a good description of
what is going on, because at best a revert to fix today's breaking is
temporary until userspace gets their bugs fixed.

Eric

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ