On Fri, Oct 4, 2024 at 11:53 AM Stephen Smalley
<stephen.smalley.work@xxxxxxxxx> wrote:
>
> The only known user of this interface was libselinux and its
> internal usage of this interface for get_ordered_context_list(3)
> was removed in Feb 2020, with a deprecation warning added to
> security_compute_user(3) at the same time. Add a deprecation
> warning to the kernel and schedule it for final removal in 2025.
>
> Signed-off-by: Stephen Smalley <stephen.smalley.work@xxxxxxxxx>
> ---
> Documentation/ABI/obsolete/sysfs-selinux-user | 12 ++++++++++++
> security/selinux/selinuxfs.c | 4 ++++
> 2 files changed, 16 insertions(+)
> create mode 100644 Documentation/ABI/obsolete/sysfs-selinux-user
>
> diff --git a/Documentation/ABI/obsolete/sysfs-selinux-user b/Documentation/ABI/obsolete/sysfs-selinux-user
> new file mode 100644
> index 000000000000..8ab7557f283f
> --- /dev/null
> +++ b/Documentation/ABI/obsolete/sysfs-selinux-user
> @@ -0,0 +1,12 @@
> +What: /sys/fs/selinux/user
> +Date: April 2005 (predates git)
> +KernelVersion: 2.6.12-rc2 (predates git)
> +Contact: selinux@xxxxxxxxxxxxxxx
> +Description:
> +
> + The selinuxfs "user" node allows userspace to request a list
> + of security contexts that can be reached for a given SELinux
> + user from a given starting context. This was used by libselinux
> + when various login-style programs requested contexts for
> + users, but libselinux stopped using it in 2020.
> + Kernel support will be removed no sooner than Dec 2025.
> diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
> index e172f182b65c..8117d8f6ac2d 100644
> --- a/security/selinux/selinuxfs.c
> +++ b/security/selinux/selinuxfs.c
> @@ -1069,6 +1069,10 @@ static ssize_t sel_write_user(struct file *file, char *buf, size_t size)
> int rc;
> u32 i, len, nsids;
>
> + pr_warn_once("SELinux: %s (%d) wrote to /sys/fs/selinux/user! This "
> + "will not be supported in the future; please update your "
> + "userspace.\n", current->comm, current->pid);
Since this could be triggered by multiple different applications, it
is worth using pr_warn() so users have a better list of what
applications are causing this notice? I understand that there is a
risk of log spam, but considering the limited use of this API it seems
like this is a reasonable risk?
> length = avc_has_perm(current_sid(), SECINITSID_SECURITY,
> SECCLASS_SECURITY, SECURITY__COMPUTE_USER,
> NULL);
> --
> 2.40.1
--
paul-moore.com
