Re: [PATCH v15 22/23] LSM: Add /proc attr entry for full LSM context

From: Stephen Smalley <sds@tycho.nsa.gov>
To: Casey Schaufler <casey@schaufler-ca.com>,
	casey.schaufler@intel.com, jmorris@namei.org,
	linux-security-module@vger.kernel.org, selinux@vger.kernel.org
Cc: keescook@chromium.org, john.johansen@canonical.com,
	penguin-kernel@i-love.sakura.ne.jp, paul@paul-moore.com
Subject: Re: [PATCH v15 22/23] LSM: Add /proc attr entry for full LSM context
Date: Tue, 18 Feb 2020 13:17:52 -0500	[thread overview]
Message-ID: <fa270db3-1e4c-c524-5983-06c2c6f73d79@tycho.nsa.gov> (raw)
In-Reply-To: <20200214234203.7086-23-casey@schaufler-ca.com>

On 2/14/20 6:42 PM, Casey Schaufler wrote:
> Add an entry /proc/.../attr/context which displays the full
> process security "context" in compound format:
>          lsm1\0value\0lsm2\0value\0...
> This entry is not writable.
> 
> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
> Cc: linux-api@vger.kernel.org
<snip>
> ---
> diff --git a/Documentation/security/lsm.rst b/Documentation/security/lsm.rst
> index aadf47c808c0..faec18e7e7d1 100644
> --- a/Documentation/security/lsm.rst
> +++ b/Documentation/security/lsm.rst
> @@ -199,3 +199,25 @@ capability-related fields:
>   -  ``fs/nfsd/auth.c``::c:func:`nfsd_setuser()`
>   
>   -  ``fs/proc/array.c``::c:func:`task_cap()`
> +
> +LSM External Interfaces
> +=======================
> +
> +The LSM infrastructure does not generally provide external interfaces.
> +The individual security modules provide what external interfaces they
> +require.
> +
> +The infrastructure does provide an interface for the special
> +case where multiple security modules provide a process context.
> +This is provided in compound context format.
> +
> +-  `lsm1\0value\0lsm2\0value\0`
> +
> +The `value` is a nul terminated bytestring. It may contain
> +whitespace or non-printable characters.

Slight ambiguity above as to whether the NUL byte is part of "value" or 
a separator between "value" and "lsm2" or both (e.g. two consecutive NULs).

> +
> +The special file ``/proc/pid/attr/context`` provides the security
> +context of the identified process.
> +
> +The special file ``/sys/kernel/security/lsm`` provides a comma
> +separated list of the active security modules.

nit: To me at least, "special file" means device file and I think that's 
the common usage for UNIX-like systems.  So I wouldn't use that term for 
these files.  Could just drop "special".

> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index 2bf82e1cf347..61977a33f2c3 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -1321,6 +1321,12 @@
>    *	@pages contains the number of pages.
>    *	Return 0 if permission is granted.
>    *
> + * @getprocattr:
> + *	Provide the named process attribute for display in special files in
> + *	the /proc/.../attr directory.  Attribute naming and the data displayed

Ditto.

> + *	is at the discretion of the security modules.  The exception is the
> + *	"context" attribute, which will contain the security context of the
> + *	task as a nul terminated text string without trailing whitespace.

I guess you didn't like the kernel-doc description I offered (aside from 
the printable ASCII bit).  At least be explicit above about whether the 
returned length should include or omit the terminating NUL and make sure 
all modules conform.

> diff --git a/security/security.c b/security/security.c
> index a66786c255aa..89b635277245 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -2100,6 +2140,29 @@ int security_getprocattr(struct task_struct *p, const char *lsm, char *name,
>   		return -ENOMEM;
>   	}
>   
> +	if (!strcmp(name, "context")) {
> +		hlist_for_each_entry(hp, &security_hook_heads.getprocattr,
> +				     list) {
> +			rc = hp->hook.getprocattr(p, "context", &cp);
> +			if (rc == -EINVAL || rc == -ENOPROTOOPT)
> +				continue;

I'm guessing the -ENOPROTOOPT test is a leftover from trying to handle 
getpeersec_stream as well as getprocattr?  AFAICT, that is only returned 
for getpeersec_stream.