From: "Mickaël Salaün" <mic@digikod.net>
To: Jann Horn <jannh@google.com>
Cc: Tahera Fahimi <fahimitahera@gmail.com>,
outreachy@lists.linux.dev, gnoack@google.com,
paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, bjorn3_gh@protonmail.com,
netdev@vger.kernel.org
Subject: Re: [PATCH v2 1/4] Landlock: Add signal control
Date: Thu, 8 Aug 2024 16:09:20 +0200 [thread overview]
Message-ID: <20240808.kaiyaeZoo1ha@digikod.net> (raw)
In-Reply-To: <CAG48ez1q80onUxoDrFFvGmoWzOhjRaXzYpu+e8kNAHzPADvAAg@mail.gmail.com>
On Thu, Aug 08, 2024 at 03:10:54AM +0200, Jann Horn wrote:
> On Thu, Aug 8, 2024 at 1:36 AM Tahera Fahimi <fahimitahera@gmail.com> wrote:
> > On Wed, Aug 07, 2024 at 08:16:47PM +0200, Mickaël Salaün wrote:
> > > On Tue, Aug 06, 2024 at 11:55:27PM +0200, Jann Horn wrote:
> > > > On Tue, Aug 6, 2024 at 8:56 PM Jann Horn <jannh@google.com> wrote:
> > > > > On Tue, Aug 6, 2024 at 8:11 PM Tahera Fahimi <fahimitahera@gmail.com> wrote:
> > > > > > Currently, a sandbox process is not restricted to send a signal
> > > > > > (e.g. SIGKILL) to a process outside of the sandbox environment.
> > > > > > Ability to sending a signal for a sandboxed process should be
> > > > > > scoped the same way abstract unix sockets are scoped. Therefore,
> > > > > > we extend "scoped" field in a ruleset with
> > > > > > "LANDLOCK_SCOPED_SIGNAL" to specify that a ruleset will deny
> > > > > > sending any signal from within a sandbox process to its
> > > > > > parent(i.e. any parent sandbox or non-sandboxed procsses).
> > > > [...]
> > > > > > + if (is_scoped)
> > > > > > + return 0;
> > > > > > +
> > > > > > + return -EPERM;
> > > > > > +}
> > > > > > +
> > > > > > +static int hook_file_send_sigiotask(struct task_struct *tsk,
> > > > > > + struct fown_struct *fown, int signum)
> > >
> > > I was wondering if we should handle this case, but I guess it makes
> > > sense to have a consistent policy for all kind of user-triggerable
> > > signals.
> > >
> > > > > > +{
> > > > > > + bool is_scoped;
> > > > > > + const struct landlock_ruleset *dom, *target_dom;
> > > > > > + struct task_struct *result = get_pid_task(fown->pid, fown->pid_type);
> > > > >
> > > > > I'm not an expert on how the fowner stuff works, but I think this will
> > > > > probably give you "result = NULL" if the file owner PID has already
> > > > > exited, and then the following landlock_get_task_domain() would
> > > > > probably crash? But I'm not entirely sure about how this works.
> > > > >
> > > > > I think the intended way to use this hook would be to instead use the
> > > > > "file_set_fowner" hook to record the owning domain (though the setup
> > > > > for that is going to be kind of a pain...), see the Smack and SELinux
> > > > > definitions of that hook. Or alternatively maybe it would be even
> > > > > nicer to change the fown_struct to record a cred* instead of a uid and
> > > > > euid and then use the domain from those credentials for this hook...
> > > > > I'm not sure which of those would be easier.
> > > >
> > > > (For what it's worth, I think the first option would probably be
> > > > easier to implement and ship for now, since you can basically copy
> > > > what Smack and SELinux are already doing in their implementations of
> > > > these hooks. I think the second option would theoretically result in
> > > > nicer code, but it might require a bit more work, and you'd have to
> > > > include the maintainers of the file locking code in the review of such
> > > > refactoring and have them approve those changes. So if you want to get
> > > > this patchset into the kernel quickly, the first option might be
> > > > better for now?)
> > > >
> > >
> > > I agree, let's extend landlock_file_security with a new "fown" pointer
> > > to a Landlock domain. We'll need to call landlock_get_ruleset() in
> > > hook_file_send_sigiotask(), and landlock_put_ruleset() in a new
> > > hook_file_free_security().
> > I think we should add a new hook (hook_file_set_owner()) to initialize
> > the "fown" pointer and call landlock_get_ruleset() in that?
>
> Yeah. Initialize the pointer in the file_set_fowner hook, and read the
> pointer in the file_send_sigiotask hook.
>
> Note that in the file_set_fowner hook, you'll probably need to use
> both landlock_get_ruleset() (to take a reference on the ruleset you're
> storing in the fown pointer) and landlock_put_ruleset() (to drop the
> reference to the ruleset that the fown pointer was pointing to
> before). And you'll need to use some kind of lock to protect the fown
> pointer - either by adding an appropriate lock next to your fown
> pointer or by using some appropriate existing lock in "struct file".
> Probably it's cleanest to have your own lock for this? (This lock will
> have to be something like a spinlock, not a mutex, since you need to
> be able to acquire it in the file_set_fowner hook, which runs inside
> an RCU read-side critical section, where sleeping is forbidden -
> acquiring a mutex can sleep and therefore is forbidden in this
> context, acquiring a spinlock can't sleep.)
Yes, I think this should work for file_set_fowner:
struct landlock_ruleset *prev_dom, *new_dom;
new_dom = landlock_get_current_domain();
landlock_get_ruleset(new_dom);
/* Cf. f_modown() */
write_lock_irq(&filp->f_owner.lock);
prev_dom = rcu_replace_pointer(&landlock_file(file)->fown_domain,
new_dom, lockdep_is_held(&filp->f_owner.lock));
write_unlock_irq(&filp->f_owner.lock);
landlock_put_ruleset_rcu(prev_dom);
With landlock_put_ruleset_rcu() define with this:
diff --git a/security/landlock/ruleset.c b/security/landlock/ruleset.c
index a93bdbf52fff..897116205520 100644
--- a/security/landlock/ruleset.c
+++ b/security/landlock/ruleset.c
@@ -524,6 +524,20 @@ void landlock_put_ruleset_deferred(struct landlock_ruleset *const ruleset)
}
}
+static void free_ruleset_rcu(struct rcu_head *const head)
+{
+ struct landlock_ruleset *ruleset;
+
+ ruleset = container_of(head, struct landlock_ruleset, rcu);
+ free_ruleset(ruleset);
+}
+
+void landlock_put_ruleset_rcu(struct landlock_ruleset *const ruleset)
+{
+ if (ruleset && refcount_dec_and_test(&ruleset->usage))
+ call_rcu(&ruleset->rcu, free_ruleset_rcu);
+}
+
/**
* landlock_merge_ruleset - Merge a ruleset with a domain
*
diff --git a/security/landlock/ruleset.h b/security/landlock/ruleset.h
index c749fa0b3ecd..c930b39174b0 100644
--- a/security/landlock/ruleset.h
+++ b/security/landlock/ruleset.h
@@ -190,19 +190,35 @@ struct landlock_ruleset {
* @work_free: Enables to free a ruleset within a lockless
* section. This is only used by
* landlock_put_ruleset_deferred() when @usage reaches zero.
- * The fields @lock, @usage, @num_rules, @num_layers and
+ * The fields @rcu, @lock, @usage, @num_rules, @num_layers and
* @access_masks are then unused.
*/
struct work_struct work_free;
struct {
- /**
- * @lock: Protects against concurrent modifications of
- * @root, if @usage is greater than zero.
- */
- struct mutex lock;
+ union {
+ /**
+ * @rcu: Protects RCU read-side critical
+ * sections. This is only used by
+ * landlock_put_ruleset_rcu() when @usage
+ * reaches zero.
+ *
+ * Only used for domains.
+ */
+ struct rcu_head rcu;
+ /**
+ * @lock: Protects against concurrent
+ * modifications of @root_inode and
+ * @root_net_port, if @usage is greater than
+ * zero.
+ *
+ * Only used for rulesets.
+ */
+ struct mutex lock;
+ };
/**
* @usage: Number of processes (i.e. domains) or file
- * descriptors referencing this ruleset.
+ * descriptors referencing this ruleset. It can be
+ * zero in RCU read-side critical sections.
*/
refcount_t usage;
/**
@@ -241,6 +257,7 @@ landlock_create_ruleset(const access_mask_t access_mask_fs,
void landlock_put_ruleset(struct landlock_ruleset *const ruleset);
void landlock_put_ruleset_deferred(struct landlock_ruleset *const ruleset);
+void landlock_put_ruleset_rcu(struct landlock_ruleset *const ruleset);
int landlock_insert_rule(struct landlock_ruleset *const ruleset,
const struct landlock_id id,
next prev parent reply other threads:[~2024-08-08 14:15 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-06 18:10 [PATCH v2 0/4] Landlock: Signal Scoping Support Tahera Fahimi
2024-08-06 18:10 ` [PATCH v2 1/4] Landlock: Add signal control Tahera Fahimi
2024-08-06 18:56 ` Jann Horn
2024-08-06 21:55 ` Jann Horn
2024-08-07 18:16 ` Mickaël Salaün
2024-08-07 23:36 ` Tahera Fahimi
2024-08-08 1:10 ` Jann Horn
2024-08-08 14:09 ` Mickaël Salaün [this message]
2024-08-08 14:42 ` Jann Horn
2024-08-09 10:59 ` Mickaël Salaün
2024-08-09 12:40 ` Mickaël Salaün
2024-08-09 12:45 ` Mickaël Salaün
2024-08-09 12:44 ` Jann Horn
2024-08-09 13:17 ` f_modown and LSM inconsistency (was [PATCH v2 1/4] Landlock: Add signal control) Mickaël Salaün
2024-08-09 14:00 ` Jann Horn
2024-08-09 14:44 ` Christian Brauner
2024-08-11 22:04 ` Paul Moore
2024-08-12 13:09 ` Jann Horn
2024-08-12 14:55 ` Mickaël Salaün
2024-08-12 14:57 ` Paul Moore
2024-08-12 15:06 ` Jann Horn
2024-08-12 16:30 ` Paul Moore
2024-08-12 17:27 ` Mickaël Salaün
2024-08-12 18:17 ` Paul Moore
2024-08-12 14:49 ` [PATCH] fs,security: Fix file_set_fowner LSM hook inconsistencies Mickaël Salaün
2024-08-12 15:00 ` Paul Moore
2024-08-13 1:32 ` kernel test robot
2024-08-13 1:42 ` kernel test robot
2024-08-13 1:42 ` kernel test robot
2024-08-13 11:44 ` kernel test robot
2024-08-09 13:37 ` [PATCH v2 1/4] Landlock: Add signal control Mickaël Salaün
2024-08-09 13:57 ` Jann Horn
2024-08-06 22:00 ` Tahera Fahimi
2024-08-06 22:55 ` Jann Horn
2024-08-06 18:10 ` [PATCH v2 2/4] selftest/Landlock: Signal restriction tests Tahera Fahimi
2024-08-06 18:10 ` [PATCH v2 3/4] sample/Landlock: Support signal scoping restriction Tahera Fahimi
2024-08-06 18:10 ` [PATCH v2 4/4] Landlock: Document LANDLOCK_SCOPED_SIGNAL Tahera Fahimi
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=20240808.kaiyaeZoo1ha@digikod.net \
--to=mic@digikod.net \
--cc=bjorn3_gh@protonmail.com \
--cc=fahimitahera@gmail.com \
--cc=gnoack@google.com \
--cc=jannh@google.com \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=outreachy@lists.linux.dev \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.