From: Paul Moore <paul@paul-moore.com>
To: Xu Kuohai <xukuohai@huaweicloud.com>,
bpf@vger.kernel.org, netdev@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-integrity@vger.kernel.org,
apparmor@lists.ubuntu.com, selinux@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <martin.lau@linux.dev>,
Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>,
Matt Bobrowski <mattbobrowski@google.com>,
Brendan Jackman <jackmanb@chromium.org>,
James Morris <jmorris@namei.org>,
"Serge E . Hallyn" <serge@hallyn.com>,
Khadija Kamran <kamrankhadijadj@gmail.com>,
Casey Schaufler <casey@schaufler-ca.com>,
Ondrej Mosnacek <omosnace@redhat.com>,
Kees Cook <keescook@chromium.org>,
John Johansen <john.johansen@canonical.com>,
Lukas Bulwahn <lukas.bulwahn@gmail.com>,
Roberto Sassu <roberto.sassu@huawei.com>,
Shung-Hsi Yu <shung-hsi.yu@suse.com>,
Edward Cree <ecree.xilinx@gmail.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
Trond Myklebust <trond.myklebust@hammerspace.com>,
Anna Schumaker <anna@kernel.org>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Stephen Smalley <stephen.smalley.work@gmail.com>
Subject: Re: [PATCH v4 9/20] lsm: Refactor return value of LSM hook key_getsecurity
Date: Thu, 18 Jul 2024 22:08:07 -0400 [thread overview]
Message-ID: <94a3b82a1e3e1fec77d676fa382105d4@paul-moore.com> (raw)
In-Reply-To: <20240711111908.3817636-10-xukuohai@huaweicloud.com>
On Jul 11, 2024 Xu Kuohai <xukuohai@huaweicloud.com> wrote:
>
> To be consistent with most LSM hooks, convert the return value of
> hook key_getsecurity to 0 or a negative error code.
>
> Before:
> - Hook key_getsecurity returns length of value on success or a
> negative error code on failure.
>
> After:
> - Hook key_getsecurity returns 0 on success or a negative error
> code on failure. An output parameter @len is introduced to hold
> the length of value on success.
>
> Signed-off-by: Xu Kuohai <xukuohai@huawei.com>
> ---
> include/linux/lsm_hook_defs.h | 3 ++-
> include/linux/security.h | 6 ++++--
> security/keys/keyctl.c | 11 ++++++++---
> security/security.c | 26 +++++++++++++++++++++-----
> security/selinux/hooks.c | 11 +++++------
> security/smack/smack_lsm.c | 21 +++++++++++----------
> 6 files changed, 51 insertions(+), 27 deletions(-)
...
> diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c
> index 4bc3e9398ee3..e9f857620f28 100644
> --- a/security/keys/keyctl.c
> +++ b/security/keys/keyctl.c
> @@ -1565,6 +1565,7 @@ long keyctl_get_security(key_serial_t keyid,
> struct key *key, *instkey;
> key_ref_t key_ref;
> char *context;
> + size_t len;
> long ret;
>
> key_ref = lookup_user_key(keyid, KEY_LOOKUP_PARTIAL, KEY_NEED_VIEW);
> @@ -1586,15 +1587,18 @@ long keyctl_get_security(key_serial_t keyid,
> }
>
> key = key_ref_to_ptr(key_ref);
> - ret = security_key_getsecurity(key, &context);
> - if (ret == 0) {
> + ret = security_key_getsecurity(key, &context, &len);
> + if (ret < 0)
> + goto error;
Since there is already an if-else pattern here you might as well stick
with that, for example:
if (ret == 0) {
...
} else if (ret > 0) {
...
}
... you should probably add a comment that @ret is -ERRNO on failure,
but it doesn't look like you need an explicit test here since the error
case will normally fall through to the 'error' label (which you shouldn't
need anymore either).
> + if (len == 0) {
> /* if no information was returned, give userspace an empty
> * string */
> ret = 1;
> if (buffer && buflen > 0 &&
> copy_to_user(buffer, "", 1) != 0)
> ret = -EFAULT;
> - } else if (ret > 0) {
> + } else {
> + ret = len;
> /* return as much data as there's room for */
> if (buffer && buflen > 0) {
> if (buflen > ret)
> @@ -1607,6 +1611,7 @@ long keyctl_get_security(key_serial_t keyid,
> kfree(context);
> }
>
> +error:
> key_ref_put(key_ref);
> return ret;
> }
> diff --git a/security/security.c b/security/security.c
> index 9dd2ae6cf763..2c161101074d 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -5338,19 +5338,35 @@ int security_key_permission(key_ref_t key_ref, const struct cred *cred,
> * security_key_getsecurity() - Get the key's security label
> * @key: key
> * @buffer: security label buffer
> + * @len: the length of @buffer (including terminating NULL) on success
> *
> * Get a textual representation of the security context attached to a key for
> * the purposes of honouring KEYCTL_GETSECURITY. This function allocates the
> * storage for the NUL-terminated string and the caller should free it.
> *
> - * Return: Returns the length of @buffer (including terminating NUL) or -ve if
> - * an error occurs. May also return 0 (and a NULL buffer pointer) if
> - * there is no security label assigned to the key.
> + * Return: Returns 0 on success or -ve if an error occurs. May also return 0
> + * (and a NULL buffer pointer) if there is no security label assigned
> + * to the key.
> */
> -int security_key_getsecurity(struct key *key, char **buffer)
> +int security_key_getsecurity(struct key *key, char **buffer, size_t *len)
> {
> + int rc;
> + size_t n = 0;
> + struct security_hook_list *hp;
> +
> *buffer = NULL;
> - return call_int_hook(key_getsecurity, key, buffer);
> +
> + hlist_for_each_entry(hp, &security_hook_heads.key_getsecurity, list) {
> + rc = hp->hook.key_getsecurity(key, buffer, &n);
> + if (rc < 0)
> + return rc;
> + if (n)
> + break;
> + }
> +
> + *len = n;
> +
> + return 0;
> }
Help me understand why we can't continue to use the call_int_hook()
macro here?
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 16cd336aab3d..747ec602dec0 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -6737,18 +6737,17 @@ static int selinux_key_permission(key_ref_t key_ref,
> return avc_has_perm(sid, ksec->sid, SECCLASS_KEY, perm, NULL);
> }
>
> -static int selinux_key_getsecurity(struct key *key, char **_buffer)
> +static int selinux_key_getsecurity(struct key *key, char **_buffer,
> + size_t *_len)
> {
> struct key_security_struct *ksec = key->security;
> char *context = NULL;
> - unsigned len;
> + u32 context_len;
Since @len doesn't collide with the parameter, you might as well just
stick with @len as the local variable name.
> int rc;
>
> - rc = security_sid_to_context(ksec->sid,
> - &context, &len);
> - if (!rc)
> - rc = len;
> + rc = security_sid_to_context(ksec->sid, &context, &context_len);
> *_buffer = context;
> + *_len = context_len;
> return rc;
> }
--
paul-moore.com
next prev parent reply other threads:[~2024-07-19 2:08 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-11 11:18 [PATCH bpf-next v4 00/20] Add return value range check for BPF LSM Xu Kuohai
2024-07-11 11:18 ` [PATCH bpf-next v4 01/20] lsm: Refactor return value of LSM hook vm_enough_memory Xu Kuohai
2024-07-11 13:46 ` Serge Hallyn
2024-07-19 2:07 ` [PATCH v4 1/20] " Paul Moore
2024-07-11 11:18 ` [PATCH bpf-next v4 02/20] lsm: Refactor return value of LSM hook inode_need_killpriv Xu Kuohai
2024-07-11 14:15 ` Serge Hallyn
2024-07-13 8:06 ` Xu Kuohai
2024-07-19 2:08 ` [PATCH v4 2/20] " Paul Moore
2024-07-20 9:27 ` Xu Kuohai
2024-07-11 11:18 ` [PATCH bpf-next v4 03/20] lsm: Refactor return value of LSM hook inode_getsecurity Xu Kuohai
2024-07-12 13:31 ` Simon Horman
2024-07-13 8:07 ` Xu Kuohai
2024-07-19 2:08 ` [PATCH v4 3/20] " Paul Moore
2024-07-20 9:28 ` Xu Kuohai
2024-07-11 11:18 ` [PATCH bpf-next v4 04/20] lsm: Refactor return value of LSM hook inode_listsecurity Xu Kuohai
2024-07-19 2:08 ` [PATCH v4 4/20] " Paul Moore
2024-07-20 9:29 ` Xu Kuohai
2024-07-11 11:18 ` [PATCH bpf-next v4 05/20] lsm: Refactor return value of LSM hook inode_copy_up_xattr Xu Kuohai
2024-07-19 2:08 ` [PATCH v4 5/20] " Paul Moore
2024-07-20 9:29 ` Xu Kuohai
2024-07-11 11:18 ` [PATCH bpf-next v4 06/20] lsm: Refactor return value of LSM hook getselfattr Xu Kuohai
2024-07-19 2:08 ` [PATCH v4 6/20] " Paul Moore
2024-07-20 9:30 ` Xu Kuohai
2024-07-11 11:18 ` [PATCH bpf-next v4 07/20] lsm: Refactor return value of LSM hook setprocattr Xu Kuohai
2024-07-19 2:08 ` [PATCH v4 7/20] " Paul Moore
2024-07-20 9:31 ` Xu Kuohai
2024-07-11 11:18 ` [PATCH bpf-next v4 08/20] lsm: Refactor return value of LSM hook getprocattr Xu Kuohai
2024-07-19 2:08 ` [PATCH v4 8/20] " Paul Moore
2024-07-20 9:30 ` Xu Kuohai
2024-07-11 11:18 ` [PATCH bpf-next v4 09/20] lsm: Refactor return value of LSM hook key_getsecurity Xu Kuohai
2024-07-19 2:08 ` Paul Moore [this message]
2024-07-20 9:31 ` [PATCH v4 9/20] " Xu Kuohai
2024-07-22 21:35 ` Paul Moore
2024-07-23 7:04 ` Xu Kuohai
2024-07-23 18:34 ` Paul Moore
2024-07-11 11:18 ` [PATCH bpf-next v4 10/20] lsm: Refactor return value of LSM hook audit_rule_match Xu Kuohai
2024-07-19 2:08 ` [PATCH " Paul Moore
2024-07-20 9:31 ` Xu Kuohai
2024-07-11 11:18 ` [PATCH bpf-next v4 11/20] bpf, lsm: Add disabled BPF LSM hook list Xu Kuohai
2024-07-12 17:56 ` Alexei Starovoitov
2024-07-13 8:11 ` Xu Kuohai
2024-07-11 11:19 ` [PATCH bpf-next v4 12/20] bpf, lsm: Enable BPF LSM prog to read/write return value parameters Xu Kuohai
2024-07-12 15:56 ` [PATCH bpf-next v4 00/20] Add return value range check for BPF LSM Paul Moore
2024-07-12 16:00 ` Paul Moore
2024-07-12 21:44 ` Paul Moore
2024-07-19 2:13 ` Paul Moore
2024-07-19 3:55 ` Xu Kuohai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=94a3b82a1e3e1fec77d676fa382105d4@paul-moore.com \
--to=paul@paul-moore.com \
--cc=andrii@kernel.org \
--cc=anna@kernel.org \
--cc=apparmor@lists.ubuntu.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=casey@schaufler-ca.com \
--cc=daniel@iogearbox.net \
--cc=ecree.xilinx@gmail.com \
--cc=eddyz87@gmail.com \
--cc=edumazet@google.com \
--cc=haoluo@google.com \
--cc=jackmanb@chromium.org \
--cc=jmorris@namei.org \
--cc=john.fastabend@gmail.com \
--cc=john.johansen@canonical.com \
--cc=jolsa@kernel.org \
--cc=kamrankhadijadj@gmail.com \
--cc=keescook@chromium.org \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=lukas.bulwahn@gmail.com \
--cc=martin.lau@linux.dev \
--cc=mattbobrowski@google.com \
--cc=netdev@vger.kernel.org \
--cc=omosnace@redhat.com \
--cc=pabeni@redhat.com \
--cc=roberto.sassu@huawei.com \
--cc=sdf@google.com \
--cc=selinux@vger.kernel.org \
--cc=serge@hallyn.com \
--cc=shung-hsi.yu@suse.com \
--cc=song@kernel.org \
--cc=stephen.smalley.work@gmail.com \
--cc=trond.myklebust@hammerspace.com \
--cc=viro@zeniv.linux.org.uk \
--cc=xukuohai@huaweicloud.com \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox