* Re: LSM namespacing API
From: John Johansen @ 2025-08-21 14:44 UTC (permalink / raw)
To: Dr. Greg, Paul Moore; +Cc: linux-security-module, selinux, Stephen Smalley
In-Reply-To: <20250821112011.GA31850@wind.enjellic.com>
On 8/21/25 04:20, Dr. Greg wrote:
> On Tue, Aug 19, 2025 at 10:56:27AM -0400, Paul Moore wrote:
>
>> Hello all,
>
> Good morning, I hope the day is going well for everyone.
>
>> As most of you are likely aware, Stephen Smalley has been working on
>> adding namespace support to SELinux, and the work has now progressed
>> to the point where a serious discussion on the API is warranted. For
>> those of you are unfamiliar with the details or Stephen's patchset, or
>> simply need a refresher, he has some excellent documentation in his
>> work-in-progress repo:
>>
>> * https://github.com/stephensmalley/selinuxns
>>
>> Stephen also gave a (pre-recorded) presentation at LSS-NA this year
>> about SELinux namespacing, you can watch the presentation here:
>>
>> * https://www.youtube.com/watch?v=AwzGCOwxLoM
>>
>> In the past you've heard me state, rather firmly at times, that I
>> believe namespacing at the LSM framework layer to be a mistake,
>> although if there is something that can be done to help facilitate the
>> namespacing of individual LSMs at the framework layer, I would be
>> supportive of that. I think that a single LSM namespace API, similar
>> to our recently added LSM syscalls, may be such a thing, so I'd like
>> us to have a discussion to see if we all agree on that, and if so,
>> what such an API might look like.
>>
>> At LSS-NA this year, John Johansen and I had a brief discussion where
>> he suggested a single LSM wide clone*(2) flag that individual LSM's
>> could opt into via callbacks. John is directly CC'd on this mail, so
>> I'll let him expand on this idea.
>>
>> While I agree with John that a fs based API is problematic (see all of
>> our discussions around the LSM syscalls), I'm concerned that a single
>> clone*(2) flag will significantly limit our flexibility around how
>> individual LSMs are namespaced, something I don't want to see happen.
>> This makes me wonder about the potential for expanding
>> lsm_set_self_attr(2) to support a new LSM attribute that would support
>> a namespace "unshare" operation, e.g. LSM_ATTR_UNSHARE. This would
>> provide a single LSM framework API for an unshare operation while also
>> providing a mechanism to pass LSM specific via the lsm_ctx struct if
>> needed. Just as we do with the other LSM_ATTR_* flags today,
>> individual LSMs can opt-in to the API fairly easily by providing a
>> setselfattr() LSM callback.
>>
>> Thoughts?
>
> There has been an adage that traces back to the writings of George
> Santayana in 1905 that seems relevant:
>
> "Those who cannot remember the past are condemned to repeat it."
>
> To that end, some input from more than a decade of our work on this
> issue. Some of our reflections below are relevant to issues being
> covered in downstream components of this thread, particularly by John
> in the last few hours.
>
> We have had code on the table for three years with respect to the
> problem of generic namespacing of security policy/model/architecture,
> whatever one chooses to call it.
>
> For everyone's reference, here are the URL's to the patch series:
>
> V1:
> https://lore.kernel.org/linux-security-module/20230204050954.11583-1-greg@enjellic.com/T/#t
>
> V2:
> https://lore.kernel.org/linux-security-module/20230710102319.19716-1-greg@enjellic.com/T/#t
>
> V3:
> https://lore.kernel.org/linux-security-module/20240401105015.27614-1-greg@enjellic.com/T/#t
>
> V4:
> https://lore.kernel.org/linux-security-module/20240826103728.3378-1-greg@enjellic.com/T/#t
>
> We started this work about 13-15 years ago. We initially described
> our work and the need for it, 10 years ago almost to this day. See
> our 2015 paper at the Linux Security Summit in Seattle.
>
> James Morris and Casey were in the first row, Stephen and a co-worker
> from the NSA were in the second row, to the speakers left.
>
> If one spends some time looking under the hood, TSEM is in large part
> about providing a generic framework for running multiple, independent
> and orthogonal security frameworks/policies/architectures, whatever
> one chooses to call these entities.
>
> The reason that we argue that TSEM is a generic framework, is that in
> our internal work, we have ported the major LSM's, including the IMA
> infrastructure, to run in isolated namespaces as plugins for TSEM's
> notion of Trusted Modeling Agents (TMA's). We also have ongoing work
> that enables Kubernetes to dispatch workloads, using whatever LSM
> based security policy that container developers desire for their
> workloads.
>
> Suffice it to say, we have howed a lot of ground on the issues
> surrounding this, including issues surrounding production deployment
> of this type of technology.
>
> In our initial implementation, circa 2015, we adopted the approach of
> using a CLONE_* flag and wired the implementation of security
> namespaces into the rest of the namespace infrastructure.
>
> During COVID, we re-architected the entire implementation and moved to
> using a control file in the pseudo-filesystem that TSEM implements, we
> have never looked back on this decision.
>
> TSEM security workloads are a poster child for security namespaces
> that require a number of different setup parameters. A command verb
> syntax with key=value pairs, written to a pseudo-file, has proven
> itself to be the most flexible approach when setting up security
> workloads.
>
> With respect to namespace transition, we trigger the transition of a
> process to a new namespace (unsharing) when the process issues the
> request via the control file. This has proven to be, at once, the
> most straight forward and least security prone approach.
>
> The other major, and thorny issue, is the notion of another process
> 'entering' a security namespace. There are a ton of open issues to be
> considered with this, the approach that we took that has worked well
> to date, is the notion of a 'trust orchestrator' that has
> responsibility for controlling the namespace. Any manipulations or
> control of the namespace are conducted through the orchestrator
> process.
>
> If anyone chooses to look at our implementation, you will find that we
> 'bless' the orchestrator process, at the time of namespace creation,
> with access to the security namespace context control structure for
> the namespace being created. The orchestrator is the only entity that
> can access the security state of the namespace, other than processes
> within the namespace itself.
>
> This significantly narrows the scope of vulnerability with respect to
> who or what can manipulate a security namespace. There are a number
> of thorny issues, that we have not seen anyone mention, that surface
> with respect to allowing entry into a security namespace by an
> arbitrary process. Believe me when I say we have found a number of
> them by accident and incident.
>
indeed, this has to be tightly controlled. Much more so than just
creating a namespace. And its not just the "security/LSM" namespace
but the entire context around it. That is whether or not you can
step into say the mount namespace separate from the security/LSM
namespace it was created with.
Each and everyone of those opens potential attack surface. Even if you
if it turns out to be safe, you have to carefully evaluate each
potential combination.
> So big picture.
>
> Over a decade of experience with these issues, suggests that Paul's
> premise that most of these issues are best left to specific LSM's that
> elect to implement namespacing, is correct.
>
> The challenge is that this situation ends up being all or nothing.
>
> The actual amount of code involved in unsharing a namespace is so
> trivial, in comparison to the work involved with setting up and
> maintaining state information for a security namespace context, that
> it seems to make little sense to implement this support at the level
> of the LSM infrastructure itself.
>
actually I think that is pretty much the goal, just a minimal thin
layer that provides the hooks and maybe an LSM blob object for the
individual LSMs to do their thing.
Instead of each LSM implementing their own interface there is a common
one for container orchastrators to use to make the request.
> If the decision is made to provide generic namespace support, other
> than a request to create a namespace, it will rapidly become a
> slippery slope with respect to the amount of infrastructure needed to
> address the complexities associated with every security model being
> different from every other.
>
yep, this is really just about a thin common API, and minimal
infrastructure around the existing system namespacing calls (clone,
ushare, setns).
> The caveat to this is if our notion of a 'trust orchestrator' would be
> deemed to have merit. In that case, an LSM based namespace separation
> architecture would provide a common point for the orchestrator to be
> 'blessed' with access to control of a namespace.
>
A trust orchestrator isn't necessarily needed. Each LSM can manage its
own trust within its policy. A trust orchestrator becomes more necessary
when you are trying to namespacing without the LSMs themselves
participating in the decision around namespacing. Which admittedly has
largely been the current situation.
> The other open issue is whether or not a separate capability should be
> implemented that allows the creation of a new security namespace. If
> one paws through our TSEM submissions, one will see that we proposed
> such a capability bit.
>
Its not needed if individual LSMs are making decisions around namespacing
based on policy. In fact in that case it can even be harmful. Per LSM
policy would be finer grained, where a capability becomes this shared
flag that lacks context. Examples abound in the kernel where we have
a cap check without context and then a more context based security
check.
Where the capability might be useful is wehn LSMs aren't dealing with
the namespacing request directly.
> Casey noted, rather emphatically, that no new capabilities were going
> to be implemented in Linux, particularly for what was described as a
> 'toy' project. He indicated that CAP_MAC_ADMIN was the canonical
> capability that should be used for manipulating LSM's.
>
I disagree with the reuse of CAP_MAC_ADMIN, if there is going to be
a capability around this it should be distinct from MAC_ADMIN and
MAC_OVERRIDE, as it very much has different semantics.
> We will be very interested in seeing how a discussion around this
> evolves, as 'escaping' from an existing security context to a new one
> is an extremely critical operation from a security perspective, if one
yes. I might have mentioned just how much I dislike setns().
> stands back and looks at the issue objectively. If the concept of a
> 'security orchestrator' is embraced, it would make perfect sense for
> the orchestrator to drop CAP_SEC_NS, or whatever it would be called,
> and retain CAP_MAC_ADMIN in order to manage the namespace.
>
> So lots of issues to consider; thorny, political and otherwise, on
> multiple fronts.
>
>> paul-moore.com
>
> Have a good day.
>
> As always,
> Dr. Greg
>
> The Quixote Project - Flailing at the Travails of Cybersecurity
> https://github.com/Quixote-Project
>
^ permalink raw reply
* Re: LSM namespacing API
From: Serge E. Hallyn @ 2025-08-21 14:26 UTC (permalink / raw)
To: John Johansen; +Cc: Stephen Smalley, Paul Moore, linux-security-module, selinux
In-Reply-To: <67e72960-c985-48e1-aaeb-a4286cc8508f@canonical.com>
On Thu, Aug 21, 2025 at 12:46:10AM -0700, John Johansen wrote:
> On 8/19/25 10:47, Stephen Smalley wrote:
> > On Tue, Aug 19, 2025 at 10:56 AM Paul Moore <paul@paul-moore.com> wrote:
> > >
> > > Hello all,
> > >
> > > As most of you are likely aware, Stephen Smalley has been working on
> > > adding namespace support to SELinux, and the work has now progressed
> > > to the point where a serious discussion on the API is warranted. For
> > > those of you are unfamiliar with the details or Stephen's patchset, or
> > > simply need a refresher, he has some excellent documentation in his
> > > work-in-progress repo:
> > >
> > > * https://github.com/stephensmalley/selinuxns
> > >
> > > Stephen also gave a (pre-recorded) presentation at LSS-NA this year
> > > about SELinux namespacing, you can watch the presentation here:
> > >
> > > * https://www.youtube.com/watch?v=AwzGCOwxLoM
> > >
> > > In the past you've heard me state, rather firmly at times, that I
> > > believe namespacing at the LSM framework layer to be a mistake,
> > > although if there is something that can be done to help facilitate the
> > > namespacing of individual LSMs at the framework layer, I would be
> > > supportive of that. I think that a single LSM namespace API, similar
> > > to our recently added LSM syscalls, may be such a thing, so I'd like
> > > us to have a discussion to see if we all agree on that, and if so,
> > > what such an API might look like.
> > >
> > > At LSS-NA this year, John Johansen and I had a brief discussion where
> > > he suggested a single LSM wide clone*(2) flag that individual LSM's
> > > could opt into via callbacks. John is directly CC'd on this mail, so
> > > I'll let him expand on this idea.
> > >
> > > While I agree with John that a fs based API is problematic (see all of
> > > our discussions around the LSM syscalls), I'm concerned that a single
> > > clone*(2) flag will significantly limit our flexibility around how
> > > individual LSMs are namespaced, something I don't want to see happen.
> > > This makes me wonder about the potential for expanding
> > > lsm_set_self_attr(2) to support a new LSM attribute that would support
> > > a namespace "unshare" operation, e.g. LSM_ATTR_UNSHARE. This would
> > > provide a single LSM framework API for an unshare operation while also
> > > providing a mechanism to pass LSM specific via the lsm_ctx struct if
> > > needed. Just as we do with the other LSM_ATTR_* flags today,
> > > individual LSMs can opt-in to the API fairly easily by providing a
> > > setselfattr() LSM callback.
> > >
> > > Thoughts?
> >
> > I think we want to be able to unshare a specific security module
> > namespace without unsharing the others, i.e. just SELinux or just
> > AppArmor.
>
> yes which is part of the problem with the single flag. That choice
> would be entirely at the policy level, without any input from userspace.
AIUI Paul's suggestion is the user can pre-set the details of which
lsms to unshare and how with the lsm_set_self_attr(), and then a
single CLONE_LSM effects that.
-serge
^ permalink raw reply
* Re: LSM namespacing API
From: John Johansen @ 2025-08-21 14:18 UTC (permalink / raw)
To: Mickaël Salaün, Paul Moore
Cc: Stephen Smalley, linux-security-module, selinux,
Maxime Bélair
In-Reply-To: <20250821.Ree4Liedeita@digikod.net>
On 8/21/25 02:56, Mickaël Salaün wrote:
> On Wed, Aug 20, 2025 at 04:47:15PM -0400, Paul Moore wrote:
>> On Wed, Aug 20, 2025 at 10:44 AM Mickaël Salaün <mic@digikod.net> wrote:
>>> On Tue, Aug 19, 2025 at 02:51:00PM -0400, Paul Moore wrote:
>>>> On Tue, Aug 19, 2025 at 1:47 PM Stephen Smalley
>>>> <stephen.smalley.work@gmail.com> wrote:
>>
>> ...
>>
>>>> Since we have an existing LSM namespace combination, with processes
>>>> running inside of it, it might be sufficient to simply support moving
>>>> into an existing LSM namespace set with setns(2) using only a pidfd
>>>> and a new CLONE_LSMNS flag (or similar, upstream might want this as
>>>> CLONE_NEWLSM). This would simply set the LSM namespace set for the
>>>
>>> Bike shedding but, I would prefer CLONE_NEWSEC or something without LSM
>>> because the goal is not to add a new LSM but a new "security" namespace.
>>
>> I disagree with your statement about the goal. In fact I would argue
>> that one of the goals is to explicitly *not* create a generic
>> "security" namespace. Defining a single, LSM-wide namespace, is
>> already an almost impossible task, extending it to become a generic
>> "security" namespace seems maddening.
>
> I didn't suggest a generic "security" namespace that would include
> non-LSM access checks, just using the name "security" instead of "LSM",
> but never mind.
>
>>
>>>> setns(2) caller to match that of the target pidfd. We still wouldn't
>>>> want to support CLONE_LSMNS/CLONE_NEWLSM for clone*().
>>>
>>> Why making clone*() support this flag would be an issue?
>>
>> With the understanding that I'm not going to support a single LSM-wide
>> namespace (see my previous comments), we would need multiple flags for
>
> I'm confused about the goal of this thread... When I read namespace I
> think about the user space interface that enables to tie a set of
> processes to ambient kernel objects. I'm not suggesting to force all
> LSM to handle namespaces, but to have a unified user space interface
> (i.e. namespace flag, file descriptor...) that can be used by user space
> to request a new "context" that may or may not be used by running LSMs.
>
Yes to a unified interface, no to an LSM wide namespace. The interface
could request of the LSM to namespace, but its up to the LSM what it
will do. If it creates a namespace, whether that namespace is hierarchical,
or flat.
You would at the end of the call likely get a proxy object to a set of
individual LSM namespace contexts. Not that different than you have a
set of different system namespaces, mount, pid, user, ...
>> clone*(), one for each LSM that wanted to implement a namespace.
>
> My understanding of this proposal was to create a LSM-wide namespace,
> and one of the reason was to avoid one namespace per LSM. As I
no each LSM will do its own thing wrt namespacing. The proposal is just
to provide a common API and minimal infra around it.
> explained in my previous email, I think it would make sense and could be
> convincing.
>
I have to agree with Paul that we won't generically agree on what an LSM
namespace should be.
>> While clone3() has expanded the number of flag bits from clone(),
>> there is still a limitation of 64-bits and I'm fairly certain the
>> other kernel devs are not going to be supportive of a flag for each
>> LSM that wants one.
>>
>> Maybe we could argue for our own u64 in cl_args, or create our own
>> lsm_clone(2) syscall that mimics clone3(2) with better LSM support,
>> but neither of these seem like great ideas at the moment.
>
> My idea was that using CLONE_NEWLSM would just fork the current/initial
> namespace used by LSMs to tie security policies/configurations to
> processes, but as John already said, it would be the responsibility of
> each LSM to either inherit and keep in sync the parent policy (e.g.
> SELinux) or start with a blank/default one (e.g. Yama).
>
Its not just these options though. The container manager may want to
"drop/add" an LSM.
Eg. one fedora/RH booting an Ubuntu container your host has selinux
the container wants apparmor.
In reality you have both selinux and apparmor active on the system,
but selinux is an enforcing state, and apparmor is in a no-policy
state.
selinux could deny creating the namespace, it could return its current
state, or it could mask itself by creating a namespace for the container
with the default unconfined_t policy, but its current state is still
there bounding the container, the container just doesn't see it.
On the AppArmor side at the request for a new namespace with apparmor
it needs to decide what to do independent of what selinux does. Yes
if configured correctly it should setup its policy namespace for the
container, but it has choices just like selinux that are driven
by policy as well as the userspace request for a specific combination
of LSMs for the cntainer.
> One way to configure a newly created namespace could be to load a
> configuration in the parent namespace (e.g. with one of the new LSM
> config syscall and a dedicated flag) that would only be applied to child
> namespaces when they are created, similarly to attr/exec for execve(2).
host injecting policy into the container certainly could be supported
but I think that would be a per LSM thing.
attr/exec flags Paul was discussing (correct me if I am wrong), where
a way to specify which LSMs should but part of the unshare. So the
whole I want a container to support Ubuntu or RH and need these LSMs.
> I think this is what you meant with the LSM_UNSHARE flag, right?
>
Per my above understanding the LSM_UNSHARE flag is then just a
namespacing that indicates you want to unshare the LSM and use the afore
mentioned attrs.
I don't think it is actually needed, but maybe desirable for consistency.
If you have already set the above attrs, that already indicates what
you want to do with the namespace at clone/unshare.
This then gets fed into every LSM (whether in the attrs or not). So they
can make current policy decision, and then if allowed, as second hook
with the info, so that they can each setup and return with their context
setup. Not really all that different from exec.
>>
>>>> Any other ideas?
>>>
>>> The goal of a namespace is to configure absolute references (e.g. file
>>> path, network address, PID, time). I think it would make sense to have
>>> an LSM/MAC/SEC namespace that would enforce a consistent access control
>>> on every processes in this namespace.
>>
>> Once again, I'm not going to support the idea of a namespace at the
>> LSM framework layer, individual LSMs are better suited to implementing
>> their own namespacing concepts. However, I do support the LSM
>> framework providing an API and/or helpers to help make it easier for
>> individual LSMs and userspace to create/manage individual LSM
>> namespaces.
>
> Should we still talk about "namespace" or use another name?
>
its namespaces for LSMs, just not an LSM namespace.
>>
>>> A related namespace file
>>> descriptor could then be used with an LSM-specific syscall to configure
>>> the policy related to a specific namespace (instead of only the current
>>> namespace)
>>
>> That is a reasonable request, and I think the same underlying solution
>> that we would use for setns(2) could also be used here.
>
> I'm not sure having a set of namespace file descriptors without related
> clone flags would be acceptable, at least for what we currently call
> Linux "namespace".
well Paul did propose a single Clone_LSM flag that would cover them ;-).
Agree with Paul that a per LSM flag would be unlikely and just raise the
whole, security is crazy why can't you agree on one "fun".
^ permalink raw reply
* Re: LSM namespacing API
From: Dr. Greg @ 2025-08-21 11:20 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-security-module, selinux, John Johansen, Stephen Smalley
In-Reply-To: <CAHC9VhRGMmhxbajwQNfGFy+ZFF1uN=UEBjqQZQ4UBy7yds3eVQ@mail.gmail.com>
On Tue, Aug 19, 2025 at 10:56:27AM -0400, Paul Moore wrote:
> Hello all,
Good morning, I hope the day is going well for everyone.
> As most of you are likely aware, Stephen Smalley has been working on
> adding namespace support to SELinux, and the work has now progressed
> to the point where a serious discussion on the API is warranted. For
> those of you are unfamiliar with the details or Stephen's patchset, or
> simply need a refresher, he has some excellent documentation in his
> work-in-progress repo:
>
> * https://github.com/stephensmalley/selinuxns
>
> Stephen also gave a (pre-recorded) presentation at LSS-NA this year
> about SELinux namespacing, you can watch the presentation here:
>
> * https://www.youtube.com/watch?v=AwzGCOwxLoM
>
> In the past you've heard me state, rather firmly at times, that I
> believe namespacing at the LSM framework layer to be a mistake,
> although if there is something that can be done to help facilitate the
> namespacing of individual LSMs at the framework layer, I would be
> supportive of that. I think that a single LSM namespace API, similar
> to our recently added LSM syscalls, may be such a thing, so I'd like
> us to have a discussion to see if we all agree on that, and if so,
> what such an API might look like.
>
> At LSS-NA this year, John Johansen and I had a brief discussion where
> he suggested a single LSM wide clone*(2) flag that individual LSM's
> could opt into via callbacks. John is directly CC'd on this mail, so
> I'll let him expand on this idea.
>
> While I agree with John that a fs based API is problematic (see all of
> our discussions around the LSM syscalls), I'm concerned that a single
> clone*(2) flag will significantly limit our flexibility around how
> individual LSMs are namespaced, something I don't want to see happen.
> This makes me wonder about the potential for expanding
> lsm_set_self_attr(2) to support a new LSM attribute that would support
> a namespace "unshare" operation, e.g. LSM_ATTR_UNSHARE. This would
> provide a single LSM framework API for an unshare operation while also
> providing a mechanism to pass LSM specific via the lsm_ctx struct if
> needed. Just as we do with the other LSM_ATTR_* flags today,
> individual LSMs can opt-in to the API fairly easily by providing a
> setselfattr() LSM callback.
>
> Thoughts?
There has been an adage that traces back to the writings of George
Santayana in 1905 that seems relevant:
"Those who cannot remember the past are condemned to repeat it."
To that end, some input from more than a decade of our work on this
issue. Some of our reflections below are relevant to issues being
covered in downstream components of this thread, particularly by John
in the last few hours.
We have had code on the table for three years with respect to the
problem of generic namespacing of security policy/model/architecture,
whatever one chooses to call it.
For everyone's reference, here are the URL's to the patch series:
V1:
https://lore.kernel.org/linux-security-module/20230204050954.11583-1-greg@enjellic.com/T/#t
V2:
https://lore.kernel.org/linux-security-module/20230710102319.19716-1-greg@enjellic.com/T/#t
V3:
https://lore.kernel.org/linux-security-module/20240401105015.27614-1-greg@enjellic.com/T/#t
V4:
https://lore.kernel.org/linux-security-module/20240826103728.3378-1-greg@enjellic.com/T/#t
We started this work about 13-15 years ago. We initially described
our work and the need for it, 10 years ago almost to this day. See
our 2015 paper at the Linux Security Summit in Seattle.
James Morris and Casey were in the first row, Stephen and a co-worker
from the NSA were in the second row, to the speakers left.
If one spends some time looking under the hood, TSEM is in large part
about providing a generic framework for running multiple, independent
and orthogonal security frameworks/policies/architectures, whatever
one chooses to call these entities.
The reason that we argue that TSEM is a generic framework, is that in
our internal work, we have ported the major LSM's, including the IMA
infrastructure, to run in isolated namespaces as plugins for TSEM's
notion of Trusted Modeling Agents (TMA's). We also have ongoing work
that enables Kubernetes to dispatch workloads, using whatever LSM
based security policy that container developers desire for their
workloads.
Suffice it to say, we have howed a lot of ground on the issues
surrounding this, including issues surrounding production deployment
of this type of technology.
In our initial implementation, circa 2015, we adopted the approach of
using a CLONE_* flag and wired the implementation of security
namespaces into the rest of the namespace infrastructure.
During COVID, we re-architected the entire implementation and moved to
using a control file in the pseudo-filesystem that TSEM implements, we
have never looked back on this decision.
TSEM security workloads are a poster child for security namespaces
that require a number of different setup parameters. A command verb
syntax with key=value pairs, written to a pseudo-file, has proven
itself to be the most flexible approach when setting up security
workloads.
With respect to namespace transition, we trigger the transition of a
process to a new namespace (unsharing) when the process issues the
request via the control file. This has proven to be, at once, the
most straight forward and least security prone approach.
The other major, and thorny issue, is the notion of another process
'entering' a security namespace. There are a ton of open issues to be
considered with this, the approach that we took that has worked well
to date, is the notion of a 'trust orchestrator' that has
responsibility for controlling the namespace. Any manipulations or
control of the namespace are conducted through the orchestrator
process.
If anyone chooses to look at our implementation, you will find that we
'bless' the orchestrator process, at the time of namespace creation,
with access to the security namespace context control structure for
the namespace being created. The orchestrator is the only entity that
can access the security state of the namespace, other than processes
within the namespace itself.
This significantly narrows the scope of vulnerability with respect to
who or what can manipulate a security namespace. There are a number
of thorny issues, that we have not seen anyone mention, that surface
with respect to allowing entry into a security namespace by an
arbitrary process. Believe me when I say we have found a number of
them by accident and incident.
So big picture.
Over a decade of experience with these issues, suggests that Paul's
premise that most of these issues are best left to specific LSM's that
elect to implement namespacing, is correct.
The challenge is that this situation ends up being all or nothing.
The actual amount of code involved in unsharing a namespace is so
trivial, in comparison to the work involved with setting up and
maintaining state information for a security namespace context, that
it seems to make little sense to implement this support at the level
of the LSM infrastructure itself.
If the decision is made to provide generic namespace support, other
than a request to create a namespace, it will rapidly become a
slippery slope with respect to the amount of infrastructure needed to
address the complexities associated with every security model being
different from every other.
The caveat to this is if our notion of a 'trust orchestrator' would be
deemed to have merit. In that case, an LSM based namespace separation
architecture would provide a common point for the orchestrator to be
'blessed' with access to control of a namespace.
The other open issue is whether or not a separate capability should be
implemented that allows the creation of a new security namespace. If
one paws through our TSEM submissions, one will see that we proposed
such a capability bit.
Casey noted, rather emphatically, that no new capabilities were going
to be implemented in Linux, particularly for what was described as a
'toy' project. He indicated that CAP_MAC_ADMIN was the canonical
capability that should be used for manipulating LSM's.
We will be very interested in seeing how a discussion around this
evolves, as 'escaping' from an existing security context to a new one
is an extremely critical operation from a security perspective, if one
stands back and looks at the issue objectively. If the concept of a
'security orchestrator' is embraced, it would make perfect sense for
the orchestrator to drop CAP_SEC_NS, or whatever it would be called,
and retain CAP_MAC_ADMIN in order to manage the namespace.
So lots of issues to consider; thorny, political and otherwise, on
multiple fronts.
> paul-moore.com
Have a good day.
As always,
Dr. Greg
The Quixote Project - Flailing at the Travails of Cybersecurity
https://github.com/Quixote-Project
^ permalink raw reply
* Re: LSM namespacing API
From: Mickaël Salaün @ 2025-08-21 9:56 UTC (permalink / raw)
To: Paul Moore
Cc: Stephen Smalley, linux-security-module, selinux, John Johansen,
Maxime Bélair
In-Reply-To: <CAHC9VhS3c257ywxADRzPYE-DsXSwRp8P2RhAfdDnXJHOX5bXTQ@mail.gmail.com>
On Wed, Aug 20, 2025 at 04:47:15PM -0400, Paul Moore wrote:
> On Wed, Aug 20, 2025 at 10:44 AM Mickaël Salaün <mic@digikod.net> wrote:
> > On Tue, Aug 19, 2025 at 02:51:00PM -0400, Paul Moore wrote:
> > > On Tue, Aug 19, 2025 at 1:47 PM Stephen Smalley
> > > <stephen.smalley.work@gmail.com> wrote:
>
> ...
>
> > > Since we have an existing LSM namespace combination, with processes
> > > running inside of it, it might be sufficient to simply support moving
> > > into an existing LSM namespace set with setns(2) using only a pidfd
> > > and a new CLONE_LSMNS flag (or similar, upstream might want this as
> > > CLONE_NEWLSM). This would simply set the LSM namespace set for the
> >
> > Bike shedding but, I would prefer CLONE_NEWSEC or something without LSM
> > because the goal is not to add a new LSM but a new "security" namespace.
>
> I disagree with your statement about the goal. In fact I would argue
> that one of the goals is to explicitly *not* create a generic
> "security" namespace. Defining a single, LSM-wide namespace, is
> already an almost impossible task, extending it to become a generic
> "security" namespace seems maddening.
I didn't suggest a generic "security" namespace that would include
non-LSM access checks, just using the name "security" instead of "LSM",
but never mind.
>
> > > setns(2) caller to match that of the target pidfd. We still wouldn't
> > > want to support CLONE_LSMNS/CLONE_NEWLSM for clone*().
> >
> > Why making clone*() support this flag would be an issue?
>
> With the understanding that I'm not going to support a single LSM-wide
> namespace (see my previous comments), we would need multiple flags for
I'm confused about the goal of this thread... When I read namespace I
think about the user space interface that enables to tie a set of
processes to ambient kernel objects. I'm not suggesting to force all
LSM to handle namespaces, but to have a unified user space interface
(i.e. namespace flag, file descriptor...) that can be used by user space
to request a new "context" that may or may not be used by running LSMs.
> clone*(), one for each LSM that wanted to implement a namespace.
My understanding of this proposal was to create a LSM-wide namespace,
and one of the reason was to avoid one namespace per LSM. As I
explained in my previous email, I think it would make sense and could be
convincing.
> While clone3() has expanded the number of flag bits from clone(),
> there is still a limitation of 64-bits and I'm fairly certain the
> other kernel devs are not going to be supportive of a flag for each
> LSM that wants one.
>
> Maybe we could argue for our own u64 in cl_args, or create our own
> lsm_clone(2) syscall that mimics clone3(2) with better LSM support,
> but neither of these seem like great ideas at the moment.
My idea was that using CLONE_NEWLSM would just fork the current/initial
namespace used by LSMs to tie security policies/configurations to
processes, but as John already said, it would be the responsibility of
each LSM to either inherit and keep in sync the parent policy (e.g.
SELinux) or start with a blank/default one (e.g. Yama).
One way to configure a newly created namespace could be to load a
configuration in the parent namespace (e.g. with one of the new LSM
config syscall and a dedicated flag) that would only be applied to child
namespaces when they are created, similarly to attr/exec for execve(2).
I think this is what you meant with the LSM_UNSHARE flag, right?
>
> > > Any other ideas?
> >
> > The goal of a namespace is to configure absolute references (e.g. file
> > path, network address, PID, time). I think it would make sense to have
> > an LSM/MAC/SEC namespace that would enforce a consistent access control
> > on every processes in this namespace.
>
> Once again, I'm not going to support the idea of a namespace at the
> LSM framework layer, individual LSMs are better suited to implementing
> their own namespacing concepts. However, I do support the LSM
> framework providing an API and/or helpers to help make it easier for
> individual LSMs and userspace to create/manage individual LSM
> namespaces.
Should we still talk about "namespace" or use another name?
>
> > A related namespace file
> > descriptor could then be used with an LSM-specific syscall to configure
> > the policy related to a specific namespace (instead of only the current
> > namespace)
>
> That is a reasonable request, and I think the same underlying solution
> that we would use for setns(2) could also be used here.
I'm not sure having a set of namespace file descriptors without related
clone flags would be acceptable, at least for what we currently call
Linux "namespace".
^ permalink raw reply
* [PATCH] selftests: centralise maybe-unused definition in kselftest.h
From: Bala-Vignesh-Reddy @ 2025-08-21 10:11 UTC (permalink / raw)
To: akpm, shuah
Cc: mic, gnoack, david, lorenzo.stoakes, Liam.Howlett, vbabka, rppt,
surenb, mhocko, davem, edumazet, kuba, pabeni, horms, ming.lei,
skhan, linux-kselftest, linux-kernel, linux-security-module,
linux-mm, netdev, linux-fsdevel, linux-block,
reddybalavignesh9979
Several selftests subdirectories duplicated the define __maybe_unused,
leading to redundant code. Moved to kselftest.h header and removed
other definition.
This addresses the duplication noted in the proc-pid-vm warning fix
Suggested-by: Andrew Morton <akpm@linux-foundation.org>
Link:https://lore.kernel.org/lkml/20250820143954.33d95635e504e94df01930d0@linux-foundation.org/
Signed-off-by: Bala-Vignesh-Reddy <reddybalavignesh9979@gmail.com>
---
tools/testing/selftests/kselftest.h | 4 ++++
tools/testing/selftests/landlock/audit.h | 6 ++----
tools/testing/selftests/landlock/common.h | 4 ----
tools/testing/selftests/mm/pkey-helpers.h | 3 ---
tools/testing/selftests/net/psock_lib.h | 4 ----
tools/testing/selftests/perf_events/watermark_signal.c | 2 --
tools/testing/selftests/proc/proc-pid-vm.c | 4 ----
tools/testing/selftests/ublk/utils.h | 2 --
8 files changed, 6 insertions(+), 23 deletions(-)
diff --git a/tools/testing/selftests/kselftest.h b/tools/testing/selftests/kselftest.h
index c3b6d2604b1e..661d31c4b558 100644
--- a/tools/testing/selftests/kselftest.h
+++ b/tools/testing/selftests/kselftest.h
@@ -92,6 +92,10 @@
#endif
#define __printf(a, b) __attribute__((format(printf, a, b)))
+#ifndef __maybe_unused
+#define __maybe_unused __attribute__((__unused__))
+#endif
+
/* counters */
struct ksft_count {
unsigned int ksft_pass;
diff --git a/tools/testing/selftests/landlock/audit.h b/tools/testing/selftests/landlock/audit.h
index b16986aa6442..02fd1393947a 100644
--- a/tools/testing/selftests/landlock/audit.h
+++ b/tools/testing/selftests/landlock/audit.h
@@ -20,14 +20,12 @@
#include <sys/time.h>
#include <unistd.h>
+#include "../kselftest.h"
+
#ifndef ARRAY_SIZE
#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
#endif
-#ifndef __maybe_unused
-#define __maybe_unused __attribute__((__unused__))
-#endif
-
#define REGEX_LANDLOCK_PREFIX "^audit([0-9.:]\\+): domain=\\([0-9a-f]\\+\\)"
struct audit_filter {
diff --git a/tools/testing/selftests/landlock/common.h b/tools/testing/selftests/landlock/common.h
index 88a3c78f5d98..9acecae36f51 100644
--- a/tools/testing/selftests/landlock/common.h
+++ b/tools/testing/selftests/landlock/common.h
@@ -22,10 +22,6 @@
#define TMP_DIR "tmp"
-#ifndef __maybe_unused
-#define __maybe_unused __attribute__((__unused__))
-#endif
-
/* TEST_F_FORK() should not be used for new tests. */
#define TEST_F_FORK(fixture_name, test_name) TEST_F(fixture_name, test_name)
diff --git a/tools/testing/selftests/mm/pkey-helpers.h b/tools/testing/selftests/mm/pkey-helpers.h
index ea404f80e6cb..fa15f006fa68 100644
--- a/tools/testing/selftests/mm/pkey-helpers.h
+++ b/tools/testing/selftests/mm/pkey-helpers.h
@@ -84,9 +84,6 @@ extern void abort_hooks(void);
#ifndef noinline
# define noinline __attribute__((noinline))
#endif
-#ifndef __maybe_unused
-# define __maybe_unused __attribute__((__unused__))
-#endif
int sys_pkey_alloc(unsigned long flags, unsigned long init_val);
int sys_pkey_free(unsigned long pkey);
diff --git a/tools/testing/selftests/net/psock_lib.h b/tools/testing/selftests/net/psock_lib.h
index 6e4fef560873..067265b0a554 100644
--- a/tools/testing/selftests/net/psock_lib.h
+++ b/tools/testing/selftests/net/psock_lib.h
@@ -22,10 +22,6 @@
#define PORT_BASE 8000
-#ifndef __maybe_unused
-# define __maybe_unused __attribute__ ((__unused__))
-#endif
-
static __maybe_unused void pair_udp_setfilter(int fd)
{
/* the filter below checks for all of the following conditions that
diff --git a/tools/testing/selftests/perf_events/watermark_signal.c b/tools/testing/selftests/perf_events/watermark_signal.c
index e03fe1b9bba2..b3a72f0ac522 100644
--- a/tools/testing/selftests/perf_events/watermark_signal.c
+++ b/tools/testing/selftests/perf_events/watermark_signal.c
@@ -17,8 +17,6 @@
#include "../kselftest_harness.h"
-#define __maybe_unused __attribute__((__unused__))
-
static int sigio_count;
static void handle_sigio(int signum __maybe_unused,
diff --git a/tools/testing/selftests/proc/proc-pid-vm.c b/tools/testing/selftests/proc/proc-pid-vm.c
index 978cbcb3eb11..2a72d37ad008 100644
--- a/tools/testing/selftests/proc/proc-pid-vm.c
+++ b/tools/testing/selftests/proc/proc-pid-vm.c
@@ -47,10 +47,6 @@
#include <sys/resource.h>
#include <linux/fs.h>
-#ifndef __maybe_unused
-#define __maybe_unused __attribute__((__unused__))
-#endif
-
#include "../kselftest.h"
static inline long sys_execveat(int dirfd, const char *pathname, char **argv, char **envp, int flags)
diff --git a/tools/testing/selftests/ublk/utils.h b/tools/testing/selftests/ublk/utils.h
index 36545d1567f1..a852e0b7153e 100644
--- a/tools/testing/selftests/ublk/utils.h
+++ b/tools/testing/selftests/ublk/utils.h
@@ -2,8 +2,6 @@
#ifndef KUBLK_UTILS_H
#define KUBLK_UTILS_H
-#define __maybe_unused __attribute__((unused))
-
#ifndef min
#define min(a, b) ((a) < (b) ? (a) : (b))
#endif
--
2.43.0
^ permalink raw reply related
* Re: LSM namespacing API
From: Mickaël Salaün @ 2025-08-21 10:00 UTC (permalink / raw)
To: Paul Moore
Cc: Casey Schaufler, linux-security-module, selinux, John Johansen,
Stephen Smalley, Maxime Bélair
In-Reply-To: <CAHC9VhQ5Vs+_DYAcN_Z4M9PVqW=PjaHcr4sVXADU5yqp1zFHVQ@mail.gmail.com>
On Tue, Aug 19, 2025 at 02:40:52PM -0400, Paul Moore wrote:
> On Tue, Aug 19, 2025 at 1:11 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >
> > The advantage of a clone flag is that the operation is atomic with
> > the other namespace flag based behaviors. Having a two step process
> >
> > clone(); lsm_set_self_attr(); - or -
> > lsm_set_self_attr(); clone();
> >
> > is going to lead to cases where neither order really works correctly.
>
> I was envisioning something that works similarly to LSM_ATTR_EXEC
> where the unshare isn't immediate, but rather happens at a future
> event. With LSM_ATTR_EXEC it happens at the next exec*(), with
> LSM_ATTR_UNSHARE I imagine it would happen at the next clone*().
The next unshare(2) would make more sense to me.
This deferred operation could be requested with a flag in
lsm_config_system_policy(2) instead:
https://lore.kernel.org/r/20250709080220.110947-1-maxime.belair@canonical.com
^ permalink raw reply
* Re: LSM namespacing API
From: John Johansen @ 2025-08-21 8:12 UTC (permalink / raw)
To: Paul Moore, Serge E. Hallyn
Cc: Stephen Smalley, linux-security-module, selinux
In-Reply-To: <CAHC9VhR-5Rwg132UsLdpJgM0c51HYBrBDivBinw3YcYqe0QTKA@mail.gmail.com>
On 8/20/25 19:35, Paul Moore wrote:
> On Wed, Aug 20, 2025 at 10:05 PM Serge E. Hallyn <serge@hallyn.com> wrote:
>> On Tue, Aug 19, 2025 at 02:51:00PM -0400, Paul Moore wrote:
>>> On Tue, Aug 19, 2025 at 1:47 PM Stephen Smalley
>>> <stephen.smalley.work@gmail.com> wrote:
>
> ...
>
>>>> Serge pointed out that we also will need an API to attach to an
>>>> existing SELinux namespace, which I captured here:
>>>> https://github.com/stephensmalley/selinuxns/issues/19
>>>> This is handled for other Linux namespaces by opening a pseudo file
>>>> under /proc/pid/ns and invoking setns(2), so not sure how we want to
>>>> do it.
>>>
>>> One option would be to have a the LSM framework return a LSM namespace
>>> "handle" for a given LSM using lsm_get_self_attr(2) and then do a
>>> setns(2)-esque operation using lsm_set_self_attr(2) with that
>>> "handle". We would need to figure out what would constitute a
>>> "handle" but let's just mark that as TBD for now with this approach (I
>>> think better options are available).
>>
>> The use case which would be complicated (not blocked) by this, is
>>
>> * a runtime creates a process p1
>> * p1 unshares its lsm namespace
>> * runtime forks a debug/admin process p2
>> * p2 wants to enter p1's namespace
>>
>> Of course the runtime could work around it by, before relinquishing
>> control of p1 to a new executable, returning the lsm_get_self_attr()
>> data to over a pipe.
>>
>> Note I don't think we should support setting another task's namespace,
>> only getting its namespace ID.
>>
>>> Since we have an existing LSM namespace combination, with processes
>>> running inside of it, it might be sufficient to simply support moving
>>> into an existing LSM namespace set with setns(2) using only a pidfd
>>> and a new CLONE_LSMNS flag (or similar, upstream might want this as
>>> CLONE_NEWLSM). This would simply set the LSM namespace set for the
>>> setns(2) caller to match that of the target pidfd. We still wouldn't
>>> want to support CLONE_LSMNS/CLONE_NEWLSM for clone*().
>>
>> A part of me is telling (another part of) me that being able to setns
>> to a subset of the lsms could lead to privilege escapes through
>> weird policy configurations for the various LSMs. In which case,
>> an all-or-nothing LSM setns might actually be preferable.
>
> Sorry I probably wasn't as clear as I should have been, but my idea
> with using the existing procfs/setns(2) approach with a single
> CLONE_NEWLSM (name pending sufficient bikeshedding) was that the
> process being setns()'d would simply end up in the exact copy of the
> target process' LSM namespace configuration, it shouldn't be a new
> set/subset/configuration ... and I would expect us to have controls
> around that such that LSMs could enforce policy on a setns(2)
> operation that involved their LSM.
>
entering as a complete set, is certainly the safest. At a minim the
LSMs are going to need to be able to specify the set of namespaces
the are needed if you enter the LSM namespace. The easiest way to
do this is what you propose, take away the flexibility and allow
moving everything as a set.
I do think we might still have a need to be able to request entering
an LSM namespace from the set, but I think that at least for a first
its probably better to not go there.
^ permalink raw reply
* Re: LSM namespacing API
From: John Johansen @ 2025-08-21 8:07 UTC (permalink / raw)
To: Serge E. Hallyn, Paul Moore
Cc: Stephen Smalley, linux-security-module, selinux
In-Reply-To: <aKZ+2NMx+ZQhpySY@mail.hallyn.com>
On 8/20/25 19:05, Serge E. Hallyn wrote:
> On Tue, Aug 19, 2025 at 02:51:00PM -0400, Paul Moore wrote:
>> On Tue, Aug 19, 2025 at 1:47 PM Stephen Smalley
>> <stephen.smalley.work@gmail.com> wrote:
>>>
>>> I think we want to be able to unshare a specific security module
>>> namespace without unsharing the others, i.e. just SELinux or just
>>> AppArmor.
>>> Not sure if your suggestion above supports that already but wanted to note it.
>>
>> The lsm_set_self_attr(2) approach allows for LSM specific unshare
>> operations. Take the existing LSM_ATTR_EXEC attribute as an example,
>> two LSMs have implemented support (AppArmor and SELinux), and
>> userspace can independently set the attribute as desired for each LSM.
>
> Overall I really like the idea.
>
>>> Serge pointed out that we also will need an API to attach to an
>>> existing SELinux namespace, which I captured here:
>>> https://github.com/stephensmalley/selinuxns/issues/19
>>> This is handled for other Linux namespaces by opening a pseudo file
>>> under /proc/pid/ns and invoking setns(2), so not sure how we want to
>>> do it.
>>
>> One option would be to have a the LSM framework return a LSM namespace
>> "handle" for a given LSM using lsm_get_self_attr(2) and then do a
>> setns(2)-esque operation using lsm_set_self_attr(2) with that
>> "handle". We would need to figure out what would constitute a
>> "handle" but let's just mark that as TBD for now with this approach (I
>> think better options are available).
>
> The use case which would be complicated (not blocked) by this, is
>
> * a runtime creates a process p1
> * p1 unshares its lsm namespace
> * runtime forks a debug/admin process p2
> * p2 wants to enter p1's namespace
>
> Of course the runtime could work around it by, before relinquishing
> control of p1 to a new executable, returning the lsm_get_self_attr()
> data to over a pipe.
>
> Note I don't think we should support setting another task's namespace,
> only getting its namespace ID.
>
its not reasonably doable without a significant update to the creds
architecture. Its an orthogal feature, being able to set another task's
credentials and as such can be saved for another argument. So very
much in agreement, lets not allow that as part of the design.
>> Since we have an existing LSM namespace combination, with processes
>> running inside of it, it might be sufficient to simply support moving
>> into an existing LSM namespace set with setns(2) using only a pidfd
>> and a new CLONE_LSMNS flag (or similar, upstream might want this as
>> CLONE_NEWLSM). This would simply set the LSM namespace set for the
>> setns(2) caller to match that of the target pidfd. We still wouldn't
>> want to support CLONE_LSMNS/CLONE_NEWLSM for clone*().
>
> A part of me is telling (another part of) me that being able to setns
> to a subset of the lsms could lead to privilege escapes through
> weird policy configurations for the various LSMs. In which case,
> an all-or-nothing LSM setns might actually be preferable.
>
> I haven't thought of a concrete example, though.
>
Not just potentially, and not just security/LSM namespaces. Really
the LSMs need to be able to determine whether/which namespaces (including
system namespaces) need to move together as a set.
^ permalink raw reply
* Re: LSM namespacing API
From: John Johansen @ 2025-08-21 7:46 UTC (permalink / raw)
To: Stephen Smalley, Paul Moore; +Cc: linux-security-module, selinux
In-Reply-To: <CAEjxPJ5EvR+2fboLu_nBGZu+ZVUpX4KM6xdPUqDErCmw=iA37g@mail.gmail.com>
On 8/19/25 10:47, Stephen Smalley wrote:
> On Tue, Aug 19, 2025 at 10:56 AM Paul Moore <paul@paul-moore.com> wrote:
>>
>> Hello all,
>>
>> As most of you are likely aware, Stephen Smalley has been working on
>> adding namespace support to SELinux, and the work has now progressed
>> to the point where a serious discussion on the API is warranted. For
>> those of you are unfamiliar with the details or Stephen's patchset, or
>> simply need a refresher, he has some excellent documentation in his
>> work-in-progress repo:
>>
>> * https://github.com/stephensmalley/selinuxns
>>
>> Stephen also gave a (pre-recorded) presentation at LSS-NA this year
>> about SELinux namespacing, you can watch the presentation here:
>>
>> * https://www.youtube.com/watch?v=AwzGCOwxLoM
>>
>> In the past you've heard me state, rather firmly at times, that I
>> believe namespacing at the LSM framework layer to be a mistake,
>> although if there is something that can be done to help facilitate the
>> namespacing of individual LSMs at the framework layer, I would be
>> supportive of that. I think that a single LSM namespace API, similar
>> to our recently added LSM syscalls, may be such a thing, so I'd like
>> us to have a discussion to see if we all agree on that, and if so,
>> what such an API might look like.
>>
>> At LSS-NA this year, John Johansen and I had a brief discussion where
>> he suggested a single LSM wide clone*(2) flag that individual LSM's
>> could opt into via callbacks. John is directly CC'd on this mail, so
>> I'll let him expand on this idea.
>>
>> While I agree with John that a fs based API is problematic (see all of
>> our discussions around the LSM syscalls), I'm concerned that a single
>> clone*(2) flag will significantly limit our flexibility around how
>> individual LSMs are namespaced, something I don't want to see happen.
>> This makes me wonder about the potential for expanding
>> lsm_set_self_attr(2) to support a new LSM attribute that would support
>> a namespace "unshare" operation, e.g. LSM_ATTR_UNSHARE. This would
>> provide a single LSM framework API for an unshare operation while also
>> providing a mechanism to pass LSM specific via the lsm_ctx struct if
>> needed. Just as we do with the other LSM_ATTR_* flags today,
>> individual LSMs can opt-in to the API fairly easily by providing a
>> setselfattr() LSM callback.
>>
>> Thoughts?
>
> I think we want to be able to unshare a specific security module
> namespace without unsharing the others, i.e. just SELinux or just
> AppArmor.
yes which is part of the problem with the single flag. That choice
would be entirely at the policy level, without any input from userspace.
I still think the policy may decide something different than what
userspace requests but that just means the namespacing of an LSM is
under the individual LSMs controls and not the infrastructures.
Eg. selinux is using hierarchical namespaces, so when asked for a
new namespace you will get the bounding hierarchy, but yama (if it
ever gets namespace support) could very well just use independent
namespaces.
> Not sure if your suggestion above supports that already but wanted to note it.
> Regardless, I have no objections to any system call or flag that can
> be used to unshare the SELinux namespace and it should be trivial to
> wire it up to the existing underlying function.
> Serge pointed out that we also will need an API to attach to an
> existing SELinux namespace, which I captured here:
> https://github.com/stephensmalley/selinuxns/issues/19
yes a mechanism to switch is needed, but I also strongly dislike
setns(2). For security purposes we definitely want to control whether
the LSM namespace is associated with other system namespaces.
> This is handled for other Linux namespaces by opening a pseudo file
> under /proc/pid/ns and invoking setns(2), so not sure how we want to
> do it.
That is a possible interface, not one that I like, so I would like to
explore other options first.
^ permalink raw reply
* Re: LSM namespacing API
From: John Johansen @ 2025-08-21 7:26 UTC (permalink / raw)
To: Stephen Smalley, Paul Moore
Cc: Casey Schaufler, linux-security-module, selinux
In-Reply-To: <CAEjxPJ7NpSdfUZzzj0SnN8WuUv7E9SEj5v28x_y8R178_JMESA@mail.gmail.com>
On 8/19/25 11:58, Stephen Smalley wrote:
> On Tue, Aug 19, 2025 at 2:41 PM Paul Moore <paul@paul-moore.com> wrote:
>>
>> On Tue, Aug 19, 2025 at 1:11 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>
>>> The advantage of a clone flag is that the operation is atomic with
>>> the other namespace flag based behaviors. Having a two step process
>>>
>>> clone(); lsm_set_self_attr(); - or -
>>> lsm_set_self_attr(); clone();
>>>
>>> is going to lead to cases where neither order really works correctly.
>>
>> I was envisioning something that works similarly to LSM_ATTR_EXEC
>> where the unshare isn't immediate, but rather happens at a future
>> event. With LSM_ATTR_EXEC it happens at the next exec*(), with
>> LSM_ATTR_UNSHARE I imagine it would happen at the next clone*().
>
> I've only implemented support for an immediate unsharing of the
> SELinux namespace, not any kind of deferred unsharing until the next
> exec or clone.
> Not saying that would be impossible, but since I was following the
> example of clone(2) and unshare(2) I didn't do it.
> May be some complications in doing so, but I haven't looked at it yet.
if the hooks are setup correctly I expect it will actually remove some
potential complications. But I haven't deep dived the selinux code
yet so call that an uninformed hunch.
^ permalink raw reply
* Re: LSM namespacing API
From: John Johansen @ 2025-08-21 7:23 UTC (permalink / raw)
To: Paul Moore, Casey Schaufler
Cc: linux-security-module, selinux, Stephen Smalley
In-Reply-To: <CAHC9VhQ5Vs+_DYAcN_Z4M9PVqW=PjaHcr4sVXADU5yqp1zFHVQ@mail.gmail.com>
On 8/19/25 11:40, Paul Moore wrote:
> On Tue, Aug 19, 2025 at 1:11 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>
>> The advantage of a clone flag is that the operation is atomic with
>> the other namespace flag based behaviors. Having a two step process
>>
>> clone(); lsm_set_self_attr(); - or -
>> lsm_set_self_attr(); clone();
>>
>> is going to lead to cases where neither order really works correctly.
>
> I was envisioning something that works similarly to LSM_ATTR_EXEC
> where the unshare isn't immediate, but rather happens at a future
> event. With LSM_ATTR_EXEC it happens at the next exec*(), with
> LSM_ATTR_UNSHARE I imagine it would happen at the next clone*().
>
I do think something like this is needed to deal well with the two
step process. Without it is fairly easy to get into situations
where you either need more permissions, than strictly necessary,
because of steps in between or as Casey says things just don't work
correctly.
There will need to be an additional call that allows entering a
namespace separately from clone/unshare, but that covers a different
use case.
^ permalink raw reply
* Re: LSM namespacing API
From: John Johansen @ 2025-08-21 7:14 UTC (permalink / raw)
To: Paul Moore, linux-security-module, selinux; +Cc: Stephen Smalley
In-Reply-To: <CAHC9VhRGMmhxbajwQNfGFy+ZFF1uN=UEBjqQZQ4UBy7yds3eVQ@mail.gmail.com>
On 8/19/25 07:56, Paul Moore wrote:
> Hello all,
>
> As most of you are likely aware, Stephen Smalley has been working on
> adding namespace support to SELinux, and the work has now progressed
> to the point where a serious discussion on the API is warranted. For
> those of you are unfamiliar with the details or Stephen's patchset, or
> simply need a refresher, he has some excellent documentation in his
> work-in-progress repo:
>
> * https://github.com/stephensmalley/selinuxns
>
> Stephen also gave a (pre-recorded) presentation at LSS-NA this year
> about SELinux namespacing, you can watch the presentation here:
>
> * https://www.youtube.com/watch?v=AwzGCOwxLoM
>
> In the past you've heard me state, rather firmly at times, that I
> believe namespacing at the LSM framework layer to be a mistake,
> although if there is something that can be done to help facilitate the
> namespacing of individual LSMs at the framework layer, I would be
> supportive of that. I think that a single LSM namespace API, similar
> to our recently added LSM syscalls, may be such a thing, so I'd like
> us to have a discussion to see if we all agree on that, and if so,
> what such an API might look like.
>
> At LSS-NA this year, John Johansen and I had a brief discussion where
> he suggested a single LSM wide clone*(2) flag that individual LSM's
> could opt into via callbacks. John is directly CC'd on this mail, so
> I'll let him expand on this idea.
>
> While I agree with John that a fs based API is problematic (see all of
> our discussions around the LSM syscalls), I'm concerned that a single
> clone*(2) flag will significantly limit our flexibility around how
> individual LSMs are namespaced, something I don't want to see happen.
> This makes me wonder about the potential for expanding
> lsm_set_self_attr(2) to support a new LSM attribute that would support
> a namespace "unshare" operation, e.g. LSM_ATTR_UNSHARE. This would
> provide a single LSM framework API for an unshare operation while also
> providing a mechanism to pass LSM specific via the lsm_ctx struct if
> needed. Just as we do with the other LSM_ATTR_* flags today,
> individual LSMs can opt-in to the API fairly easily by providing a
> setselfattr() LSM callback.
>
> Thoughts?
>
sorry I have been deal with a forced email migration that uhhmmm hasn't
gone well.
So yes we could do a single clone flag, but it does have significant
issues, and is not generic enough for every LSM, at least not without
some form of providing augmented information.
A single clone flag means each LSM is completely in charge of its
transitions (needed) but without any hinting from userspace container
managers (this is a problem). Under the single flag, policy would have
to drive what can be done, and that would be fairly limiting. It would
allow for something like the current MCS labeling approach but not a
finer Udica style approach, at least not without an addition call
similar to setexeccon(), or as you have proposed more generically
LSM_ATTR_UNSHARE.
The more I have looked at it. The single clone flag approach is wrong
and is just going to lead to problems.
^ permalink raw reply
* Re: LSM namespacing API
From: Serge E. Hallyn @ 2025-08-21 3:02 UTC (permalink / raw)
To: Paul Moore
Cc: Serge E. Hallyn, Stephen Smalley, linux-security-module, selinux,
John Johansen
In-Reply-To: <CAHC9VhR-5Rwg132UsLdpJgM0c51HYBrBDivBinw3YcYqe0QTKA@mail.gmail.com>
On Wed, Aug 20, 2025 at 10:35:42PM -0400, Paul Moore wrote:
> On Wed, Aug 20, 2025 at 10:05 PM Serge E. Hallyn <serge@hallyn.com> wrote:
> > On Tue, Aug 19, 2025 at 02:51:00PM -0400, Paul Moore wrote:
> > > On Tue, Aug 19, 2025 at 1:47 PM Stephen Smalley
> > > <stephen.smalley.work@gmail.com> wrote:
>
> ...
>
> > > > Serge pointed out that we also will need an API to attach to an
> > > > existing SELinux namespace, which I captured here:
> > > > https://github.com/stephensmalley/selinuxns/issues/19
> > > > This is handled for other Linux namespaces by opening a pseudo file
> > > > under /proc/pid/ns and invoking setns(2), so not sure how we want to
> > > > do it.
> > >
> > > One option would be to have a the LSM framework return a LSM namespace
> > > "handle" for a given LSM using lsm_get_self_attr(2) and then do a
> > > setns(2)-esque operation using lsm_set_self_attr(2) with that
> > > "handle". We would need to figure out what would constitute a
> > > "handle" but let's just mark that as TBD for now with this approach (I
> > > think better options are available).
> >
> > The use case which would be complicated (not blocked) by this, is
> >
> > * a runtime creates a process p1
> > * p1 unshares its lsm namespace
> > * runtime forks a debug/admin process p2
> > * p2 wants to enter p1's namespace
> >
> > Of course the runtime could work around it by, before relinquishing
> > control of p1 to a new executable, returning the lsm_get_self_attr()
> > data to over a pipe.
> >
> > Note I don't think we should support setting another task's namespace,
> > only getting its namespace ID.
> >
> > > Since we have an existing LSM namespace combination, with processes
> > > running inside of it, it might be sufficient to simply support moving
> > > into an existing LSM namespace set with setns(2) using only a pidfd
> > > and a new CLONE_LSMNS flag (or similar, upstream might want this as
> > > CLONE_NEWLSM). This would simply set the LSM namespace set for the
> > > setns(2) caller to match that of the target pidfd. We still wouldn't
> > > want to support CLONE_LSMNS/CLONE_NEWLSM for clone*().
> >
> > A part of me is telling (another part of) me that being able to setns
> > to a subset of the lsms could lead to privilege escapes through
> > weird policy configurations for the various LSMs. In which case,
> > an all-or-nothing LSM setns might actually be preferable.
>
> Sorry I probably wasn't as clear as I should have been, but my idea
> with using the existing procfs/setns(2) approach with a single
> CLONE_NEWLSM (name pending sufficient bikeshedding) was that the
> process being setns()'d would simply end up in the exact copy of the
> target process' LSM namespace configuration, it shouldn't be a new
Oh, I think I was being unclear - I thought the first option, using
lsm_set_self_attr(), would allow choosing a subset of LSMs to setns to.
In contrast, the pure setns with a single flag is less flexible, but
possibly safer. So I typed there the result of my train of thought,
which is that your second suggestion is probably preferable.
> set/subset/configuration ... and I would expect us to have controls
> around that such that LSMs could enforce policy on a setns(2)
> operation that involved their LSM.
^ permalink raw reply
* Re: LSM namespacing API
From: Paul Moore @ 2025-08-21 2:35 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Stephen Smalley, linux-security-module, selinux, John Johansen
In-Reply-To: <aKZ+2NMx+ZQhpySY@mail.hallyn.com>
On Wed, Aug 20, 2025 at 10:05 PM Serge E. Hallyn <serge@hallyn.com> wrote:
> On Tue, Aug 19, 2025 at 02:51:00PM -0400, Paul Moore wrote:
> > On Tue, Aug 19, 2025 at 1:47 PM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
...
> > > Serge pointed out that we also will need an API to attach to an
> > > existing SELinux namespace, which I captured here:
> > > https://github.com/stephensmalley/selinuxns/issues/19
> > > This is handled for other Linux namespaces by opening a pseudo file
> > > under /proc/pid/ns and invoking setns(2), so not sure how we want to
> > > do it.
> >
> > One option would be to have a the LSM framework return a LSM namespace
> > "handle" for a given LSM using lsm_get_self_attr(2) and then do a
> > setns(2)-esque operation using lsm_set_self_attr(2) with that
> > "handle". We would need to figure out what would constitute a
> > "handle" but let's just mark that as TBD for now with this approach (I
> > think better options are available).
>
> The use case which would be complicated (not blocked) by this, is
>
> * a runtime creates a process p1
> * p1 unshares its lsm namespace
> * runtime forks a debug/admin process p2
> * p2 wants to enter p1's namespace
>
> Of course the runtime could work around it by, before relinquishing
> control of p1 to a new executable, returning the lsm_get_self_attr()
> data to over a pipe.
>
> Note I don't think we should support setting another task's namespace,
> only getting its namespace ID.
>
> > Since we have an existing LSM namespace combination, with processes
> > running inside of it, it might be sufficient to simply support moving
> > into an existing LSM namespace set with setns(2) using only a pidfd
> > and a new CLONE_LSMNS flag (or similar, upstream might want this as
> > CLONE_NEWLSM). This would simply set the LSM namespace set for the
> > setns(2) caller to match that of the target pidfd. We still wouldn't
> > want to support CLONE_LSMNS/CLONE_NEWLSM for clone*().
>
> A part of me is telling (another part of) me that being able to setns
> to a subset of the lsms could lead to privilege escapes through
> weird policy configurations for the various LSMs. In which case,
> an all-or-nothing LSM setns might actually be preferable.
Sorry I probably wasn't as clear as I should have been, but my idea
with using the existing procfs/setns(2) approach with a single
CLONE_NEWLSM (name pending sufficient bikeshedding) was that the
process being setns()'d would simply end up in the exact copy of the
target process' LSM namespace configuration, it shouldn't be a new
set/subset/configuration ... and I would expect us to have controls
around that such that LSMs could enforce policy on a setns(2)
operation that involved their LSM.
--
paul-moore.com
^ permalink raw reply
* Re: LSM namespacing API
From: Serge E. Hallyn @ 2025-08-21 2:05 UTC (permalink / raw)
To: Paul Moore; +Cc: Stephen Smalley, linux-security-module, selinux, John Johansen
In-Reply-To: <CAHC9VhSubXA4tAUoz7T==UvfrM_DXS6nF5s0tJZ1HrrVizMgZA@mail.gmail.com>
On Tue, Aug 19, 2025 at 02:51:00PM -0400, Paul Moore wrote:
> On Tue, Aug 19, 2025 at 1:47 PM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> >
> > I think we want to be able to unshare a specific security module
> > namespace without unsharing the others, i.e. just SELinux or just
> > AppArmor.
> > Not sure if your suggestion above supports that already but wanted to note it.
>
> The lsm_set_self_attr(2) approach allows for LSM specific unshare
> operations. Take the existing LSM_ATTR_EXEC attribute as an example,
> two LSMs have implemented support (AppArmor and SELinux), and
> userspace can independently set the attribute as desired for each LSM.
Overall I really like the idea.
> > Serge pointed out that we also will need an API to attach to an
> > existing SELinux namespace, which I captured here:
> > https://github.com/stephensmalley/selinuxns/issues/19
> > This is handled for other Linux namespaces by opening a pseudo file
> > under /proc/pid/ns and invoking setns(2), so not sure how we want to
> > do it.
>
> One option would be to have a the LSM framework return a LSM namespace
> "handle" for a given LSM using lsm_get_self_attr(2) and then do a
> setns(2)-esque operation using lsm_set_self_attr(2) with that
> "handle". We would need to figure out what would constitute a
> "handle" but let's just mark that as TBD for now with this approach (I
> think better options are available).
The use case which would be complicated (not blocked) by this, is
* a runtime creates a process p1
* p1 unshares its lsm namespace
* runtime forks a debug/admin process p2
* p2 wants to enter p1's namespace
Of course the runtime could work around it by, before relinquishing
control of p1 to a new executable, returning the lsm_get_self_attr()
data to over a pipe.
Note I don't think we should support setting another task's namespace,
only getting its namespace ID.
> Since we have an existing LSM namespace combination, with processes
> running inside of it, it might be sufficient to simply support moving
> into an existing LSM namespace set with setns(2) using only a pidfd
> and a new CLONE_LSMNS flag (or similar, upstream might want this as
> CLONE_NEWLSM). This would simply set the LSM namespace set for the
> setns(2) caller to match that of the target pidfd. We still wouldn't
> want to support CLONE_LSMNS/CLONE_NEWLSM for clone*().
A part of me is telling (another part of) me that being able to setns
to a subset of the lsms could lead to privilege escapes through
weird policy configurations for the various LSMs. In which case,
an all-or-nothing LSM setns might actually be preferable.
I haven't thought of a concrete example, though.
> Any other ideas?
>
> --
> paul-moore.com
^ permalink raw reply
* Re: LSM namespacing API
From: Paul Moore @ 2025-08-20 20:47 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Stephen Smalley, linux-security-module, selinux, John Johansen,
Maxime Bélair
In-Reply-To: <20250820.ieNg1quoRouz@digikod.net>
On Wed, Aug 20, 2025 at 10:44 AM Mickaël Salaün <mic@digikod.net> wrote:
> On Tue, Aug 19, 2025 at 02:51:00PM -0400, Paul Moore wrote:
> > On Tue, Aug 19, 2025 at 1:47 PM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
...
> > Since we have an existing LSM namespace combination, with processes
> > running inside of it, it might be sufficient to simply support moving
> > into an existing LSM namespace set with setns(2) using only a pidfd
> > and a new CLONE_LSMNS flag (or similar, upstream might want this as
> > CLONE_NEWLSM). This would simply set the LSM namespace set for the
>
> Bike shedding but, I would prefer CLONE_NEWSEC or something without LSM
> because the goal is not to add a new LSM but a new "security" namespace.
I disagree with your statement about the goal. In fact I would argue
that one of the goals is to explicitly *not* create a generic
"security" namespace. Defining a single, LSM-wide namespace, is
already an almost impossible task, extending it to become a generic
"security" namespace seems maddening.
> > setns(2) caller to match that of the target pidfd. We still wouldn't
> > want to support CLONE_LSMNS/CLONE_NEWLSM for clone*().
>
> Why making clone*() support this flag would be an issue?
With the understanding that I'm not going to support a single LSM-wide
namespace (see my previous comments), we would need multiple flags for
clone*(), one for each LSM that wanted to implement a namespace.
While clone3() has expanded the number of flag bits from clone(),
there is still a limitation of 64-bits and I'm fairly certain the
other kernel devs are not going to be supportive of a flag for each
LSM that wants one.
Maybe we could argue for our own u64 in cl_args, or create our own
lsm_clone(2) syscall that mimics clone3(2) with better LSM support,
but neither of these seem like great ideas at the moment.
> > Any other ideas?
>
> The goal of a namespace is to configure absolute references (e.g. file
> path, network address, PID, time). I think it would make sense to have
> an LSM/MAC/SEC namespace that would enforce a consistent access control
> on every processes in this namespace.
Once again, I'm not going to support the idea of a namespace at the
LSM framework layer, individual LSMs are better suited to implementing
their own namespacing concepts. However, I do support the LSM
framework providing an API and/or helpers to help make it easier for
individual LSMs and userspace to create/manage individual LSM
namespaces.
> A related namespace file
> descriptor could then be used with an LSM-specific syscall to configure
> the policy related to a specific namespace (instead of only the current
> namespace)
That is a reasonable request, and I think the same underlying solution
that we would use for setns(2) could also be used here.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v5 2/3] lsm: introduce security_lsm_config_*_policy hooks
From: Casey Schaufler @ 2025-08-20 15:30 UTC (permalink / raw)
To: Mickaël Salaün, Maxime Bélair
Cc: linux-security-module, john.johansen, paul, jmorris, serge, kees,
stephen.smalley.work, takedakn, penguin-kernel, song, rdunlap,
linux-api, apparmor, linux-kernel, Casey Schaufler
In-Reply-To: <20250820.Ao3iquoshaiB@digikod.net>
On 8/20/2025 7:21 AM, Mickaël Salaün wrote:
> On Wed, Jul 09, 2025 at 10:00:55AM +0200, Maxime Bélair wrote:
>> Define two new LSM hooks: security_lsm_config_self_policy and
>> security_lsm_config_system_policy and wire them into the corresponding
>> lsm_config_*_policy() syscalls so that LSMs can register a unified
>> interface for policy management. This initial, minimal implementation
>> only supports the LSM_POLICY_LOAD operation to limit changes.
>>
>> Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
>> ---
>> include/linux/lsm_hook_defs.h | 4 +++
>> include/linux/security.h | 20 ++++++++++++
>> include/uapi/linux/lsm.h | 8 +++++
>> security/lsm_syscalls.c | 17 ++++++++--
>> security/security.c | 60 +++++++++++++++++++++++++++++++++++
>> 5 files changed, 107 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
>> index bf3bbac4e02a..fca490444643 100644
>> --- a/include/linux/lsm_hook_defs.h
>> +++ b/include/linux/lsm_hook_defs.h
>> @@ -464,3 +464,7 @@ LSM_HOOK(int, 0, bdev_alloc_security, struct block_device *bdev)
>> LSM_HOOK(void, LSM_RET_VOID, bdev_free_security, struct block_device *bdev)
>> LSM_HOOK(int, 0, bdev_setintegrity, struct block_device *bdev,
>> enum lsm_integrity_type type, const void *value, size_t size)
>> +LSM_HOOK(int, -EINVAL, lsm_config_self_policy, u32 lsm_id, u32 op,
>> + void __user *buf, size_t size, u32 flags)
>> +LSM_HOOK(int, -EINVAL, lsm_config_system_policy, u32 lsm_id, u32 op,
>> + void __user *buf, size_t size, u32 flags)
>> diff --git a/include/linux/security.h b/include/linux/security.h
>> index cc9b54d95d22..54acaee4a994 100644
>> --- a/include/linux/security.h
>> +++ b/include/linux/security.h
>> @@ -581,6 +581,11 @@ void security_bdev_free(struct block_device *bdev);
>> int security_bdev_setintegrity(struct block_device *bdev,
>> enum lsm_integrity_type type, const void *value,
>> size_t size);
>> +int security_lsm_config_self_policy(u32 lsm_id, u32 op, void __user *buf,
>> + size_t size, u32 flags);
>> +int security_lsm_config_system_policy(u32 lsm_id, u32 op, void __user *buf,
>> + size_t size, u32 flags);
>> +
>> #else /* CONFIG_SECURITY */
>>
>> /**
>> @@ -1603,6 +1608,21 @@ static inline int security_bdev_setintegrity(struct block_device *bdev,
>> return 0;
>> }
>>
>> +static inline int security_lsm_config_self_policy(u32 lsm_id, u32 op,
>> + void __user *buf,
>> + size_t size, u32 flags)
>> +{
>> +
>> + return -EOPNOTSUPP;
>> +}
>> +
>> +static inline int security_lsm_config_system_policy(u32 lsm_id, u32 op,
>> + void __user *buf,
>> + size_t size, u32 flags)
>> +{
>> +
>> + return -EOPNOTSUPP;
>> +}
>> #endif /* CONFIG_SECURITY */
>>
>> #if defined(CONFIG_SECURITY) && defined(CONFIG_WATCH_QUEUE)
>> diff --git a/include/uapi/linux/lsm.h b/include/uapi/linux/lsm.h
>> index 938593dfd5da..2b9432a30cdc 100644
>> --- a/include/uapi/linux/lsm.h
>> +++ b/include/uapi/linux/lsm.h
>> @@ -90,4 +90,12 @@ struct lsm_ctx {
>> */
>> #define LSM_FLAG_SINGLE 0x0001
>>
>> +/*
>> + * LSM_POLICY_XXX definitions identify the different operations
>> + * to configure LSM policies
>> + */
>> +
>> +#define LSM_POLICY_UNDEF 0
>> +#define LSM_POLICY_LOAD 100
> Why the gap between 0 and 100?
It's conventional in LSM syscalls to start identifiers at 100.
No compelling reason other than to appease the LSM maintainer.
>
>> +
>> #endif /* _UAPI_LINUX_LSM_H */
>> diff --git a/security/lsm_syscalls.c b/security/lsm_syscalls.c
>> index a3cb6dab8102..dd016ba6976c 100644
>> --- a/security/lsm_syscalls.c
>> +++ b/security/lsm_syscalls.c
>> @@ -122,11 +122,24 @@ SYSCALL_DEFINE3(lsm_list_modules, u64 __user *, ids, u32 __user *, size,
>> SYSCALL_DEFINE5(lsm_config_self_policy, u32, lsm_id, u32, op, void __user *,
>> buf, u32 __user *, size, u32, flags)
> Given these are a multiplexor syscalls, I'm wondering if they should not
> have common flags and LSM-specific flags. Alternatively, the op
> argument could also contains some optional flags. In either case, the
> documentation should guide LSM developers for flags that may be shared
> amongst LSMs.
>
> Examples of such flags could be to restrict the whole process instead of
> the calling thread.
>
>> {
>> - return 0;
>> + size_t usize;
>> +
>> + if (get_user(usize, size))
> Size should just be u32, not a pointer.
>
>> + return -EFAULT;
>> +
>> + return security_lsm_config_self_policy(lsm_id, op, buf, usize, flags);
>> }
>>
>> SYSCALL_DEFINE5(lsm_config_system_policy, u32, lsm_id, u32, op, void __user *,
>> buf, u32 __user *, size, u32, flags)
>> {
>> - return 0;
>> + size_t usize;
>> +
>> + if (!capable(CAP_SYS_ADMIN))
>> + return -EPERM;
> I like this mandatory capability check for this specific syscall. This
> makes the semantic clearer. However, to avoid the superpower of
> CAP_SYS_ADMIN, I'm wondering how we could use the CAP_MAC_ADMIN instead.
> This syscall could require CAP_MAC_ADMIN, and current LSMs (relying on a
> filesystem interface for policy configuration) could also enforce
> CAP_SYS_ADMIN for compatibility reasons.
>
> In fact, this "system" syscall could be a "namespace" syscall, which
> would take a security/LSM namespace file descriptor as argument. If the
> namespace is not the initial namespace, any CAP_SYS_ADMIN implemented by
> current LSMs could be avoided. See
> https://lore.kernel.org/r/CAHC9VhRGMmhxbajwQNfGFy+ZFF1uN=UEBjqQZQ4UBy7yds3eVQ@mail.gmail.com
>
>> +
>> + if (get_user(usize, size))
> ditto
>
>> + return -EFAULT;
>> +
>> + return security_lsm_config_system_policy(lsm_id, op, buf, usize, flags);
>> }
>> diff --git a/security/security.c b/security/security.c
>> index fb57e8fddd91..166d7d9936d0 100644
>> --- a/security/security.c
>> +++ b/security/security.c
>> @@ -5883,6 +5883,66 @@ int security_bdev_setintegrity(struct block_device *bdev,
>> }
>> EXPORT_SYMBOL(security_bdev_setintegrity);
>>
>> +/**
>> + * security_lsm_config_self_policy() - Configure caller's LSM policies
>> + * @lsm_id: id of the LSM to target
>> + * @op: Operation to perform (one of the LSM_POLICY_XXX values)
>> + * @buf: userspace pointer to policy data
>> + * @size: size of @buf
>> + * @flags: lsm policy configuration flags
>> + *
>> + * Configure the policies of a LSM for the current domain/user. This notably
>> + * allows to update them even when the lsmfs is unavailable or restricted.
>> + * Currently, only LSM_POLICY_LOAD is supported.
>> + *
>> + * Return: Returns 0 on success, error on failure.
>> + */
>> +int security_lsm_config_self_policy(u32 lsm_id, u32 op, void __user *buf,
>> + size_t size, u32 flags)
>> +{
>> + int rc = LSM_RET_DEFAULT(lsm_config_self_policy);
>> + struct lsm_static_call *scall;
>> +
>> + lsm_for_each_hook(scall, lsm_config_self_policy) {
>> + if ((scall->hl->lsmid->id) == lsm_id) {
>> + rc = scall->hl->hook.lsm_config_self_policy(lsm_id, op, buf, size, flags);
> The lsm_id should not be passed to the hook.
>
> The LSM syscall should manage the argument copy and buffer allocation
> instead of duplicating this code in each LSM hook implementation (see
> other LSM syscalls).
>
>> + break;
>> + }
>> + }
>> +
>> + return rc;
>> +}
>> +
>> +/**
>> + * security_lsm_config_system_policy() - Configure system LSM policies
>> + * @lsm_id: id of the lsm to target
>> + * @op: Operation to perform (one of the LSM_POLICY_XXX values)
>> + * @buf: userspace pointer to policy data
>> + * @size: size of @buf
>> + * @flags: lsm policy configuration flags
>> + *
>> + * Configure the policies of a LSM for the whole system. This notably allows
>> + * to update them even when the lsmfs is unavailable or restricted. Currently,
>> + * only LSM_POLICY_LOAD is supported.
>> + *
>> + * Return: Returns 0 on success, error on failure.
>> + */
>> +int security_lsm_config_system_policy(u32 lsm_id, u32 op, void __user *buf,
>> + size_t size, u32 flags)
>> +{
>> + int rc = LSM_RET_DEFAULT(lsm_config_system_policy);
>> + struct lsm_static_call *scall;
>> +
>> + lsm_for_each_hook(scall, lsm_config_system_policy) {
>> + if ((scall->hl->lsmid->id) == lsm_id) {
>> + rc = scall->hl->hook.lsm_config_system_policy(lsm_id, op, buf, size, flags);
> ditto
>
>> + break;
>> + }
>> + }
>> +
>> + return rc;
>> +}
>> +
>> #ifdef CONFIG_PERF_EVENTS
>> /**
>> * security_perf_event_open() - Check if a perf event open is allowed
>> --
>> 2.48.1
>>
>>
^ permalink raw reply
* Re: LSM namespacing API
From: Casey Schaufler @ 2025-08-20 15:37 UTC (permalink / raw)
To: Mickaël Salaün, Paul Moore
Cc: Stephen Smalley, linux-security-module, selinux, John Johansen,
Maxime Bélair, Casey Schaufler
In-Reply-To: <20250820.ieNg1quoRouz@digikod.net>
On 8/20/2025 7:44 AM, Mickaël Salaün wrote:
> On Tue, Aug 19, 2025 at 02:51:00PM -0400, Paul Moore wrote:
>> On Tue, Aug 19, 2025 at 1:47 PM Stephen Smalley
>> <stephen.smalley.work@gmail.com> wrote:
>>> I think we want to be able to unshare a specific security module
>>> namespace without unsharing the others, i.e. just SELinux or just
>>> AppArmor.
>>> Not sure if your suggestion above supports that already but wanted to note it.
>> The lsm_set_self_attr(2) approach allows for LSM specific unshare
>> operations. Take the existing LSM_ATTR_EXEC attribute as an example,
>> two LSMs have implemented support (AppArmor and SELinux), and
>> userspace can independently set the attribute as desired for each LSM.
>>
>>> Serge pointed out that we also will need an API to attach to an
>>> existing SELinux namespace, which I captured here:
>>> https://github.com/stephensmalley/selinuxns/issues/19
>>> This is handled for other Linux namespaces by opening a pseudo file
>>> under /proc/pid/ns and invoking setns(2), so not sure how we want to
>>> do it.
>> One option would be to have a the LSM framework return a LSM namespace
>> "handle" for a given LSM using lsm_get_self_attr(2) and then do a
>> setns(2)-esque operation using lsm_set_self_attr(2) with that
>> "handle". We would need to figure out what would constitute a
>> "handle" but let's just mark that as TBD for now with this approach (I
>> think better options are available).
>>
>> Since we have an existing LSM namespace combination, with processes
>> running inside of it, it might be sufficient to simply support moving
>> into an existing LSM namespace set with setns(2) using only a pidfd
>> and a new CLONE_LSMNS flag (or similar, upstream might want this as
>> CLONE_NEWLSM). This would simply set the LSM namespace set for the
> Bike shedding but, I would prefer CLONE_NEWSEC or something without LSM
> because the goal is not to add a new LSM but a new "security" namespace.
> To fit with existing capabilities that could be reused by such security
> namespace (CAP_MAC_ADMIN), CLONE_NEWMAC is another option. I know that
> LSM may not be enforce MAC, but I think "LSM" would be confusing for
> users.
I disagree. Using MAC in the name is bad because many LSMs don't do MAC.
Using SEC is even worse, because no two "users" define "security" the
same way, and most of what implements security in Linux is outside of
LSMs. Since this feature would be limited to use by LSMs, it makes sense
that LSM be in the name.
^ permalink raw reply
* Re: [PATCH v5 2/3] lsm: introduce security_lsm_config_*_policy hooks
From: Mickaël Salaün @ 2025-08-20 14:21 UTC (permalink / raw)
To: Maxime Bélair
Cc: linux-security-module, john.johansen, paul, jmorris, serge, kees,
stephen.smalley.work, casey, takedakn, penguin-kernel, song,
rdunlap, linux-api, apparmor, linux-kernel
In-Reply-To: <20250709080220.110947-3-maxime.belair@canonical.com>
On Wed, Jul 09, 2025 at 10:00:55AM +0200, Maxime Bélair wrote:
> Define two new LSM hooks: security_lsm_config_self_policy and
> security_lsm_config_system_policy and wire them into the corresponding
> lsm_config_*_policy() syscalls so that LSMs can register a unified
> interface for policy management. This initial, minimal implementation
> only supports the LSM_POLICY_LOAD operation to limit changes.
>
> Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
> ---
> include/linux/lsm_hook_defs.h | 4 +++
> include/linux/security.h | 20 ++++++++++++
> include/uapi/linux/lsm.h | 8 +++++
> security/lsm_syscalls.c | 17 ++++++++--
> security/security.c | 60 +++++++++++++++++++++++++++++++++++
> 5 files changed, 107 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
> index bf3bbac4e02a..fca490444643 100644
> --- a/include/linux/lsm_hook_defs.h
> +++ b/include/linux/lsm_hook_defs.h
> @@ -464,3 +464,7 @@ LSM_HOOK(int, 0, bdev_alloc_security, struct block_device *bdev)
> LSM_HOOK(void, LSM_RET_VOID, bdev_free_security, struct block_device *bdev)
> LSM_HOOK(int, 0, bdev_setintegrity, struct block_device *bdev,
> enum lsm_integrity_type type, const void *value, size_t size)
> +LSM_HOOK(int, -EINVAL, lsm_config_self_policy, u32 lsm_id, u32 op,
> + void __user *buf, size_t size, u32 flags)
> +LSM_HOOK(int, -EINVAL, lsm_config_system_policy, u32 lsm_id, u32 op,
> + void __user *buf, size_t size, u32 flags)
> diff --git a/include/linux/security.h b/include/linux/security.h
> index cc9b54d95d22..54acaee4a994 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -581,6 +581,11 @@ void security_bdev_free(struct block_device *bdev);
> int security_bdev_setintegrity(struct block_device *bdev,
> enum lsm_integrity_type type, const void *value,
> size_t size);
> +int security_lsm_config_self_policy(u32 lsm_id, u32 op, void __user *buf,
> + size_t size, u32 flags);
> +int security_lsm_config_system_policy(u32 lsm_id, u32 op, void __user *buf,
> + size_t size, u32 flags);
> +
> #else /* CONFIG_SECURITY */
>
> /**
> @@ -1603,6 +1608,21 @@ static inline int security_bdev_setintegrity(struct block_device *bdev,
> return 0;
> }
>
> +static inline int security_lsm_config_self_policy(u32 lsm_id, u32 op,
> + void __user *buf,
> + size_t size, u32 flags)
> +{
> +
> + return -EOPNOTSUPP;
> +}
> +
> +static inline int security_lsm_config_system_policy(u32 lsm_id, u32 op,
> + void __user *buf,
> + size_t size, u32 flags)
> +{
> +
> + return -EOPNOTSUPP;
> +}
> #endif /* CONFIG_SECURITY */
>
> #if defined(CONFIG_SECURITY) && defined(CONFIG_WATCH_QUEUE)
> diff --git a/include/uapi/linux/lsm.h b/include/uapi/linux/lsm.h
> index 938593dfd5da..2b9432a30cdc 100644
> --- a/include/uapi/linux/lsm.h
> +++ b/include/uapi/linux/lsm.h
> @@ -90,4 +90,12 @@ struct lsm_ctx {
> */
> #define LSM_FLAG_SINGLE 0x0001
>
> +/*
> + * LSM_POLICY_XXX definitions identify the different operations
> + * to configure LSM policies
> + */
> +
> +#define LSM_POLICY_UNDEF 0
> +#define LSM_POLICY_LOAD 100
Why the gap between 0 and 100?
> +
> #endif /* _UAPI_LINUX_LSM_H */
> diff --git a/security/lsm_syscalls.c b/security/lsm_syscalls.c
> index a3cb6dab8102..dd016ba6976c 100644
> --- a/security/lsm_syscalls.c
> +++ b/security/lsm_syscalls.c
> @@ -122,11 +122,24 @@ SYSCALL_DEFINE3(lsm_list_modules, u64 __user *, ids, u32 __user *, size,
> SYSCALL_DEFINE5(lsm_config_self_policy, u32, lsm_id, u32, op, void __user *,
> buf, u32 __user *, size, u32, flags)
Given these are a multiplexor syscalls, I'm wondering if they should not
have common flags and LSM-specific flags. Alternatively, the op
argument could also contains some optional flags. In either case, the
documentation should guide LSM developers for flags that may be shared
amongst LSMs.
Examples of such flags could be to restrict the whole process instead of
the calling thread.
> {
> - return 0;
> + size_t usize;
> +
> + if (get_user(usize, size))
Size should just be u32, not a pointer.
> + return -EFAULT;
> +
> + return security_lsm_config_self_policy(lsm_id, op, buf, usize, flags);
> }
>
> SYSCALL_DEFINE5(lsm_config_system_policy, u32, lsm_id, u32, op, void __user *,
> buf, u32 __user *, size, u32, flags)
> {
> - return 0;
> + size_t usize;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
I like this mandatory capability check for this specific syscall. This
makes the semantic clearer. However, to avoid the superpower of
CAP_SYS_ADMIN, I'm wondering how we could use the CAP_MAC_ADMIN instead.
This syscall could require CAP_MAC_ADMIN, and current LSMs (relying on a
filesystem interface for policy configuration) could also enforce
CAP_SYS_ADMIN for compatibility reasons.
In fact, this "system" syscall could be a "namespace" syscall, which
would take a security/LSM namespace file descriptor as argument. If the
namespace is not the initial namespace, any CAP_SYS_ADMIN implemented by
current LSMs could be avoided. See
https://lore.kernel.org/r/CAHC9VhRGMmhxbajwQNfGFy+ZFF1uN=UEBjqQZQ4UBy7yds3eVQ@mail.gmail.com
> +
> + if (get_user(usize, size))
ditto
> + return -EFAULT;
> +
> + return security_lsm_config_system_policy(lsm_id, op, buf, usize, flags);
> }
> diff --git a/security/security.c b/security/security.c
> index fb57e8fddd91..166d7d9936d0 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -5883,6 +5883,66 @@ int security_bdev_setintegrity(struct block_device *bdev,
> }
> EXPORT_SYMBOL(security_bdev_setintegrity);
>
> +/**
> + * security_lsm_config_self_policy() - Configure caller's LSM policies
> + * @lsm_id: id of the LSM to target
> + * @op: Operation to perform (one of the LSM_POLICY_XXX values)
> + * @buf: userspace pointer to policy data
> + * @size: size of @buf
> + * @flags: lsm policy configuration flags
> + *
> + * Configure the policies of a LSM for the current domain/user. This notably
> + * allows to update them even when the lsmfs is unavailable or restricted.
> + * Currently, only LSM_POLICY_LOAD is supported.
> + *
> + * Return: Returns 0 on success, error on failure.
> + */
> +int security_lsm_config_self_policy(u32 lsm_id, u32 op, void __user *buf,
> + size_t size, u32 flags)
> +{
> + int rc = LSM_RET_DEFAULT(lsm_config_self_policy);
> + struct lsm_static_call *scall;
> +
> + lsm_for_each_hook(scall, lsm_config_self_policy) {
> + if ((scall->hl->lsmid->id) == lsm_id) {
> + rc = scall->hl->hook.lsm_config_self_policy(lsm_id, op, buf, size, flags);
The lsm_id should not be passed to the hook.
The LSM syscall should manage the argument copy and buffer allocation
instead of duplicating this code in each LSM hook implementation (see
other LSM syscalls).
> + break;
> + }
> + }
> +
> + return rc;
> +}
> +
> +/**
> + * security_lsm_config_system_policy() - Configure system LSM policies
> + * @lsm_id: id of the lsm to target
> + * @op: Operation to perform (one of the LSM_POLICY_XXX values)
> + * @buf: userspace pointer to policy data
> + * @size: size of @buf
> + * @flags: lsm policy configuration flags
> + *
> + * Configure the policies of a LSM for the whole system. This notably allows
> + * to update them even when the lsmfs is unavailable or restricted. Currently,
> + * only LSM_POLICY_LOAD is supported.
> + *
> + * Return: Returns 0 on success, error on failure.
> + */
> +int security_lsm_config_system_policy(u32 lsm_id, u32 op, void __user *buf,
> + size_t size, u32 flags)
> +{
> + int rc = LSM_RET_DEFAULT(lsm_config_system_policy);
> + struct lsm_static_call *scall;
> +
> + lsm_for_each_hook(scall, lsm_config_system_policy) {
> + if ((scall->hl->lsmid->id) == lsm_id) {
> + rc = scall->hl->hook.lsm_config_system_policy(lsm_id, op, buf, size, flags);
ditto
> + break;
> + }
> + }
> +
> + return rc;
> +}
> +
> #ifdef CONFIG_PERF_EVENTS
> /**
> * security_perf_event_open() - Check if a perf event open is allowed
> --
> 2.48.1
>
>
^ permalink raw reply
* Re: LSM namespacing API
From: Mickaël Salaün @ 2025-08-20 14:44 UTC (permalink / raw)
To: Paul Moore
Cc: Stephen Smalley, linux-security-module, selinux, John Johansen,
Maxime Bélair
In-Reply-To: <CAHC9VhSubXA4tAUoz7T==UvfrM_DXS6nF5s0tJZ1HrrVizMgZA@mail.gmail.com>
On Tue, Aug 19, 2025 at 02:51:00PM -0400, Paul Moore wrote:
> On Tue, Aug 19, 2025 at 1:47 PM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> >
> > I think we want to be able to unshare a specific security module
> > namespace without unsharing the others, i.e. just SELinux or just
> > AppArmor.
> > Not sure if your suggestion above supports that already but wanted to note it.
>
> The lsm_set_self_attr(2) approach allows for LSM specific unshare
> operations. Take the existing LSM_ATTR_EXEC attribute as an example,
> two LSMs have implemented support (AppArmor and SELinux), and
> userspace can independently set the attribute as desired for each LSM.
>
> > Serge pointed out that we also will need an API to attach to an
> > existing SELinux namespace, which I captured here:
> > https://github.com/stephensmalley/selinuxns/issues/19
> > This is handled for other Linux namespaces by opening a pseudo file
> > under /proc/pid/ns and invoking setns(2), so not sure how we want to
> > do it.
>
> One option would be to have a the LSM framework return a LSM namespace
> "handle" for a given LSM using lsm_get_self_attr(2) and then do a
> setns(2)-esque operation using lsm_set_self_attr(2) with that
> "handle". We would need to figure out what would constitute a
> "handle" but let's just mark that as TBD for now with this approach (I
> think better options are available).
>
> Since we have an existing LSM namespace combination, with processes
> running inside of it, it might be sufficient to simply support moving
> into an existing LSM namespace set with setns(2) using only a pidfd
> and a new CLONE_LSMNS flag (or similar, upstream might want this as
> CLONE_NEWLSM). This would simply set the LSM namespace set for the
Bike shedding but, I would prefer CLONE_NEWSEC or something without LSM
because the goal is not to add a new LSM but a new "security" namespace.
To fit with existing capabilities that could be reused by such security
namespace (CAP_MAC_ADMIN), CLONE_NEWMAC is another option. I know that
LSM may not be enforce MAC, but I think "LSM" would be confusing for
users.
> setns(2) caller to match that of the target pidfd. We still wouldn't
> want to support CLONE_LSMNS/CLONE_NEWLSM for clone*().
Why making clone*() support this flag would be an issue?
>
> Any other ideas?
The goal of a namespace is to configure absolute references (e.g. file
path, network address, PID, time). I think it would make sense to have
an LSM/MAC/SEC namespace that would enforce a consistent access control
on every processes in this namespace. A related namespace file
descriptor could then be used with an LSM-specific syscall to configure
the policy related to a specific namespace (instead of only the current
namespace), see
https://lore.kernel.org/r/20250820.Ao3iquoshaiB@digikod.net
That would enables us to build a context before running untrusted code
in it, and to update the related security policy without requiring a
trusted (and exposed) process in each namespace.
I guess a security namespace would not be exclusive to an LSM but could
be shared, right? If yes, then it's OK to only have one new security
namespace instead of one per LSM. ;)
^ permalink raw reply
* Re: [PATCH v5 3/3] AppArmor: add support for lsm_config_self_policy and lsm_config_system_policy
From: Mickaël Salaün @ 2025-08-20 14:21 UTC (permalink / raw)
To: Maxime Bélair
Cc: linux-security-module, john.johansen, paul, jmorris, serge, kees,
stephen.smalley.work, casey, takedakn, penguin-kernel, song,
rdunlap, linux-api, apparmor, linux-kernel
In-Reply-To: <20250709080220.110947-4-maxime.belair@canonical.com>
On Wed, Jul 09, 2025 at 10:00:56AM +0200, Maxime Bélair wrote:
> Enable users to manage AppArmor policies through the new hooks
> lsm_config_self_policy and lsm_config_system_policy.
>
> lsm_config_self_policy allows stacking existing policies in the kernel.
> This ensures that it can only further restrict the caller and can never
> be used to gain new privileges.
>
> lsm_config_system_policy allows loading or replacing AppArmor policies in
> any AppArmor namespace.
>
> Signed-off-by: Maxime Bélair <maxime.belair@canonical.com>
> ---
> security/apparmor/apparmorfs.c | 31 ++++++++++
> security/apparmor/include/apparmor.h | 4 ++
> security/apparmor/include/apparmorfs.h | 3 +
> security/apparmor/lsm.c | 84 ++++++++++++++++++++++++++
> 4 files changed, 122 insertions(+)
>
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index 9b6c2f157f83..0ce40290f44e 100644
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@ -1275,6 +1275,86 @@ static int apparmor_socket_shutdown(struct socket *sock, int how)
> return aa_sock_perm(OP_SHUTDOWN, AA_MAY_SHUTDOWN, sock);
> }
>
> +/**
> + * apparmor_lsm_config_self_policy - Stack a profile
> + * @lsm_id: AppArmor ID (LSM_ID_APPARMOR). Unused here
> + * @op: operation to perform. Currently, only LSM_POLICY_LOAD is supported
> + * @buf: buffer containing the user-provided name of the profile to stack
> + * @size: size of @buf
> + * @flags: reserved for future use; must be zero
> + *
> + * Returns: 0 on success, negative value on error
> + */
> +static int apparmor_lsm_config_self_policy(u32 lsm_id, u32 op, void __user *buf,
> + size_t size, u32 flags)
> +{
> + char *name;
> + long name_size;
> + int ret;
> +
> + if (op != LSM_POLICY_LOAD || flags)
> + return -EOPNOTSUPP;
> + if (size == 0)
> + return -EINVAL;
> + if (size > AA_PROFILE_NAME_MAX_SIZE)
> + return -E2BIG;
> +
> + name = kmalloc(size, GFP_KERNEL);
> + if (!name)
> + return -ENOMEM;
This hunk should be part of the syscall code and shared amongst LSMs.
> +
> +
> + name_size = strncpy_from_user(name, buf, size);
> + if (name_size < 0) {
> + kfree(name);
> + return name_size;
> + }
> +
> + ret = aa_change_profile(name, AA_CHANGE_STACK);
> +
> + kfree(name);
> +
> + return ret;
> +}
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: add the associated Rust helper to the CREDENTIALS section
From: Alice Ryhl @ 2025-08-20 8:28 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-security-module, rust-for-linux
In-Reply-To: <20250819195841.238246-2-paul@paul-moore.com>
On Tue, Aug 19, 2025 at 03:58:42PM -0400, Paul Moore wrote:
> Signed-off-by: Paul Moore <paul@paul-moore.com>
> ---
Acked-by: Alice Ryhl <aliceryhl@google.com>
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d61f7246e5bf..0ee0098f2df8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6484,6 +6484,7 @@ S: Supported
> T: git https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git
> F: include/linux/cred.h
> F: kernel/cred.c
> +F: rust/kernel/cred.rs
> F: Documentation/security/credentials.rst
>
> INTEL CRPS COMMON REDUNDANT PSU DRIVER
> --
> 2.50.1
>
^ permalink raw reply
* Re: [PATCH] rust: cred: update AlwaysRefCounted import to sync::aref
From: Miguel Ojeda @ 2025-08-19 20:08 UTC (permalink / raw)
To: Paul Moore
Cc: Alice Ryhl, Serge E. Hallyn, Shankari Anand, Miguel Ojeda,
Alex Gaynor, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
rust-for-linux, linux-kernel, linux-security-module
In-Reply-To: <CAHC9VhSoyh3EqFqYD7tXDmPXsao8FLQo2PMAKEmJVJ6khPA51Q@mail.gmail.com>
On Tue, Aug 19, 2025 at 10:06 PM Paul Moore <paul@paul-moore.com> wrote:
>
> Okay, patch sent.
>
> https://lore.kernel.org/linux-security-module/20250819195841.238246-2-paul@paul-moore.com
>
> In that case, I've gone ahead and merged Shankari's patch into lsm/dev
> and will plan to send it up to Linus during the next merge window. If
> something changes and the Rust folks want to send this up via a Rust
> tree just let me know and I'll drop the patch.
Sounds good, thanks a lot -- I replied on the patch.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH] rust: cred: update AlwaysRefCounted import to sync::aref
From: Paul Moore @ 2025-08-19 20:06 UTC (permalink / raw)
To: Alice Ryhl
Cc: Serge E. Hallyn, Shankari Anand, Miguel Ojeda, Alex Gaynor,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, Danilo Krummrich, rust-for-linux,
linux-kernel, linux-security-module
In-Reply-To: <CAH5fLgin9OhTmf52i2hQKztYLcHTxE+n1gMPXDFN83atE+u_oA@mail.gmail.com>
On Mon, Aug 18, 2025 at 6:06 PM Alice Ryhl <aliceryhl@google.com> wrote:
> On Mon, Aug 18, 2025 at 11:22 PM Paul Moore <paul@paul-moore.com> wrote:
> >
> > On Sun, Aug 17, 2025 at 11:26 PM Serge E. Hallyn <serge@hallyn.com> wrote:
> > > On Sat, Aug 16, 2025 at 05:14:09PM +0530, Shankari Anand wrote:
> > > > Update the import of `AlwaysRefCounted` in `cred.rs` to use `sync::aref`
> > > > instead of `types`.
> > >
> > > Thank you for forwarding, Miguel.
> > >
> > > As far as I can see from the included links, this looks good.
> > >
> > > > This is part of the ongoing effort to move `ARef` and
> > > > `AlwaysRefCounted` to the `sync` module for better modularity.
> > > >
> > > > Suggested-by: Benno Lossin <lossin@kernel.org>
> > > > Link: https://github.com/Rust-for-Linux/linux/issues/1173
> > > > Signed-off-by: Shankari Anand <shankari.ak0208@gmail.com>
>
> Reviewed-by: Alice Ryhl <aliceryhl@google.com>
>
> > > Acked-by: Serge Hallyn <serge@hallyn.com>
> >
> > As mentioned previously, I'm still not well versed in Rust so as long
> > as Serge is happy with it, I'm good with it too :)
> >
> > I'm guessing it probably makes sense to include rust/kernel/cred.rs in
> > the creds MAINTAINERS section just as we did (or will do) with the LSM
> > Rust shim?
>
> That would make sense to me.
Okay, patch sent.
https://lore.kernel.org/linux-security-module/20250819195841.238246-2-paul@paul-moore.com
> My understanding is that this patch, unlike the pin-init one, is
> intended to go through the LSM / CRED tree rather than taking
> everything through a shared tree with Acked-bys.
In that case, I've gone ahead and merged Shankari's patch into lsm/dev
and will plan to send it up to Linus during the next merge window. If
something changes and the Rust folks want to send this up via a Rust
tree just let me know and I'll drop the patch.
--
paul-moore.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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).