On 11/9/2022 3:33 PM, Paul Moore wrote:

On Fri, Oct 28, 2022 at 12:55 PM Casey Schaufler [off-list ref] wrote:

quoted

On 10/26/2022 11:31 PM, Greg KH wrote:

quoted

On Wed, Oct 26, 2022 at 12:36:34PM -0700, Casey Schaufler wrote:

quoted

quoted

quoted

+ *
+ * Copyright (C) 2022 Casey Schaufler [off-list ref]
+ * Copyright (C) Intel Corporation

No date for Intel?

The latest guidance I have received is that Intel does not want a date.

Ok, then I need to have an Intel lawyer sign off on a patch that does
this in order to have that be their official statement.  Otherwise, it
needs a date.

Seems I misunderstood something. The date will be there.

quoted

quoted

quoted

quoted

+ */
+
+#ifndef _UAPI_LINUX_LSM_H
+#define _UAPI_LINUX_LSM_H
+
+/*
+ * ID values to identify security modules.
+ * A system may use more than one security module.
+ *
+ * LSM_ID_XXX values 0 - 31 are reserved for future use

Reserved for what?  Why?

You're not the first person to ask.

And the answer is?

There hasn't been an argument for it beyond "just in case".
I can't see a rational reason to reserve specific numbers as
I don't see value in LSM ranges.

quoted

quoted

I'll remove the reserved values for the next version.

Because we asked it will be removed?

Because I don't have a good reason for including it and it
has been called into question. If a reviewer has a legitimate
case for reserved values they may be back.

Sorry for the delay, I was away for a couple of weeks and limiting my
patch review to bug fixes, critical stuff, etc. but normal service is
resuming this week ...

I was the one who originally added the note on reserved values in my
original strawman proposal and I suspect Casey just carried that
forward into his patches, so feel free to blame me.

Done!

  My reason for
doing so is rather simple, we're going to treat the ID as a 32-bit
value so we have *plenty* of room (just the thought of supporting +4
billion unique LSMs is comically insane), and I'd like to try and
leave some space for yet-undetermined "special" things that we might
need to convey in the LSM syscalls.  For example, this would allow us
to convey additional information to userspace when an application
asked for labeling information using one of these reserved LSM IDs;
applications which did not know (or care) about the special ID would
continue to function normally but augmented/new applications would be
able to make sense of the additional information ... and we wouldn't
have to add a new syscall to do it.

I don't see how

	#define LSM_ID_SPECIAL	2

is better than

	#define LSM_ID_SPECIAL	13

There's no reason to "group" LSM_ID values, nor have a range of them.
Really, I don't care one way or the other. I will bend to whatever will
is stronger.

It's basically really cheap futureproofing with little downside (we
can always reclaim it at a later date if really necessary).  I've done
similar things on other projects and it has proven to be useful in a
few, and in none of the cases has it proven to be a problem.

--
paul-moore.com