From: luca.boccassi@gmail.com
To: Paul Moore <paul@paul-moore.com>
Cc: linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] pidfd: add ioctl to retrieve pid info
Date: Wed, 23 Oct 2024 00:45:30 +0100 [thread overview]
Message-ID: <5fe2d1fea417a2b0a28193d5641ab8144a4df9a5.camel@gmail.com> (raw)
In-Reply-To: <CAHC9VhRY81Wp-=jC6-G=6y4e=TSe-dznO=j87i-i+t6GVq4m3w@mail.gmail.com>
On Sat, 5 Oct 2024 at 17:06, Paul Moore <paul@paul-moore.com> wrote:
>
> On Fri, Oct 4, 2024 at 2:48 PM Luca Boccassi <luca.boccassi@gmail.com> wrote:
> > On Wed, 2 Oct 2024 at 15:48, Paul Moore <paul@paul-moore.com> wrote:
> > > On Wed, Oct 2, 2024 at 10:25 AM <luca.boccassi@gmail.com> wrote:
>
> ...
>
> > > [NOTE: please CC the LSM list on changes like this]
> > >
> > > Thanks Luca :)
> > >
> > > With the addition of the LSM syscalls we've created a lsm_ctx struct
> > > (see include/uapi/linux/lsm.h) that properly supports multiple LSMs.
> > > The original char ptr "secctx" approach worked back when only a single
> > > LSM was supported at any given time, but now that multiple LSMs are
> > > supported we need something richer, and it would be good to use this
> > > new struct in any new userspace API.
> > >
> > > See the lsm_get_self_attr(2) syscall for an example (defined in
> > > security/lsm_syscalls.c but effectively implemented via
> > > security_getselfattr() in security/security.c).
> >
> > Thanks for the review, makes sense to me - I had a look at those
> > examples but unfortunately it is getting a bit beyond my (very low)
> > kernel skills, so I've dropped the string-based security_context from
> > v2 but without adding something else, is there someone more familiar
> > with the LSM world that could help implementing that side?
>
> We are running a little short on devs/time in LSM land right now so I
> guess I'm the only real option (not that I have any time, but you know
> how it goes). If you can put together the ioctl side of things I can
> likely put together the LSM side fairly quickly - sound good?
Here's a skeleton ioctl, needs lsm-specific fields to be added to the new struct, and filled in the new function:
diff --git a/fs/pidfs.c b/fs/pidfs.c
index 4eaf30873105..30310489f5e1 100644
--- a/fs/pidfs.c
+++ b/fs/pidfs.c
@@ -115,6 +115,35 @@ static __poll_t pidfd_poll(struct file *file, struct poll_table_struct *pts)
return poll_flags;
}
+static long pidfd_security(struct task_struct *task, unsigned int cmd, unsigned long arg)
+{
+ struct pidfd_security __user *usecurity = (struct pidfd_security __user *)arg;
+ size_t usize = _IOC_SIZE(cmd);
+ struct pidfd_security ksecurity = {};
+ __u64 mask;
+
+ if (!usecurity)
+ return -EINVAL;
+ if (usize < PIDFD_SECURITY_SIZE_VER0)
+ return -EINVAL; /* First version, no smaller struct possible */
+
+ if (copy_from_user(&mask, &usecurity->mask, sizeof(mask)))
+ return -EFAULT;
+
+ // TODO: fill in ksecurity
+
+ /*
+ * If userspace and the kernel have the same struct size it can just
+ * be copied. If userspace provides an older struct, only the bits that
+ * userspace knows about will be copied. If userspace provides a new
+ * struct, only the bits that the kernel knows about will be copied.
+ */
+ if (copy_to_user(usecurity, &ksecurity, min(usize, sizeof(ksecurity))))
+ return -EFAULT;
+
+ return 0;
+}
+
static long pidfd_info(struct task_struct *task, unsigned int cmd, unsigned long arg)
{
struct pidfd_info __user *uinfo = (struct pidfd_info __user *)arg;
@@ -160,7 +189,7 @@ static long pidfd_info(struct task_struct *task, unsigned int cmd, unsigned long
* the flag only if we can still access it.
*/
rcu_read_lock();
- cgrp = task_dfl_cgroup(current);
+ cgrp = task_dfl_cgroup(task);
if (cgrp) {
kinfo.cgroupid = cgroup_id(cgrp);
kinfo.mask |= PIDFD_INFO_CGROUPID;
@@ -209,9 +238,11 @@ static long pidfd_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
if (!task)
return -ESRCH;
- /* Extensible IOCTL that does not open namespace FDs, take a shortcut */
+ /* Extensible IOCTLs that do not open namespace FDs, take a shortcut */
if (_IOC_NR(cmd) == _IOC_NR(PIDFD_GET_INFO))
return pidfd_info(task, cmd, arg);
+ if (_IOC_NR(cmd) == _IOC_NR(PIDFD_GET_SECURITY))
+ return pidfd_security(task, cmd, arg);
if (arg)
return -EINVAL;
diff --git a/include/uapi/linux/pidfd.h b/include/uapi/linux/pidfd.h
index 4540f6301b8c..0658880a9089 100644
--- a/include/uapi/linux/pidfd.h
+++ b/include/uapi/linux/pidfd.h
@@ -65,6 +65,14 @@ struct pidfd_info {
__u32 spare0[1];
};
+#define PIDFD_SECURITY_SIZE_VER0 8 /* sizeof first published struct */
+
+struct pidfd_security {
+ /* This mask follows the same rules as pidfd_info.mask. */
+ __u64 mask;
+ // TODO: add data fields and flags and increase size defined above
+};
+
#define PIDFS_IOCTL_MAGIC 0xFF
#define PIDFD_GET_CGROUP_NAMESPACE _IO(PIDFS_IOCTL_MAGIC, 1)
@@ -78,5 +86,6 @@ struct pidfd_info {
#define PIDFD_GET_USER_NAMESPACE _IO(PIDFS_IOCTL_MAGIC, 9)
#define PIDFD_GET_UTS_NAMESPACE _IO(PIDFS_IOCTL_MAGIC, 10)
#define PIDFD_GET_INFO _IOWR(PIDFS_IOCTL_MAGIC, 11, struct pidfd_info)
+#define PIDFD_GET_SECURITY _IOWR(PIDFS_IOCTL_MAGIC, 12, struct pidfd_security)
#endif /* _UAPI_LINUX_PIDFD_H */
next prev parent reply other threads:[~2024-10-22 23:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20241002142516.110567-1-luca.boccassi@gmail.com>
2024-10-04 9:29 ` [PATCH] pidfd: add ioctl to retrieve pid info Christian Brauner
2024-10-04 14:05 ` Paul Moore
2024-10-04 18:50 ` Luca Boccassi
2024-10-04 19:29 ` Oleg Nesterov
2024-10-04 19:40 ` Luca Boccassi
2024-10-05 11:29 ` Oleg Nesterov
2024-10-06 14:59 ` Luca Boccassi
2024-10-06 19:18 ` David Laight
2024-10-07 14:54 ` Josh Triplett
[not found] ` <CAHC9VhRV3KcNGRw6_c-97G6w=HKNuEQoUGrfKhsQdWywzDDnBQ@mail.gmail.com>
[not found] ` <CAMw=ZnSkm1U-gBEy9MBbjo2gP2+WHV2LyCsKmwYu2cUJqSUeXg@mail.gmail.com>
[not found] ` <CAHC9VhRY81Wp-=jC6-G=6y4e=TSe-dznO=j87i-i+t6GVq4m3w@mail.gmail.com>
2024-10-22 23:45 ` luca.boccassi [this message]
2024-10-22 23:56 ` Luca Boccassi
2024-10-24 23:14 ` Paul Moore
2024-10-24 23:31 ` Luca Boccassi
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=5fe2d1fea417a2b0a28193d5641ab8144a4df9a5.camel@gmail.com \
--to=luca.boccassi@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
/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;
as well as URLs for NNTP newsgroup(s).