linux-kernel - Re: [PATCH] selinux: enable per-file labeling for functionfs

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: <CAEjxPJ4Vi9rXXkvPUoS-tjHks_6oevdkhrjvSeX_Rh5VV5gBBw@mail.gmail.com>
Date: Thu, 21 Aug 2025 08:59:51 -0400
From: Stephen Smalley <stephen.smalley.work@...il.com>
To: Neill Kapron <nkapron@...gle.com>
Cc: Paul Moore <paul@...l-moore.com>, Ondrej Mosnacek <omosnace@...hat.com>, kernel-team@...roid.com, 
	selinux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] selinux: enable per-file labeling for functionfs

On Wed, Aug 20, 2025 at 5:23 PM Neill Kapron <nkapron@...gle.com> wrote:
>
> This patch adds support for genfscon per-file labeling of functionfs
> files as well as support for userspace to apply labels after new
> functionfs endpoints are created.
>
> This allows for separate labels and therefore access control on a
> per-endpoint basis. An example use case would be for the default
> endpoint EP0 used as a restricted control endpoint, and additional
> usb endpoints to be used by other more permissive domains.
>
> It should be noted that if there are multiple functionfs mounts on a
> system, genfs file labels will apply to all mounts, and therefore will not
> likely be as useful as the userspace relabeling portion of this patch -
> the addition to selinux_is_genfs_special_handling().
>
> Signed-off-by: Neill Kapron <nkapron@...gle.com>

Did you confirm that functionfs is safe wrt genfscon-based and
userspace labeling, as per:
https://github.com/SELinuxProject/selinux-kernel/issues/2

Also as per that longstanding open issue, we'd welcome patches to
generalize the current hardcoded list of filesystem types to
instead lookup the filesystem type in the policy to see if it should
support genfscon and/or userspace labeling.

> ---
>  security/selinux/hooks.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index e474cd7398ef..54b82c814b4d 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -474,6 +474,7 @@ static int selinux_is_genfs_special_handling(struct super_block *sb)
>                 !strcmp(sb->s_type->name, "debugfs") ||
>                 !strcmp(sb->s_type->name, "tracefs") ||
>                 !strcmp(sb->s_type->name, "rootfs") ||
> +               !strcmp(sb->s_type->name, "functionfs") ||
>                 (selinux_policycap_cgroupseclabel() &&
>                  (!strcmp(sb->s_type->name, "cgroup") ||
>                   !strcmp(sb->s_type->name, "cgroup2")));
> @@ -741,6 +742,7 @@ static int selinux_set_mnt_opts(struct super_block *sb,
>             !strcmp(sb->s_type->name, "binder") ||
>             !strcmp(sb->s_type->name, "bpf") ||
>             !strcmp(sb->s_type->name, "pstore") ||
> +           !strcmp(sb->s_type->name, "functionfs") ||
>             !strcmp(sb->s_type->name, "securityfs"))
>                 sbsec->flags |= SE_SBGENFS;
>
> --
> 2.51.0.261.g7ce5a0a67e-goog
>