linux-kernel - Re: [RFC PATCH v3 3/3] devguard: added device guard for mknod in non-initial userns

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20231219-gebaggert-felgen-279a8e8716a8@brauner>
Date: Tue, 19 Dec 2023 14:43:53 +0100
From: Christian Brauner <brauner@...nel.org>
To: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@...onical.com>
Cc: Michael Weiß <michael.weiss@...ec.fraunhofer.de>,
	Alexander Mikhalitsyn <alexander@...alicyn.com>,
	Alexei Starovoitov <ast@...nel.org>,
	Paul Moore <paul@...l-moore.com>,
	Daniel Borkmann <daniel@...earbox.net>,
	Andrii Nakryiko <andrii@...nel.org>,
	Martin KaFai Lau <martin.lau@...ux.dev>, Song Liu <song@...nel.org>,
	Yonghong Song <yhs@...com>,
	John Fastabend <john.fastabend@...il.com>,
	KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...gle.com>,
	Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
	Quentin Monnet <quentin@...valent.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Miklos Szeredi <miklos@...redi.hu>,
	Amir Goldstein <amir73il@...il.com>,
	"Serge E. Hallyn" <serge@...lyn.com>, bpf@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-security-module@...r.kernel.org, gyroidos@...ec.fraunhofer.de
Subject: Re: [RFC PATCH v3 3/3] devguard: added device guard for mknod in
 non-initial userns

> The only thing that is not clear to me about the sb_device_access hook is, what we can check inside it practically?
> Yes, we have an access to struct super_block, but at this point this structure is not filled with anything useful. We only
> can determine a filesystem type and that's all. It means that we can use this hook as a flag that says "ok, we do care about device permissions,
> kernel, please do not set SB_I_NODEV for us". Am I correct?

What the the LSM needs to definitely know is what filesystem type and
what user namespace are relevant. Because this whole thing is mostly
interesting for the != init_user_ns case here.

And both things are already present at that point in time (Technically,
kernfs stuff can be a bit different but kernfs stuff does have
SB_I_NODEV unconditionally so it really doesn't matter.).The thing is
though that you want device access settled as soon as possible when the
superblock isn't yet exposed anywhere. And for that alloc_super() is
pretty convenient. Then you don't have to put much thought into it.

But we can always move the hook to another place. It's also feasible to
do this in vfs_get_tree() for example and provide the fs_context but
again. I don't see why we need to do this now.