linux-kernel - Re: [GIT PULL] LSM patches for v6.1

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 6 Oct 2022 10:42:07 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Paul Moore <paul@...l-moore.com>,
        linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] LSM patches for v6.1

Eric, there's one thing I don't get about why you hate LSM's having
the ability to prevent user name spaces, and yet you are OK with
(indeed, touting) /proc/sys/user/max_user_namespaces.

If we set max_user_namespaces to N, won't the N+1'th application get
an error when they try to create a user namespace?  One of your
arguments about why having LSM's forcing a error of say, EPERM, is
that applications that don't check for error returns might get
confused.  (Those are buggy applications; so they should be fixed ---
isn't that your argument about why we shouldn't be freaking out over
security bugs caused by kernel bugs and user namespaces.)  But if you
set max_user_namespaces, that same application will now fail with say,
ENOSPC.

And if in fact there is a buggy application that will create a
security exposure because they aren't checking !@#@?! error returns,
an attacker can simply create N user namespaces --- and then trigger
the buggy applicaion, at which point, they will have 0wned the system.

    	  	      	       	      - Ted