* Re: LSM stacking in next for 6.1?
@ 2022-09-06 23:24 ` Paul Moore
0 siblings, 0 replies; 148+ messages in thread
From: Paul Moore @ 2022-09-06 23:24 UTC (permalink / raw)
To: Casey Schaufler
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 9/2/2022 2:30 PM, Paul Moore wrote:
> > On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
> >> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >>> I would like very much to get v38 or v39 of the LSM stacking for Apparmor
> >>> patch set in the LSM next branch for 6.1. The audit changes have polished
> >>> up nicely and I believe that all comments on the integrity code have been
> >>> addressed. The interface_lsm mechanism has been beaten to a frothy peak.
> >>> There are serious binder changes, but I think they address issues beyond
> >>> the needs of stacking. Changes outside these areas are pretty well limited
> >>> to LSM interface improvements.
> >>
> >> The LSM stacking patches are near the very top of my list to review
> >> once the merge window clears, the io_uring fixes are in (bug fix), and
> >> SCTP is somewhat sane again (bug fix). I'm hopeful that the io_uring
> >> and SCTP stuff can be finished up in the next week or two.
> >>
> >> Since I'm the designated first stuckee now for the stacking stuff I
> >> want to go back through everything with fresh eyes, which probably
> >> isn't a bad idea since it has been a while since I looked at the full
> >> patchset from bottom to top. I can tell you that I've never been
> >> really excited about the /proc changes, and believe it or not I've
> >> been thinking about those a fair amount since James asked me to start
> >> maintaining the LSM. I don't want to get into any detail until I've
> >> had a chance to look over everything again, but just a heads-up that
> >> I'm not too excited about those bits.
> >
> > As I mentioned above, I don't really like the stuff that one has to do
> > to support LSM stacking on the existing /proc interfaces, the
> > "label1\0label2\labelN\0" hack is probably the best (only?) option we
> > have for retrofitting multiple LSMs into those interfaces and I think
> > we can all agree it's not a great API. Considering that applications
> > that wish to become simultaneous multi-LSM aware are going to need
> > modification anyway, let's take a step back and see if we can do this
> > with a more sensible API.
>
> This is a compound problem. Some applications, including systemd and dbus,
> will require modification to completely support multiple concurrent LSMs
> in the long term. This will certainly be the case should someone be wild
> and crazy enough to use Smack and SELinux together. Even with the (Smack or
> SELinux) and AppArmor case the ps(1) command should be educated about the
> possibility of multiple "current" values. However, in a container world,
> where an Android container can run on an Ubuntu system, the presence of
> AppArmor on the base system is completely uninteresting to the SELinux
> aware applications in the container. This is a real use case.
If you are running AppArmor on the host system and SELinux in a
container you are likely going to have some *very* bizarre behavior as
the SELinux policy you load in the container will apply to the entire
system, including processes which started *before* the SELinux policy
was loaded. While I understand the point you are trying to make, I
don't believe the example you chose is going to work without a lot of
other changes.
Regardless of the above example, I want to be clear that I'm not
suggesting changes to the /proc interfaces. Existing LSM aware
applications that use procfs for information would continue to work as
expected, it would just be the simul-multi-LSM aware applications that
would need to transition to the new syscall API to get all of the LSM
labels.
> > I think it's time to think about a proper set of LSM syscalls.
>
> At the very least we need a liblsm that preforms a number of useful
> functions, like identifying what security modules are available,
> validating "contexts", fetching "contexts" from files and processes
> and that sort of thing. Whether it is built on syscalls or /proc and
> getxattr() is a matter of debate and taste.
Why is it a forgone conclusion that a library would be necessary for
basic operations? If the kernel/userspace API is sane to begin with
we could probably either significantly reduce or eliminate the need
for additional libraries. I really want us to attempt to come up with
a decent kernel/userspace API to begin with as opposed to using the
excuse of a userspace library to hide API sins that never should have
been committed.
The LSM stacking work presents us with a unique opportunity to
modify/update/whatever the LSM kernel/userspace API, I don't want to
see us squander this chance on a hack.
> > While I realize syscalls are not the only kernel/userspace API option,
> > but given the popularity of namespaces I believe a syscall based
> > kernel/userspace LSM API has a number of advantages over the other
> > options, e.g. procfs/sysfs, netlink, etc.
>
> You can't script syscalls.
True. However I don't see that as a blocker, trivial helper
applications can be written for those who wish to incorporate the new
syscall-based API into their scripts. We would not be the first (or
the last) in this regard.
> A syscall interface is fine if you can also
> update the entire system service application base for your distribution.
> I don't see that as an option.
Once again, I'm not talking about removing the existing procfs
interface; existing applications would continue to work. Only
applications which wanted to be simul-multi-LSM aware would need to be
modified, and those applications would need to be modified regardless
of if the procfs or syscall-based API was used.
> > Further, I think we can add the new syscall API separately from the
> > LSM stacking changes as they do have standalone value.
>
> I agree, but unless the new system calls take stacking into account
> from their inception they're just going to be another interface that
> makes stacking harder to accomplish.
They obviously would Casey, not only is that the context of the
discussion but my dummy example clearly had support for multiple LSMs.
> > This would
> > help reduce the size and complexity of the stacking patchset, which I
> > believe would be a very good thing.
>
> The /proc interfaces interface_lsm and context are really pretty simple.
They are now, they are also a bit of a mess with legacy constraints
and they only get more complicated and messy with the LSM stacking
patches. It is my opinion that a syscall-based API is cleaner and
easier for applications to use.
> The addition of multiple subject labels to audit would be the same regardless
> of /proc or syscall interfaces.
Yes, that's why I didn't bring up audit as it doesn't weigh on this
decision. If you really want to include audit for some reason, I'll
simply remind you that I pushed back hard on overloading the existing
subj/obj fields with a multiplexed label format, asking for individual
subj/obj fields for each LSM.
> We'd still need multiple LSM data in most
> security blobs. The conversion of LSM hook interfaces from secids to lsmblobs
> would still be required. As would the conversion from string+len pairs to
> lsmcontext structures.
I'm not talking about kernel internal data structures Casey, I'm
talking about the kernel/userspace API.
> > Introducing the syscall API
> > sooner would also allow any applications wanting to make use of the
> > crazy new stacked-LSM world a head start as they could be modified
> > while the kernel patches were making their way through the
> > review/update/merge/release process.
>
> A liblsm based on the /proc interfaces would address that as well.
Perhaps a liblsm library would be useful for other reasons beyond this
discussion, but I don't want to use a userspace library as an excuse
to support an awful kernel/userspace API.
> > Thoughts?
>
> I wish you'd suggested this three years ago, when I could have done
> something with it. If stacking has to go on a two year redesign because
> of this it is dead.
I've never liked the combined label interfaces, see the mention of
audit in this email above. I'm sure if you wanted to dig through all
of the mail archives I'm sure I've probably mentioned my dislike of
the combined label interface in procfs too; if not on the mailing list
then surely in-person at some point. However, regardless of all that,
the key difference is that prior to a few months ago I didn't have to
worry about it quite as much as I do now. Now I'm responsible for
standing up for the code that goes into the LSM tree and that means
both defending it as "good" and maintaining it long term; prior to a
few months ago that was, politely, "not my problem" :)
I can't currently in good conscience defend the kernel/userspace
combined label interfaces as "good", especially when we have a very
rare opportunity to do better.
--
paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-06 23:24 ` Paul Moore
@ 2022-09-07 0:10 ` John Johansen
-1 siblings, 0 replies; 148+ messages in thread
From: John Johansen @ 2022-09-07 0:10 UTC (permalink / raw)
To: Paul Moore, Casey Schaufler
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook, SElinux list
sorry I am wayyyy behind on this, so starting from here
On 9/6/22 16:24, Paul Moore wrote:
> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>> I would like very much to get v38 or v39 of the LSM stacking for Apparmor
>>>>> patch set in the LSM next branch for 6.1. The audit changes have polished
>>>>> up nicely and I believe that all comments on the integrity code have been
>>>>> addressed. The interface_lsm mechanism has been beaten to a frothy peak.
>>>>> There are serious binder changes, but I think they address issues beyond
>>>>> the needs of stacking. Changes outside these areas are pretty well limited
>>>>> to LSM interface improvements.
>>>>
>>>> The LSM stacking patches are near the very top of my list to review
>>>> once the merge window clears, the io_uring fixes are in (bug fix), and
>>>> SCTP is somewhat sane again (bug fix). I'm hopeful that the io_uring
>>>> and SCTP stuff can be finished up in the next week or two.
>>>>
>>>> Since I'm the designated first stuckee now for the stacking stuff I
>>>> want to go back through everything with fresh eyes, which probably
>>>> isn't a bad idea since it has been a while since I looked at the full
>>>> patchset from bottom to top. I can tell you that I've never been
>>>> really excited about the /proc changes, and believe it or not I've
>>>> been thinking about those a fair amount since James asked me to start
>>>> maintaining the LSM. I don't want to get into any detail until I've
>>>> had a chance to look over everything again, but just a heads-up that
>>>> I'm not too excited about those bits.
>>>
>>> As I mentioned above, I don't really like the stuff that one has to do
>>> to support LSM stacking on the existing /proc interfaces, the
>>> "label1\0label2\labelN\0" hack is probably the best (only?) option we
>>> have for retrofitting multiple LSMs into those interfaces and I think
>>> we can all agree it's not a great API. Considering that applications
>>> that wish to become simultaneous multi-LSM aware are going to need
>>> modification anyway, let's take a step back and see if we can do this
>>> with a more sensible API.
>>
>> This is a compound problem. Some applications, including systemd and dbus,
>> will require modification to completely support multiple concurrent LSMs
>> in the long term. This will certainly be the case should someone be wild
>> and crazy enough to use Smack and SELinux together. Even with the (Smack or
>> SELinux) and AppArmor case the ps(1) command should be educated about the
>> possibility of multiple "current" values. However, in a container world,
>> where an Android container can run on an Ubuntu system, the presence of
>> AppArmor on the base system is completely uninteresting to the SELinux
>> aware applications in the container. This is a real use case.
>
> If you are running AppArmor on the host system and SELinux in a
> container you are likely going to have some *very* bizarre behavior as
> the SELinux policy you load in the container will apply to the entire
> system, including processes which started *before* the SELinux policy
> was loaded. While I understand the point you are trying to make, I
> don't believe the example you chose is going to work without a lot of
> other changes.
>
correct but the reverse does work. Where SELinux is running on the host
and AppArmor in the container. Obviously that is the simplified version
AppArmor is running on the host too but unconfined, has setup a policy
namespace for the container and is self stacking (bounding).
> Regardless of the above example, I want to be clear that I'm not
> suggesting changes to the /proc interfaces. Existing LSM aware
> applications that use procfs for information would continue to work as
> expected, it would just be the simul-multi-LSM aware applications that
> would need to transition to the new syscall API to get all of the LSM
> labels.
>
I can live with that. AppArmor and Smack have already landed private
interfaces and prefer them over the shared interface if they are
available.
>>> I think it's time to think about a proper set of LSM syscalls.
>>
>> At the very least we need a liblsm that preforms a number of useful
>> functions, like identifying what security modules are available,
>> validating "contexts", fetching "contexts" from files and processes
>> and that sort of thing. Whether it is built on syscalls or /proc and
>> getxattr() is a matter of debate and taste.
>
> Why is it a forgone conclusion that a library would be necessary for
> basic operations? If the kernel/userspace API is sane to begin with
> we could probably either significantly reduce or eliminate the need
> for additional libraries. I really want us to attempt to come up with
> a decent kernel/userspace API to begin with as opposed to using the
> excuse of a userspace library to hide API sins that never should have
> been committed.
>
I don't think its a foregone conclusion, its just that it has been
discussed several times, and all the interfaces have been nasty and
prebaked userspace code would be really nice to have.
There are other reasons to use a lib as well. Libs can help apps
pickup fixes/changes automatically.
> The LSM stacking work presents us with a unique opportunity to
> modify/update/whatever the LSM kernel/userspace API, I don't want to
> see us squander this chance on a hack.
>
I do wish we had a better API from the beginning. I just hope it isn't
going to take another 10 years to get the API portion done.
>>> While I realize syscalls are not the only kernel/userspace API option,
>>> but given the popularity of namespaces I believe a syscall based
>>> kernel/userspace LSM API has a number of advantages over the other
>>> options, e.g. procfs/sysfs, netlink, etc.
>>
>> You can't script syscalls.
>
> True. However I don't see that as a blocker, trivial helper
> applications can be written for those who wish to incorporate the new
> syscall-based API into their scripts. We would not be the first (or
> the last) in this regard.
>
>> A syscall interface is fine if you can also
>> update the entire system service application base for your distribution.
>> I don't see that as an option.
>
> Once again, I'm not talking about removing the existing procfs
> interface; existing applications would continue to work. Only
> applications which wanted to be simul-multi-LSM aware would need to be
> modified, and those applications would need to be modified regardless
> of if the procfs or syscall-based API was used.
>
>>> Further, I think we can add the new syscall API separately from the
>>> LSM stacking changes as they do have standalone value.
>>
>> I agree, but unless the new system calls take stacking into account
>> from their inception they're just going to be another interface that
>> makes stacking harder to accomplish.
>
> They obviously would Casey, not only is that the context of the
> discussion but my dummy example clearly had support for multiple LSMs.
>
>>> This would
>>> help reduce the size and complexity of the stacking patchset, which I
>>> believe would be a very good thing.
>>
>> The /proc interfaces interface_lsm and context are really pretty simple.
>
> They are now, they are also a bit of a mess with legacy constraints
> and they only get more complicated and messy with the LSM stacking
> patches. It is my opinion that a syscall-based API is cleaner and
> easier for applications to use.
>
potentially if we can get one
>> The addition of multiple subject labels to audit would be the same regardless
>> of /proc or syscall interfaces.
>
> Yes, that's why I didn't bring up audit as it doesn't weigh on this
> decision. If you really want to include audit for some reason, I'll
> simply remind you that I pushed back hard on overloading the existing
> subj/obj fields with a multiplexed label format, asking for individual
> subj/obj fields for each LSM.
>
how can I forget, what a pita :)
>> We'd still need multiple LSM data in most
>> security blobs. The conversion of LSM hook interfaces from secids to lsmblobs
>> would still be required. As would the conversion from string+len pairs to
>> lsmcontext structures.
>
> I'm not talking about kernel internal data structures Casey, I'm
> talking about the kernel/userspace API.
>
>>> Introducing the syscall API
>>> sooner would also allow any applications wanting to make use of the
>>> crazy new stacked-LSM world a head start as they could be modified
>>> while the kernel patches were making their way through the
>>> review/update/merge/release process.
>>
>> A liblsm based on the /proc interfaces would address that as well.
>
> Perhaps a liblsm library would be useful for other reasons beyond this
> discussion, but I don't want to use a userspace library as an excuse
> to support an awful kernel/userspace API.
>
>>> Thoughts?
>>
>> I wish you'd suggested this three years ago, when I could have done
>> something with it. If stacking has to go on a two year redesign because
>> of this it is dead.
>
> I've never liked the combined label interfaces, see the mention of
> audit in this email above. I'm sure if you wanted to dig through all
> of the mail archives I'm sure I've probably mentioned my dislike of
> the combined label interface in procfs too; if not on the mailing list
> then surely in-person at some point. However, regardless of all that,
> the key difference is that prior to a few months ago I didn't have to
> worry about it quite as much as I do now. Now I'm responsible for
> standing up for the code that goes into the LSM tree and that means
> both defending it as "good" and maintaining it long term; prior to a
> few months ago that was, politely, "not my problem" :)
>
> I can't currently in good conscience defend the kernel/userspace
> combined label interfaces as "good", especially when we have a very
> rare opportunity to do better.
>
so I am going to grab and hold onto
>>> Further, I think we can add the new syscall API separately from the
>>> LSM stacking changes as they do have standalone value.
>>
what I think Paul is saying is we can move the LSM stacking patches
forward by removing the combined label interface. They won't be as
useful but it would be a huge step forward, and the next step could
be the syscall API.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-09-07 0:10 ` John Johansen
0 siblings, 0 replies; 148+ messages in thread
From: John Johansen @ 2022-09-07 0:10 UTC (permalink / raw)
To: Paul Moore, Casey Schaufler
Cc: SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
sorry I am wayyyy behind on this, so starting from here
On 9/6/22 16:24, Paul Moore wrote:
> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>> I would like very much to get v38 or v39 of the LSM stacking for Apparmor
>>>>> patch set in the LSM next branch for 6.1. The audit changes have polished
>>>>> up nicely and I believe that all comments on the integrity code have been
>>>>> addressed. The interface_lsm mechanism has been beaten to a frothy peak.
>>>>> There are serious binder changes, but I think they address issues beyond
>>>>> the needs of stacking. Changes outside these areas are pretty well limited
>>>>> to LSM interface improvements.
>>>>
>>>> The LSM stacking patches are near the very top of my list to review
>>>> once the merge window clears, the io_uring fixes are in (bug fix), and
>>>> SCTP is somewhat sane again (bug fix). I'm hopeful that the io_uring
>>>> and SCTP stuff can be finished up in the next week or two.
>>>>
>>>> Since I'm the designated first stuckee now for the stacking stuff I
>>>> want to go back through everything with fresh eyes, which probably
>>>> isn't a bad idea since it has been a while since I looked at the full
>>>> patchset from bottom to top. I can tell you that I've never been
>>>> really excited about the /proc changes, and believe it or not I've
>>>> been thinking about those a fair amount since James asked me to start
>>>> maintaining the LSM. I don't want to get into any detail until I've
>>>> had a chance to look over everything again, but just a heads-up that
>>>> I'm not too excited about those bits.
>>>
>>> As I mentioned above, I don't really like the stuff that one has to do
>>> to support LSM stacking on the existing /proc interfaces, the
>>> "label1\0label2\labelN\0" hack is probably the best (only?) option we
>>> have for retrofitting multiple LSMs into those interfaces and I think
>>> we can all agree it's not a great API. Considering that applications
>>> that wish to become simultaneous multi-LSM aware are going to need
>>> modification anyway, let's take a step back and see if we can do this
>>> with a more sensible API.
>>
>> This is a compound problem. Some applications, including systemd and dbus,
>> will require modification to completely support multiple concurrent LSMs
>> in the long term. This will certainly be the case should someone be wild
>> and crazy enough to use Smack and SELinux together. Even with the (Smack or
>> SELinux) and AppArmor case the ps(1) command should be educated about the
>> possibility of multiple "current" values. However, in a container world,
>> where an Android container can run on an Ubuntu system, the presence of
>> AppArmor on the base system is completely uninteresting to the SELinux
>> aware applications in the container. This is a real use case.
>
> If you are running AppArmor on the host system and SELinux in a
> container you are likely going to have some *very* bizarre behavior as
> the SELinux policy you load in the container will apply to the entire
> system, including processes which started *before* the SELinux policy
> was loaded. While I understand the point you are trying to make, I
> don't believe the example you chose is going to work without a lot of
> other changes.
>
correct but the reverse does work. Where SELinux is running on the host
and AppArmor in the container. Obviously that is the simplified version
AppArmor is running on the host too but unconfined, has setup a policy
namespace for the container and is self stacking (bounding).
> Regardless of the above example, I want to be clear that I'm not
> suggesting changes to the /proc interfaces. Existing LSM aware
> applications that use procfs for information would continue to work as
> expected, it would just be the simul-multi-LSM aware applications that
> would need to transition to the new syscall API to get all of the LSM
> labels.
>
I can live with that. AppArmor and Smack have already landed private
interfaces and prefer them over the shared interface if they are
available.
>>> I think it's time to think about a proper set of LSM syscalls.
>>
>> At the very least we need a liblsm that preforms a number of useful
>> functions, like identifying what security modules are available,
>> validating "contexts", fetching "contexts" from files and processes
>> and that sort of thing. Whether it is built on syscalls or /proc and
>> getxattr() is a matter of debate and taste.
>
> Why is it a forgone conclusion that a library would be necessary for
> basic operations? If the kernel/userspace API is sane to begin with
> we could probably either significantly reduce or eliminate the need
> for additional libraries. I really want us to attempt to come up with
> a decent kernel/userspace API to begin with as opposed to using the
> excuse of a userspace library to hide API sins that never should have
> been committed.
>
I don't think its a foregone conclusion, its just that it has been
discussed several times, and all the interfaces have been nasty and
prebaked userspace code would be really nice to have.
There are other reasons to use a lib as well. Libs can help apps
pickup fixes/changes automatically.
> The LSM stacking work presents us with a unique opportunity to
> modify/update/whatever the LSM kernel/userspace API, I don't want to
> see us squander this chance on a hack.
>
I do wish we had a better API from the beginning. I just hope it isn't
going to take another 10 years to get the API portion done.
>>> While I realize syscalls are not the only kernel/userspace API option,
>>> but given the popularity of namespaces I believe a syscall based
>>> kernel/userspace LSM API has a number of advantages over the other
>>> options, e.g. procfs/sysfs, netlink, etc.
>>
>> You can't script syscalls.
>
> True. However I don't see that as a blocker, trivial helper
> applications can be written for those who wish to incorporate the new
> syscall-based API into their scripts. We would not be the first (or
> the last) in this regard.
>
>> A syscall interface is fine if you can also
>> update the entire system service application base for your distribution.
>> I don't see that as an option.
>
> Once again, I'm not talking about removing the existing procfs
> interface; existing applications would continue to work. Only
> applications which wanted to be simul-multi-LSM aware would need to be
> modified, and those applications would need to be modified regardless
> of if the procfs or syscall-based API was used.
>
>>> Further, I think we can add the new syscall API separately from the
>>> LSM stacking changes as they do have standalone value.
>>
>> I agree, but unless the new system calls take stacking into account
>> from their inception they're just going to be another interface that
>> makes stacking harder to accomplish.
>
> They obviously would Casey, not only is that the context of the
> discussion but my dummy example clearly had support for multiple LSMs.
>
>>> This would
>>> help reduce the size and complexity of the stacking patchset, which I
>>> believe would be a very good thing.
>>
>> The /proc interfaces interface_lsm and context are really pretty simple.
>
> They are now, they are also a bit of a mess with legacy constraints
> and they only get more complicated and messy with the LSM stacking
> patches. It is my opinion that a syscall-based API is cleaner and
> easier for applications to use.
>
potentially if we can get one
>> The addition of multiple subject labels to audit would be the same regardless
>> of /proc or syscall interfaces.
>
> Yes, that's why I didn't bring up audit as it doesn't weigh on this
> decision. If you really want to include audit for some reason, I'll
> simply remind you that I pushed back hard on overloading the existing
> subj/obj fields with a multiplexed label format, asking for individual
> subj/obj fields for each LSM.
>
how can I forget, what a pita :)
>> We'd still need multiple LSM data in most
>> security blobs. The conversion of LSM hook interfaces from secids to lsmblobs
>> would still be required. As would the conversion from string+len pairs to
>> lsmcontext structures.
>
> I'm not talking about kernel internal data structures Casey, I'm
> talking about the kernel/userspace API.
>
>>> Introducing the syscall API
>>> sooner would also allow any applications wanting to make use of the
>>> crazy new stacked-LSM world a head start as they could be modified
>>> while the kernel patches were making their way through the
>>> review/update/merge/release process.
>>
>> A liblsm based on the /proc interfaces would address that as well.
>
> Perhaps a liblsm library would be useful for other reasons beyond this
> discussion, but I don't want to use a userspace library as an excuse
> to support an awful kernel/userspace API.
>
>>> Thoughts?
>>
>> I wish you'd suggested this three years ago, when I could have done
>> something with it. If stacking has to go on a two year redesign because
>> of this it is dead.
>
> I've never liked the combined label interfaces, see the mention of
> audit in this email above. I'm sure if you wanted to dig through all
> of the mail archives I'm sure I've probably mentioned my dislike of
> the combined label interface in procfs too; if not on the mailing list
> then surely in-person at some point. However, regardless of all that,
> the key difference is that prior to a few months ago I didn't have to
> worry about it quite as much as I do now. Now I'm responsible for
> standing up for the code that goes into the LSM tree and that means
> both defending it as "good" and maintaining it long term; prior to a
> few months ago that was, politely, "not my problem" :)
>
> I can't currently in good conscience defend the kernel/userspace
> combined label interfaces as "good", especially when we have a very
> rare opportunity to do better.
>
so I am going to grab and hold onto
>>> Further, I think we can add the new syscall API separately from the
>>> LSM stacking changes as they do have standalone value.
>>
what I think Paul is saying is we can move the LSM stacking patches
forward by removing the combined label interface. They won't be as
useful but it would be a huge step forward, and the next step could
be the syscall API.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-07 0:10 ` John Johansen
@ 2022-09-07 0:39 ` Casey Schaufler
-1 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-07 0:39 UTC (permalink / raw)
To: John Johansen, Paul Moore
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook,
SElinux list, casey
On 9/6/2022 5:10 PM, John Johansen wrote:
> sorry I am wayyyy behind on this, so starting from here
>
> On 9/6/22 16:24, Paul Moore wrote:
>> I can't currently in good conscience defend the kernel/userspace
>> combined label interfaces as "good", especially when we have a very
>> rare opportunity to do better.
>>
>
> so I am going to grab and hold onto
>>>> Further, I think we can add the new syscall API separately from the
>>>> LSM stacking changes as they do have standalone value.
>>>
>
> what I think Paul is saying is we can move the LSM stacking patches
> forward by removing the combined label interface.
Do you mean /proc/self/attr/interface_lsm? /proc/.../attr/context?
> They won't be as
> useful but it would be a huge step forward, and the next step could
> be the syscall API.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-09-07 0:39 ` Casey Schaufler
0 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-07 0:39 UTC (permalink / raw)
To: John Johansen, Paul Moore
Cc: SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On 9/6/2022 5:10 PM, John Johansen wrote:
> sorry I am wayyyy behind on this, so starting from here
>
> On 9/6/22 16:24, Paul Moore wrote:
>> I can't currently in good conscience defend the kernel/userspace
>> combined label interfaces as "good", especially when we have a very
>> rare opportunity to do better.
>>
>
> so I am going to grab and hold onto
>>>> Further, I think we can add the new syscall API separately from the
>>>> LSM stacking changes as they do have standalone value.
>>>
>
> what I think Paul is saying is we can move the LSM stacking patches
> forward by removing the combined label interface.
Do you mean /proc/self/attr/interface_lsm? /proc/.../attr/context?
> They won't be as
> useful but it would be a huge step forward, and the next step could
> be the syscall API.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-07 0:39 ` Casey Schaufler
@ 2022-09-07 0:50 ` John Johansen
-1 siblings, 0 replies; 148+ messages in thread
From: John Johansen @ 2022-09-07 0:50 UTC (permalink / raw)
To: Casey Schaufler, Paul Moore
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook, SElinux list
On 9/6/22 17:39, Casey Schaufler wrote:
> On 9/6/2022 5:10 PM, John Johansen wrote:
>> sorry I am wayyyy behind on this, so starting from here
>>
>> On 9/6/22 16:24, Paul Moore wrote:
>>> I can't currently in good conscience defend the kernel/userspace
>>> combined label interfaces as "good", especially when we have a very
>>> rare opportunity to do better.
>>>
>>
>> so I am going to grab and hold onto
>>>>> Further, I think we can add the new syscall API separately from the
>>>>> LSM stacking changes as they do have standalone value.
>>>>
>>
>> what I think Paul is saying is we can move the LSM stacking patches
>> forward by removing the combined label interface.
>
> Do you mean /proc/self/attr/interface_lsm? /proc/.../attr/context?
/proc/.../attr/context is the combined label interface.
/proc/self/attr/interface_lsm is an interesting question. Its not
a combined label interface, instead it is a new interface that allows
controlling of which LSM the task get to see on the old
/proc/.../attr/* interface.
Loosing it would hurt (its a useful tool and is currently necessary
for the SElinux host + AppArmor in container use case) but I think
if that is cost to move forward dropping it at least for now would
be worth it.
>> They won't be as
>> useful but it would be a huge step forward, and the next step could
>> be the syscall API.
>
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-09-07 0:50 ` John Johansen
0 siblings, 0 replies; 148+ messages in thread
From: John Johansen @ 2022-09-07 0:50 UTC (permalink / raw)
To: Casey Schaufler, Paul Moore
Cc: SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On 9/6/22 17:39, Casey Schaufler wrote:
> On 9/6/2022 5:10 PM, John Johansen wrote:
>> sorry I am wayyyy behind on this, so starting from here
>>
>> On 9/6/22 16:24, Paul Moore wrote:
>>> I can't currently in good conscience defend the kernel/userspace
>>> combined label interfaces as "good", especially when we have a very
>>> rare opportunity to do better.
>>>
>>
>> so I am going to grab and hold onto
>>>>> Further, I think we can add the new syscall API separately from the
>>>>> LSM stacking changes as they do have standalone value.
>>>>
>>
>> what I think Paul is saying is we can move the LSM stacking patches
>> forward by removing the combined label interface.
>
> Do you mean /proc/self/attr/interface_lsm? /proc/.../attr/context?
/proc/.../attr/context is the combined label interface.
/proc/self/attr/interface_lsm is an interesting question. Its not
a combined label interface, instead it is a new interface that allows
controlling of which LSM the task get to see on the old
/proc/.../attr/* interface.
Loosing it would hurt (its a useful tool and is currently necessary
for the SElinux host + AppArmor in container use case) but I think
if that is cost to move forward dropping it at least for now would
be worth it.
>> They won't be as
>> useful but it would be a huge step forward, and the next step could
>> be the syscall API.
>
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-07 0:10 ` John Johansen
@ 2022-09-07 14:41 ` Paul Moore
-1 siblings, 0 replies; 148+ messages in thread
From: Paul Moore @ 2022-09-07 14:41 UTC (permalink / raw)
To: John Johansen
Cc: SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On Tue, Sep 6, 2022 at 8:10 PM John Johansen
<john.johansen@canonical.com> wrote:
> On 9/6/22 16:24, Paul Moore wrote:
> > On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >> On 9/2/2022 2:30 PM, Paul Moore wrote:
> >>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
> >>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
...
> > If you are running AppArmor on the host system and SELinux in a
> > container you are likely going to have some *very* bizarre behavior as
> > the SELinux policy you load in the container will apply to the entire
> > system, including processes which started *before* the SELinux policy
> > was loaded. While I understand the point you are trying to make, I
> > don't believe the example you chose is going to work without a lot of
> > other changes.
>
> correct but the reverse does work ...
Sure, that doesn't surprise me, but that isn't the example Casey brought up.
> >>> I think it's time to think about a proper set of LSM syscalls.
> >>
> >> At the very least we need a liblsm that preforms a number of useful
> >> functions, like identifying what security modules are available,
> >> validating "contexts", fetching "contexts" from files and processes
> >> and that sort of thing. Whether it is built on syscalls or /proc and
> >> getxattr() is a matter of debate and taste.
> >
> > Why is it a forgone conclusion that a library would be necessary for
> > basic operations? If the kernel/userspace API is sane to begin with
> > we could probably either significantly reduce or eliminate the need
> > for additional libraries. I really want us to attempt to come up with
> > a decent kernel/userspace API to begin with as opposed to using the
> > excuse of a userspace library to hide API sins that never should have
> > been committed.
>
> I don't think its a foregone conclusion, its just that it has been
> discussed several times, and all the interfaces have been nasty and
> prebaked userspace code would be really nice to have.
>
> There are other reasons to use a lib as well. Libs can help apps
> pickup fixes/changes automatically.
Fair point.
> > The LSM stacking work presents us with a unique opportunity to
> > modify/update/whatever the LSM kernel/userspace API, I don't want to
> > see us squander this chance on a hack.
>
> I do wish we had a better API from the beginning. I just hope it isn't
> going to take another 10 years to get the API portion done.
This really should surprise no one at this point, but I care very
little about how long something might take, or how difficult it might
be if it is something we are going to have to live with
<dramatic_voice>forever</dramatic_voice>. I'm sympathetic that this
work has been going on for some time, but that is no reason to push
through a bad design; look at the ACKs/reviews on the combined-label
patches vs the others in the series, that's a pretty good indication
that no one is really excited about that design.
> >> The /proc interfaces interface_lsm and context are really pretty simple.
>
> > They are now, they are also a bit of a mess with legacy constraints
> > and they only get more complicated and messy with the LSM stacking
> > patches. It is my opinion that a syscall-based API is cleaner and
> > easier for applications to use.
>
> potentially if we can get one
Let me try and remove some ambiguity from that - I'm not going to
merge any combined-label APIs. I'm not sold on the syscall-based API,
I'm open to other ideas, but it needs to support distinct per-LSM
labels that allow applications to identify which LSMs are active and
which labels belong to each. In addition, I do not want any changes
to the existing procfs APIs as I want there to be zero chance we will
break existing applications; if existing applications need to be made
aware of a simul-multi-LSM world then they would need to change to the
new API, whatever that may be.
> >>> Further, I think we can add the new syscall API separately from the
> >>> LSM stacking changes as they do have standalone value.
>
> what I think Paul is saying is we can move the LSM stacking patches
> forward by removing the combined label interface. They won't be as
> useful but it would be a huge step forward, and the next step could
> be the syscall API.
Whatever new LSM API we decide on, I want to see that developed and
merged first. It obviously must be designed to support multiple,
simultaneously active LSMs.
--
paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-09-07 14:41 ` Paul Moore
0 siblings, 0 replies; 148+ messages in thread
From: Paul Moore @ 2022-09-07 14:41 UTC (permalink / raw)
To: John Johansen
Cc: Casey Schaufler, LSM List, James Morris, linux-audit, Mimi Zohar,
keescook, SElinux list
On Tue, Sep 6, 2022 at 8:10 PM John Johansen
<john.johansen@canonical.com> wrote:
> On 9/6/22 16:24, Paul Moore wrote:
> > On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >> On 9/2/2022 2:30 PM, Paul Moore wrote:
> >>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
> >>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
...
> > If you are running AppArmor on the host system and SELinux in a
> > container you are likely going to have some *very* bizarre behavior as
> > the SELinux policy you load in the container will apply to the entire
> > system, including processes which started *before* the SELinux policy
> > was loaded. While I understand the point you are trying to make, I
> > don't believe the example you chose is going to work without a lot of
> > other changes.
>
> correct but the reverse does work ...
Sure, that doesn't surprise me, but that isn't the example Casey brought up.
> >>> I think it's time to think about a proper set of LSM syscalls.
> >>
> >> At the very least we need a liblsm that preforms a number of useful
> >> functions, like identifying what security modules are available,
> >> validating "contexts", fetching "contexts" from files and processes
> >> and that sort of thing. Whether it is built on syscalls or /proc and
> >> getxattr() is a matter of debate and taste.
> >
> > Why is it a forgone conclusion that a library would be necessary for
> > basic operations? If the kernel/userspace API is sane to begin with
> > we could probably either significantly reduce or eliminate the need
> > for additional libraries. I really want us to attempt to come up with
> > a decent kernel/userspace API to begin with as opposed to using the
> > excuse of a userspace library to hide API sins that never should have
> > been committed.
>
> I don't think its a foregone conclusion, its just that it has been
> discussed several times, and all the interfaces have been nasty and
> prebaked userspace code would be really nice to have.
>
> There are other reasons to use a lib as well. Libs can help apps
> pickup fixes/changes automatically.
Fair point.
> > The LSM stacking work presents us with a unique opportunity to
> > modify/update/whatever the LSM kernel/userspace API, I don't want to
> > see us squander this chance on a hack.
>
> I do wish we had a better API from the beginning. I just hope it isn't
> going to take another 10 years to get the API portion done.
This really should surprise no one at this point, but I care very
little about how long something might take, or how difficult it might
be if it is something we are going to have to live with
<dramatic_voice>forever</dramatic_voice>. I'm sympathetic that this
work has been going on for some time, but that is no reason to push
through a bad design; look at the ACKs/reviews on the combined-label
patches vs the others in the series, that's a pretty good indication
that no one is really excited about that design.
> >> The /proc interfaces interface_lsm and context are really pretty simple.
>
> > They are now, they are also a bit of a mess with legacy constraints
> > and they only get more complicated and messy with the LSM stacking
> > patches. It is my opinion that a syscall-based API is cleaner and
> > easier for applications to use.
>
> potentially if we can get one
Let me try and remove some ambiguity from that - I'm not going to
merge any combined-label APIs. I'm not sold on the syscall-based API,
I'm open to other ideas, but it needs to support distinct per-LSM
labels that allow applications to identify which LSMs are active and
which labels belong to each. In addition, I do not want any changes
to the existing procfs APIs as I want there to be zero chance we will
break existing applications; if existing applications need to be made
aware of a simul-multi-LSM world then they would need to change to the
new API, whatever that may be.
> >>> Further, I think we can add the new syscall API separately from the
> >>> LSM stacking changes as they do have standalone value.
>
> what I think Paul is saying is we can move the LSM stacking patches
> forward by removing the combined label interface. They won't be as
> useful but it would be a huge step forward, and the next step could
> be the syscall API.
Whatever new LSM API we decide on, I want to see that developed and
merged first. It obviously must be designed to support multiple,
simultaneously active LSMs.
--
paul-moore.com
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-07 14:41 ` Paul Moore
@ 2022-09-07 16:41 ` Casey Schaufler
-1 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-07 16:41 UTC (permalink / raw)
To: Paul Moore, John Johansen
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook,
SElinux list, casey
On 9/7/2022 7:41 AM, Paul Moore wrote:
> On Tue, Sep 6, 2022 at 8:10 PM John Johansen
> <john.johansen@canonical.com> wrote:
>> On 9/6/22 16:24, Paul Moore wrote:
>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> ..
>
>>> If you are running AppArmor on the host system and SELinux in a
>>> container you are likely going to have some *very* bizarre behavior as
>>> the SELinux policy you load in the container will apply to the entire
>>> system, including processes which started *before* the SELinux policy
>>> was loaded. While I understand the point you are trying to make, I
>>> don't believe the example you chose is going to work without a lot of
>>> other changes.
>> correct but the reverse does work ...
> Sure, that doesn't surprise me, but that isn't the example Casey brought up.
I said that I'm not sure how they go about doing Android on Ubuntu.
I brought it up because I've seen it.
>>>>> I think it's time to think about a proper set of LSM syscalls.
>>>> At the very least we need a liblsm that preforms a number of useful
>>>> functions, like identifying what security modules are available,
>>>> validating "contexts", fetching "contexts" from files and processes
>>>> and that sort of thing. Whether it is built on syscalls or /proc and
>>>> getxattr() is a matter of debate and taste.
>>> Why is it a forgone conclusion that a library would be necessary for
>>> basic operations? If the kernel/userspace API is sane to begin with
>>> we could probably either significantly reduce or eliminate the need
>>> for additional libraries. I really want us to attempt to come up with
>>> a decent kernel/userspace API to begin with as opposed to using the
>>> excuse of a userspace library to hide API sins that never should have
>>> been committed.
>> I don't think its a foregone conclusion, its just that it has been
>> discussed several times, and all the interfaces have been nasty and
>> prebaked userspace code would be really nice to have.
>>
>> There are other reasons to use a lib as well. Libs can help apps
>> pickup fixes/changes automatically.
> Fair point.
>
>>> The LSM stacking work presents us with a unique opportunity to
>>> modify/update/whatever the LSM kernel/userspace API, I don't want to
>>> see us squander this chance on a hack.
>> I do wish we had a better API from the beginning. I just hope it isn't
>> going to take another 10 years to get the API portion done.
> This really should surprise no one at this point, but I care very
> little about how long something might take, or how difficult it might
> be if it is something we are going to have to live with
> <dramatic_voice>forever</dramatic_voice>.
Fair point.
> I'm sympathetic that this
> work has been going on for some time, but that is no reason to push
> through a bad design; look at the ACKs/reviews on the combined-label
> patches vs the others in the series, that's a pretty good indication
> that no one is really excited about that design.
The kernel developers aren't the consumers of these APIs. There
has been considerable feedback from system application developers
on the interfaces. This included dbus and systemd. Kernel developers
aren't interested in these APIs because they don't care one way or
the other. That, and as you are painfully aware, some of them are
really busy on their own projects.
Am I really happy with the "hideous" format? Yeah, because it makes
the end user happy. Am I happy with interface_lsm? Other than the
name, which was the result of feedback, yes, because it in the
simplest way to accomplish the goal.
I am curious about what you think is "bad" about the current design.
The interfaces aren't exciting. They don't need to be.
>>>> The /proc interfaces interface_lsm and context are really pretty simple.
>>> They are now, they are also a bit of a mess with legacy constraints
>>> and they only get more complicated and messy with the LSM stacking
>>> patches. It is my opinion that a syscall-based API is cleaner and
>>> easier for applications to use.
>> potentially if we can get one
> Let me try and remove some ambiguity from that - I'm not going to
> merge any combined-label APIs.
Why? A combined-label API is what the application developers asked for.
> I'm not sold on the syscall-based API,
> I'm open to other ideas, but it needs to support distinct per-LSM
> labels that allow applications to identify which LSMs are active and
> which labels belong to each.
??????? This is exactly what I've provided.
"apparmor\0unconfined\0smack\0User\0"
You know exactly what LSMs are providing data and what that data is.
How could it be clearer or cleaner?
> In addition, I do not want any changes
> to the existing procfs APIs as I want there to be zero chance we will
> break existing applications;
Are you saying that interface_lsm changes the /proc/.../attr/current API?
That API is already dependent on the active security module. You may get
an AppArmor, SELinux or Smack context from that API. It's been thus for a
long time. Creating the smack and apparmor subdirectories was done to help
make this cleaner. But those are new APIs. The existing applications either
allow for a variety of security modules (e.g. ps(1)) or need to check for
a particular one (e.g. id(1), which doesn't need to and would be better if
it didn't, but what the hay). If they don't they are flawed and should be
repaired.
> if existing applications need to be made
> aware of a simul-multi-LSM world then they would need to change to the
> new API, whatever that may be.
Agreed. That's why the proposed APIs have been discussed with many
of those application communities.
>>>>> Further, I think we can add the new syscall API separately from the
>>>>> LSM stacking changes as they do have standalone value.
>> what I think Paul is saying is we can move the LSM stacking patches
>> forward by removing the combined label interface. They won't be as
>> useful but it would be a huge step forward, and the next step could
>> be the syscall API.
> Whatever new LSM API we decide on, I want to see that developed and
> merged first. It obviously must be designed to support multiple,
> simultaneously active LSMs.
That's what I've been proposing all along. You don't like the APIs.
What don't you like about them? I believe they address the objections
you've raised. I know that I can be real obtuse from time to time,
but I don't see how they fail to meet your requirements.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-09-07 16:41 ` Casey Schaufler
0 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-07 16:41 UTC (permalink / raw)
To: Paul Moore, John Johansen
Cc: SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On 9/7/2022 7:41 AM, Paul Moore wrote:
> On Tue, Sep 6, 2022 at 8:10 PM John Johansen
> <john.johansen@canonical.com> wrote:
>> On 9/6/22 16:24, Paul Moore wrote:
>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> ..
>
>>> If you are running AppArmor on the host system and SELinux in a
>>> container you are likely going to have some *very* bizarre behavior as
>>> the SELinux policy you load in the container will apply to the entire
>>> system, including processes which started *before* the SELinux policy
>>> was loaded. While I understand the point you are trying to make, I
>>> don't believe the example you chose is going to work without a lot of
>>> other changes.
>> correct but the reverse does work ...
> Sure, that doesn't surprise me, but that isn't the example Casey brought up.
I said that I'm not sure how they go about doing Android on Ubuntu.
I brought it up because I've seen it.
>>>>> I think it's time to think about a proper set of LSM syscalls.
>>>> At the very least we need a liblsm that preforms a number of useful
>>>> functions, like identifying what security modules are available,
>>>> validating "contexts", fetching "contexts" from files and processes
>>>> and that sort of thing. Whether it is built on syscalls or /proc and
>>>> getxattr() is a matter of debate and taste.
>>> Why is it a forgone conclusion that a library would be necessary for
>>> basic operations? If the kernel/userspace API is sane to begin with
>>> we could probably either significantly reduce or eliminate the need
>>> for additional libraries. I really want us to attempt to come up with
>>> a decent kernel/userspace API to begin with as opposed to using the
>>> excuse of a userspace library to hide API sins that never should have
>>> been committed.
>> I don't think its a foregone conclusion, its just that it has been
>> discussed several times, and all the interfaces have been nasty and
>> prebaked userspace code would be really nice to have.
>>
>> There are other reasons to use a lib as well. Libs can help apps
>> pickup fixes/changes automatically.
> Fair point.
>
>>> The LSM stacking work presents us with a unique opportunity to
>>> modify/update/whatever the LSM kernel/userspace API, I don't want to
>>> see us squander this chance on a hack.
>> I do wish we had a better API from the beginning. I just hope it isn't
>> going to take another 10 years to get the API portion done.
> This really should surprise no one at this point, but I care very
> little about how long something might take, or how difficult it might
> be if it is something we are going to have to live with
> <dramatic_voice>forever</dramatic_voice>.
Fair point.
> I'm sympathetic that this
> work has been going on for some time, but that is no reason to push
> through a bad design; look at the ACKs/reviews on the combined-label
> patches vs the others in the series, that's a pretty good indication
> that no one is really excited about that design.
The kernel developers aren't the consumers of these APIs. There
has been considerable feedback from system application developers
on the interfaces. This included dbus and systemd. Kernel developers
aren't interested in these APIs because they don't care one way or
the other. That, and as you are painfully aware, some of them are
really busy on their own projects.
Am I really happy with the "hideous" format? Yeah, because it makes
the end user happy. Am I happy with interface_lsm? Other than the
name, which was the result of feedback, yes, because it in the
simplest way to accomplish the goal.
I am curious about what you think is "bad" about the current design.
The interfaces aren't exciting. They don't need to be.
>>>> The /proc interfaces interface_lsm and context are really pretty simple.
>>> They are now, they are also a bit of a mess with legacy constraints
>>> and they only get more complicated and messy with the LSM stacking
>>> patches. It is my opinion that a syscall-based API is cleaner and
>>> easier for applications to use.
>> potentially if we can get one
> Let me try and remove some ambiguity from that - I'm not going to
> merge any combined-label APIs.
Why? A combined-label API is what the application developers asked for.
> I'm not sold on the syscall-based API,
> I'm open to other ideas, but it needs to support distinct per-LSM
> labels that allow applications to identify which LSMs are active and
> which labels belong to each.
??????? This is exactly what I've provided.
"apparmor\0unconfined\0smack\0User\0"
You know exactly what LSMs are providing data and what that data is.
How could it be clearer or cleaner?
> In addition, I do not want any changes
> to the existing procfs APIs as I want there to be zero chance we will
> break existing applications;
Are you saying that interface_lsm changes the /proc/.../attr/current API?
That API is already dependent on the active security module. You may get
an AppArmor, SELinux or Smack context from that API. It's been thus for a
long time. Creating the smack and apparmor subdirectories was done to help
make this cleaner. But those are new APIs. The existing applications either
allow for a variety of security modules (e.g. ps(1)) or need to check for
a particular one (e.g. id(1), which doesn't need to and would be better if
it didn't, but what the hay). If they don't they are flawed and should be
repaired.
> if existing applications need to be made
> aware of a simul-multi-LSM world then they would need to change to the
> new API, whatever that may be.
Agreed. That's why the proposed APIs have been discussed with many
of those application communities.
>>>>> Further, I think we can add the new syscall API separately from the
>>>>> LSM stacking changes as they do have standalone value.
>> what I think Paul is saying is we can move the LSM stacking patches
>> forward by removing the combined label interface. They won't be as
>> useful but it would be a huge step forward, and the next step could
>> be the syscall API.
> Whatever new LSM API we decide on, I want to see that developed and
> merged first. It obviously must be designed to support multiple,
> simultaneously active LSMs.
That's what I've been proposing all along. You don't like the APIs.
What don't you like about them? I believe they address the objections
you've raised. I know that I can be real obtuse from time to time,
but I don't see how they fail to meet your requirements.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-07 16:41 ` Casey Schaufler
@ 2022-09-07 17:23 ` John Johansen
-1 siblings, 0 replies; 148+ messages in thread
From: John Johansen @ 2022-09-07 17:23 UTC (permalink / raw)
To: Casey Schaufler, Paul Moore
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook, SElinux list
On 9/7/22 09:41, Casey Schaufler wrote:
> On 9/7/2022 7:41 AM, Paul Moore wrote:
>> On Tue, Sep 6, 2022 at 8:10 PM John Johansen
>> <john.johansen@canonical.com> wrote:
>>> On 9/6/22 16:24, Paul Moore wrote:
>>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> ..
>>
>>>> If you are running AppArmor on the host system and SELinux in a
>>>> container you are likely going to have some *very* bizarre behavior as
>>>> the SELinux policy you load in the container will apply to the entire
>>>> system, including processes which started *before* the SELinux policy
>>>> was loaded. While I understand the point you are trying to make, I
>>>> don't believe the example you chose is going to work without a lot of
>>>> other changes.
>>> correct but the reverse does work ...
>> Sure, that doesn't surprise me, but that isn't the example Casey brought up.
>
> I said that I'm not sure how they go about doing Android on Ubuntu.
> I brought it up because I've seen it.
>
LSM stacking for that use case is necessary but insufficient. At a minimum
SELinux would need bounding, and realistically some other gymnastics. I
don't hold out hope of it happening soon if ever. I have told the anbox people
such. At the momement anbox disables SELinux when run in a container
https://github.com/anbox/platform_system_core/commit/71907fc5e7833866be6ae3c120c602974edf8322
there has been work on using a VM instead so that they can have SELinux
but I am not current on how/when that is used.
Where Canonical is interested in LSM stacking is running snaps with apparmor
confinement on top of SELinux distros. I know snaps aren't popular but it is
a much more realistic and attainable use case for LSM stacking.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-09-07 17:23 ` John Johansen
0 siblings, 0 replies; 148+ messages in thread
From: John Johansen @ 2022-09-07 17:23 UTC (permalink / raw)
To: Casey Schaufler, Paul Moore
Cc: SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On 9/7/22 09:41, Casey Schaufler wrote:
> On 9/7/2022 7:41 AM, Paul Moore wrote:
>> On Tue, Sep 6, 2022 at 8:10 PM John Johansen
>> <john.johansen@canonical.com> wrote:
>>> On 9/6/22 16:24, Paul Moore wrote:
>>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> ..
>>
>>>> If you are running AppArmor on the host system and SELinux in a
>>>> container you are likely going to have some *very* bizarre behavior as
>>>> the SELinux policy you load in the container will apply to the entire
>>>> system, including processes which started *before* the SELinux policy
>>>> was loaded. While I understand the point you are trying to make, I
>>>> don't believe the example you chose is going to work without a lot of
>>>> other changes.
>>> correct but the reverse does work ...
>> Sure, that doesn't surprise me, but that isn't the example Casey brought up.
>
> I said that I'm not sure how they go about doing Android on Ubuntu.
> I brought it up because I've seen it.
>
LSM stacking for that use case is necessary but insufficient. At a minimum
SELinux would need bounding, and realistically some other gymnastics. I
don't hold out hope of it happening soon if ever. I have told the anbox people
such. At the momement anbox disables SELinux when run in a container
https://github.com/anbox/platform_system_core/commit/71907fc5e7833866be6ae3c120c602974edf8322
there has been work on using a VM instead so that they can have SELinux
but I am not current on how/when that is used.
Where Canonical is interested in LSM stacking is running snaps with apparmor
confinement on top of SELinux distros. I know snaps aren't popular but it is
a much more realistic and attainable use case for LSM stacking.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-07 17:23 ` John Johansen
@ 2022-09-07 22:57 ` Paul Moore
-1 siblings, 0 replies; 148+ messages in thread
From: Paul Moore @ 2022-09-07 22:57 UTC (permalink / raw)
To: John Johansen
Cc: Casey Schaufler, LSM List, James Morris, linux-audit, Mimi Zohar,
keescook, SElinux list
On Wed, Sep 7, 2022 at 1:23 PM John Johansen
<john.johansen@canonical.com> wrote:
> On 9/7/22 09:41, Casey Schaufler wrote:
> > On 9/7/2022 7:41 AM, Paul Moore wrote:
> >> On Tue, Sep 6, 2022 at 8:10 PM John Johansen
> >> <john.johansen@canonical.com> wrote:
> >>> On 9/6/22 16:24, Paul Moore wrote:
> >>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >>>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
> >>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
> >>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >> ..
> >>
> >>>> If you are running AppArmor on the host system and SELinux in a
> >>>> container you are likely going to have some *very* bizarre behavior as
> >>>> the SELinux policy you load in the container will apply to the entire
> >>>> system, including processes which started *before* the SELinux policy
> >>>> was loaded. While I understand the point you are trying to make, I
> >>>> don't believe the example you chose is going to work without a lot of
> >>>> other changes.
> >>> correct but the reverse does work ...
> >> Sure, that doesn't surprise me, but that isn't the example Casey brought up.
> >
> > I said that I'm not sure how they go about doing Android on Ubuntu.
> > I brought it up because I've seen it.
>
> LSM stacking for that use case is necessary but insufficient.
Yes, exactly. One of my bigger worries about the stacking effort is
that a lot of people have some false assumptions about what it will
actually enable. Of course that doesn't mean it isn't worth doing,
just that there may be a lot of disappointed people out there.
> At a minimum
> SELinux would need bounding, and realistically some other gymnastics. I
> don't hold out hope of it happening soon if ever. I have told the anbox people
> such.
Most of that is just a matter of writing the code. Yes, that's going
to be a decent chunk of work, but the idea is relatively
straightforward. The bit that keeps blocking this in my mind is
handling of the persistent filesystem labels, that's a conceptual
problem we have yet to solve. The current solution of just creating
more and more (scoped) xattrs isn't going to scale to the level I
believe we are going to need. I keep toying with the idea of just
punting on it and leaving it up to the container orchestrator to
manage the filesystems; if you want to run a nested SELinux instance
inside a container with dedicated file labels you need your own
filesystem mounted. Dunno, lots to think about here ...
> At the momement anbox disables SELinux when run in a container
>
> https://github.com/anbox/platform_system_core/commit/71907fc5e7833866be6ae3c120c602974edf8322
>
> there has been work on using a VM instead so that they can have SELinux
> but I am not current on how/when that is used.
That makes much more sense, thanks John.
--
paul-moore.com
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-09-07 22:57 ` Paul Moore
0 siblings, 0 replies; 148+ messages in thread
From: Paul Moore @ 2022-09-07 22:57 UTC (permalink / raw)
To: John Johansen
Cc: SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On Wed, Sep 7, 2022 at 1:23 PM John Johansen
<john.johansen@canonical.com> wrote:
> On 9/7/22 09:41, Casey Schaufler wrote:
> > On 9/7/2022 7:41 AM, Paul Moore wrote:
> >> On Tue, Sep 6, 2022 at 8:10 PM John Johansen
> >> <john.johansen@canonical.com> wrote:
> >>> On 9/6/22 16:24, Paul Moore wrote:
> >>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >>>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
> >>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
> >>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >> ..
> >>
> >>>> If you are running AppArmor on the host system and SELinux in a
> >>>> container you are likely going to have some *very* bizarre behavior as
> >>>> the SELinux policy you load in the container will apply to the entire
> >>>> system, including processes which started *before* the SELinux policy
> >>>> was loaded. While I understand the point you are trying to make, I
> >>>> don't believe the example you chose is going to work without a lot of
> >>>> other changes.
> >>> correct but the reverse does work ...
> >> Sure, that doesn't surprise me, but that isn't the example Casey brought up.
> >
> > I said that I'm not sure how they go about doing Android on Ubuntu.
> > I brought it up because I've seen it.
>
> LSM stacking for that use case is necessary but insufficient.
Yes, exactly. One of my bigger worries about the stacking effort is
that a lot of people have some false assumptions about what it will
actually enable. Of course that doesn't mean it isn't worth doing,
just that there may be a lot of disappointed people out there.
> At a minimum
> SELinux would need bounding, and realistically some other gymnastics. I
> don't hold out hope of it happening soon if ever. I have told the anbox people
> such.
Most of that is just a matter of writing the code. Yes, that's going
to be a decent chunk of work, but the idea is relatively
straightforward. The bit that keeps blocking this in my mind is
handling of the persistent filesystem labels, that's a conceptual
problem we have yet to solve. The current solution of just creating
more and more (scoped) xattrs isn't going to scale to the level I
believe we are going to need. I keep toying with the idea of just
punting on it and leaving it up to the container orchestrator to
manage the filesystems; if you want to run a nested SELinux instance
inside a container with dedicated file labels you need your own
filesystem mounted. Dunno, lots to think about here ...
> At the momement anbox disables SELinux when run in a container
>
> https://github.com/anbox/platform_system_core/commit/71907fc5e7833866be6ae3c120c602974edf8322
>
> there has been work on using a VM instead so that they can have SELinux
> but I am not current on how/when that is used.
That makes much more sense, thanks John.
--
paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-07 16:41 ` Casey Schaufler
@ 2022-09-07 23:27 ` Paul Moore
-1 siblings, 0 replies; 148+ messages in thread
From: Paul Moore @ 2022-09-07 23:27 UTC (permalink / raw)
To: Casey Schaufler
Cc: John Johansen, LSM List, James Morris, linux-audit, Mimi Zohar,
keescook, SElinux list
On Wed, Sep 7, 2022 at 12:42 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 9/7/2022 7:41 AM, Paul Moore wrote:
> > On Tue, Sep 6, 2022 at 8:10 PM John Johansen
> > <john.johansen@canonical.com> wrote:
> >> On 9/6/22 16:24, Paul Moore wrote:
> >>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
> >>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
> >>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> > ..
> >
> >>> If you are running AppArmor on the host system and SELinux in a
> >>> container you are likely going to have some *very* bizarre behavior as
> >>> the SELinux policy you load in the container will apply to the entire
> >>> system, including processes which started *before* the SELinux policy
> >>> was loaded. While I understand the point you are trying to make, I
> >>> don't believe the example you chose is going to work without a lot of
> >>> other changes.
> >> correct but the reverse does work ...
> > Sure, that doesn't surprise me, but that isn't the example Casey brought up.
>
> I said that I'm not sure how they go about doing Android on Ubuntu.
> I brought it up because I've seen it.
Addressed in the other portion of this thread, but the quick response
here is: No, you were mistaken, that was not proper Android, SELinux
was disabled.
> > I'm sympathetic that this
> > work has been going on for some time, but that is no reason to push
> > through a bad design; look at the ACKs/reviews on the combined-label
> > patches vs the others in the series, that's a pretty good indication
> > that no one is really excited about that design.
>
> The kernel developers aren't the consumers of these APIs. There
> has been considerable feedback from system application developers
> on the interfaces. This included dbus and systemd. Kernel developers
> aren't interested in these APIs because they don't care one way or
> the other. That, and as you are painfully aware, some of them are
> really busy on their own projects.
Yes, everyone is busy yet they found time to ACK/review the other
patches in the patchset. I'm not buying the "busy" argument here.
Yes, you are also correct in that the kernel devs are not likely to be
the main consumers of any kernel/userspace API, but we do have to
support these APIs and find ways to handle the inevitable misuse and
abuse of these APIs. Further, while I do believe that you've talked
to some application developers about the current proposed API, I'm
reasonably confident that it isn't the only API they would be happy
supporting in their applications.
As far as kernel developers not being interested in these APIs, I
think the recent conversation in this thread proves the exact opposite
;)
> Am I really happy with the "hideous" format? Yeah, because it makes
> the end user happy. Am I happy with interface_lsm? Other than the
> name, which was the result of feedback, yes, because it in the
> simplest way to accomplish the goal.
>
> I am curious about what you think is "bad" about the current design.
> The interfaces aren't exciting. They don't need to be.
I don't even know what an exciting interface would look like ... ? I
just want an interface that is clearly defined, has reasonable
capacity to be extended in the future as needed, and is easy(ish) to
use and support over extended periods of time (both from a kernel and
userspace perspective).
The "smack_label\0apparmor_label\0selinux_label\0future_lsm_label\0"
string interface is none of these things. It is not clearly defined
as it requires other interfaces to associate the labels with the
correct LSMs. It has no provision for extension beyond adding a new
LSM. The ease-of-use quality is a bit subjective, but it does need
another interface to use properly and it requires string parsing which
history has shown to be an issue time and time again (although it is
relatively simple here).
Once again, the syscall example I tossed out was a quick strawman, but
it had clearly separated and defined labels conveyed in data
structures that didn't require string parsing to find the label
associated with an LSM. It was also self-contained in that no other
interface was needed to interpret the results of the syscall (well,
beyond the header file definitions I guess). Finally, it made use of
flags and "reserved for future use" token values to allow for
additional data to be conveyed in the future.
--
paul-moore.com
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-09-07 23:27 ` Paul Moore
0 siblings, 0 replies; 148+ messages in thread
From: Paul Moore @ 2022-09-07 23:27 UTC (permalink / raw)
To: Casey Schaufler
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On Wed, Sep 7, 2022 at 12:42 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 9/7/2022 7:41 AM, Paul Moore wrote:
> > On Tue, Sep 6, 2022 at 8:10 PM John Johansen
> > <john.johansen@canonical.com> wrote:
> >> On 9/6/22 16:24, Paul Moore wrote:
> >>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
> >>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
> >>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> > ..
> >
> >>> If you are running AppArmor on the host system and SELinux in a
> >>> container you are likely going to have some *very* bizarre behavior as
> >>> the SELinux policy you load in the container will apply to the entire
> >>> system, including processes which started *before* the SELinux policy
> >>> was loaded. While I understand the point you are trying to make, I
> >>> don't believe the example you chose is going to work without a lot of
> >>> other changes.
> >> correct but the reverse does work ...
> > Sure, that doesn't surprise me, but that isn't the example Casey brought up.
>
> I said that I'm not sure how they go about doing Android on Ubuntu.
> I brought it up because I've seen it.
Addressed in the other portion of this thread, but the quick response
here is: No, you were mistaken, that was not proper Android, SELinux
was disabled.
> > I'm sympathetic that this
> > work has been going on for some time, but that is no reason to push
> > through a bad design; look at the ACKs/reviews on the combined-label
> > patches vs the others in the series, that's a pretty good indication
> > that no one is really excited about that design.
>
> The kernel developers aren't the consumers of these APIs. There
> has been considerable feedback from system application developers
> on the interfaces. This included dbus and systemd. Kernel developers
> aren't interested in these APIs because they don't care one way or
> the other. That, and as you are painfully aware, some of them are
> really busy on their own projects.
Yes, everyone is busy yet they found time to ACK/review the other
patches in the patchset. I'm not buying the "busy" argument here.
Yes, you are also correct in that the kernel devs are not likely to be
the main consumers of any kernel/userspace API, but we do have to
support these APIs and find ways to handle the inevitable misuse and
abuse of these APIs. Further, while I do believe that you've talked
to some application developers about the current proposed API, I'm
reasonably confident that it isn't the only API they would be happy
supporting in their applications.
As far as kernel developers not being interested in these APIs, I
think the recent conversation in this thread proves the exact opposite
;)
> Am I really happy with the "hideous" format? Yeah, because it makes
> the end user happy. Am I happy with interface_lsm? Other than the
> name, which was the result of feedback, yes, because it in the
> simplest way to accomplish the goal.
>
> I am curious about what you think is "bad" about the current design.
> The interfaces aren't exciting. They don't need to be.
I don't even know what an exciting interface would look like ... ? I
just want an interface that is clearly defined, has reasonable
capacity to be extended in the future as needed, and is easy(ish) to
use and support over extended periods of time (both from a kernel and
userspace perspective).
The "smack_label\0apparmor_label\0selinux_label\0future_lsm_label\0"
string interface is none of these things. It is not clearly defined
as it requires other interfaces to associate the labels with the
correct LSMs. It has no provision for extension beyond adding a new
LSM. The ease-of-use quality is a bit subjective, but it does need
another interface to use properly and it requires string parsing which
history has shown to be an issue time and time again (although it is
relatively simple here).
Once again, the syscall example I tossed out was a quick strawman, but
it had clearly separated and defined labels conveyed in data
structures that didn't require string parsing to find the label
associated with an LSM. It was also self-contained in that no other
interface was needed to interpret the results of the syscall (well,
beyond the header file definitions I guess). Finally, it made use of
flags and "reserved for future use" token values to allow for
additional data to be conveyed in the future.
--
paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-07 23:27 ` Paul Moore
@ 2022-09-07 23:53 ` Casey Schaufler
-1 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-07 23:53 UTC (permalink / raw)
To: Paul Moore
Cc: John Johansen, LSM List, James Morris, linux-audit, Mimi Zohar,
keescook, SElinux list, casey
On 9/7/2022 4:27 PM, Paul Moore wrote:
> On Wed, Sep 7, 2022 at 12:42 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/7/2022 7:41 AM, Paul Moore wrote:
>>> On Tue, Sep 6, 2022 at 8:10 PM John Johansen
>>> <john.johansen@canonical.com> wrote:
>>>> On 9/6/22 16:24, Paul Moore wrote:
>>>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>> ..
>>>
>>>>> If you are running AppArmor on the host system and SELinux in a
>>>>> container you are likely going to have some *very* bizarre behavior as
>>>>> the SELinux policy you load in the container will apply to the entire
>>>>> system, including processes which started *before* the SELinux policy
>>>>> was loaded. While I understand the point you are trying to make, I
>>>>> don't believe the example you chose is going to work without a lot of
>>>>> other changes.
>>>> correct but the reverse does work ...
>>> Sure, that doesn't surprise me, but that isn't the example Casey brought up.
>> I said that I'm not sure how they go about doing Android on Ubuntu.
>> I brought it up because I've seen it.
> Addressed in the other portion of this thread, but the quick response
> here is: No, you were mistaken, that was not proper Android, SELinux
> was disabled.
>
>>> I'm sympathetic that this
>>> work has been going on for some time, but that is no reason to push
>>> through a bad design; look at the ACKs/reviews on the combined-label
>>> patches vs the others in the series, that's a pretty good indication
>>> that no one is really excited about that design.
>> The kernel developers aren't the consumers of these APIs. There
>> has been considerable feedback from system application developers
>> on the interfaces. This included dbus and systemd. Kernel developers
>> aren't interested in these APIs because they don't care one way or
>> the other. That, and as you are painfully aware, some of them are
>> really busy on their own projects.
> Yes, everyone is busy yet they found time to ACK/review the other
> patches in the patchset. I'm not buying the "busy" argument here.
>
> Yes, you are also correct in that the kernel devs are not likely to be
> the main consumers of any kernel/userspace API, but we do have to
> support these APIs and find ways to handle the inevitable misuse and
> abuse of these APIs. Further, while I do believe that you've talked
> to some application developers about the current proposed API, I'm
> reasonably confident that it isn't the only API they would be happy
> supporting in their applications.
>
> As far as kernel developers not being interested in these APIs, I
> think the recent conversation in this thread proves the exact opposite
> ;)
>
>> Am I really happy with the "hideous" format? Yeah, because it makes
>> the end user happy. Am I happy with interface_lsm? Other than the
>> name, which was the result of feedback, yes, because it in the
>> simplest way to accomplish the goal.
>>
>> I am curious about what you think is "bad" about the current design.
>> The interfaces aren't exciting. They don't need to be.
> I don't even know what an exciting interface would look like ... ?
io_uring? :)
> I
> just want an interface that is clearly defined, has reasonable
> capacity to be extended in the future as needed, and is easy(ish) to
> use and support over extended periods of time (both from a kernel and
> userspace perspective).
>
> The "smack_label\0apparmor_label\0selinux_label\0future_lsm_label\0"
> string interface is none of these things.
In this we disagree ....
> It is not clearly defined
> as it requires other interfaces to associate the labels with the
> correct LSMs.
The label follows the lsm name directly. What other association is required?
> It has no provision for extension beyond adding a new
> LSM.
I grant that. But the purpose of the format is to present LSM/context
pairs. What other information would make sense? We could add an "aux"
field, but that seems somewhat arbitrary.
> The ease-of-use quality is a bit subjective, but it does need
> another interface to use properly and it requires string parsing which
> history has shown to be an issue time and time again (although it is
> relatively simple here).
There was a lot of discussion regarding that. My proposed
apparmor="unconfined",smack="User" format was panned for those same reasons.
The nil byte format has been used elsewhere and suggested for that reason.
>
> Once again, the syscall example I tossed out was a quick strawman, but
> it had clearly separated and defined labels conveyed in data
> structures that didn't require string parsing to find the label
> associated with an LSM.
True, but it uses pointers internally and you can't do that in memory
you're sending up from the system. What comes from the syscall has to
look something like the nil byte format. The strawman would have to do
the same sort of parsing in userspace that you are objecting to.
> It was also self-contained in that no other
> interface was needed to interpret the results of the syscall (well,
> beyond the header file definitions I guess). Finally, it made use of
> flags and "reserved for future use" token values to allow for
> additional data to be conveyed in the future.
Can you describe potential flags or additional data? Planning for the future
is a good idea, but throwing fields on "just in case" seems contrary to
what I'm used to hearing from you.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-09-07 23:53 ` Casey Schaufler
0 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-07 23:53 UTC (permalink / raw)
To: Paul Moore
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On 9/7/2022 4:27 PM, Paul Moore wrote:
> On Wed, Sep 7, 2022 at 12:42 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/7/2022 7:41 AM, Paul Moore wrote:
>>> On Tue, Sep 6, 2022 at 8:10 PM John Johansen
>>> <john.johansen@canonical.com> wrote:
>>>> On 9/6/22 16:24, Paul Moore wrote:
>>>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>> ..
>>>
>>>>> If you are running AppArmor on the host system and SELinux in a
>>>>> container you are likely going to have some *very* bizarre behavior as
>>>>> the SELinux policy you load in the container will apply to the entire
>>>>> system, including processes which started *before* the SELinux policy
>>>>> was loaded. While I understand the point you are trying to make, I
>>>>> don't believe the example you chose is going to work without a lot of
>>>>> other changes.
>>>> correct but the reverse does work ...
>>> Sure, that doesn't surprise me, but that isn't the example Casey brought up.
>> I said that I'm not sure how they go about doing Android on Ubuntu.
>> I brought it up because I've seen it.
> Addressed in the other portion of this thread, but the quick response
> here is: No, you were mistaken, that was not proper Android, SELinux
> was disabled.
>
>>> I'm sympathetic that this
>>> work has been going on for some time, but that is no reason to push
>>> through a bad design; look at the ACKs/reviews on the combined-label
>>> patches vs the others in the series, that's a pretty good indication
>>> that no one is really excited about that design.
>> The kernel developers aren't the consumers of these APIs. There
>> has been considerable feedback from system application developers
>> on the interfaces. This included dbus and systemd. Kernel developers
>> aren't interested in these APIs because they don't care one way or
>> the other. That, and as you are painfully aware, some of them are
>> really busy on their own projects.
> Yes, everyone is busy yet they found time to ACK/review the other
> patches in the patchset. I'm not buying the "busy" argument here.
>
> Yes, you are also correct in that the kernel devs are not likely to be
> the main consumers of any kernel/userspace API, but we do have to
> support these APIs and find ways to handle the inevitable misuse and
> abuse of these APIs. Further, while I do believe that you've talked
> to some application developers about the current proposed API, I'm
> reasonably confident that it isn't the only API they would be happy
> supporting in their applications.
>
> As far as kernel developers not being interested in these APIs, I
> think the recent conversation in this thread proves the exact opposite
> ;)
>
>> Am I really happy with the "hideous" format? Yeah, because it makes
>> the end user happy. Am I happy with interface_lsm? Other than the
>> name, which was the result of feedback, yes, because it in the
>> simplest way to accomplish the goal.
>>
>> I am curious about what you think is "bad" about the current design.
>> The interfaces aren't exciting. They don't need to be.
> I don't even know what an exciting interface would look like ... ?
io_uring? :)
> I
> just want an interface that is clearly defined, has reasonable
> capacity to be extended in the future as needed, and is easy(ish) to
> use and support over extended periods of time (both from a kernel and
> userspace perspective).
>
> The "smack_label\0apparmor_label\0selinux_label\0future_lsm_label\0"
> string interface is none of these things.
In this we disagree ....
> It is not clearly defined
> as it requires other interfaces to associate the labels with the
> correct LSMs.
The label follows the lsm name directly. What other association is required?
> It has no provision for extension beyond adding a new
> LSM.
I grant that. But the purpose of the format is to present LSM/context
pairs. What other information would make sense? We could add an "aux"
field, but that seems somewhat arbitrary.
> The ease-of-use quality is a bit subjective, but it does need
> another interface to use properly and it requires string parsing which
> history has shown to be an issue time and time again (although it is
> relatively simple here).
There was a lot of discussion regarding that. My proposed
apparmor="unconfined",smack="User" format was panned for those same reasons.
The nil byte format has been used elsewhere and suggested for that reason.
>
> Once again, the syscall example I tossed out was a quick strawman, but
> it had clearly separated and defined labels conveyed in data
> structures that didn't require string parsing to find the label
> associated with an LSM.
True, but it uses pointers internally and you can't do that in memory
you're sending up from the system. What comes from the syscall has to
look something like the nil byte format. The strawman would have to do
the same sort of parsing in userspace that you are objecting to.
> It was also self-contained in that no other
> interface was needed to interpret the results of the syscall (well,
> beyond the header file definitions I guess). Finally, it made use of
> flags and "reserved for future use" token values to allow for
> additional data to be conveyed in the future.
Can you describe potential flags or additional data? Planning for the future
is a good idea, but throwing fields on "just in case" seems contrary to
what I'm used to hearing from you.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-07 23:53 ` Casey Schaufler
@ 2022-09-08 0:19 ` John Johansen
-1 siblings, 0 replies; 148+ messages in thread
From: John Johansen @ 2022-09-08 0:19 UTC (permalink / raw)
To: Casey Schaufler, Paul Moore
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook, SElinux list
On 9/7/22 16:53, Casey Schaufler wrote:
> On 9/7/2022 4:27 PM, Paul Moore wrote:
>> On Wed, Sep 7, 2022 at 12:42 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>> On 9/7/2022 7:41 AM, Paul Moore wrote:
>>>> On Tue, Sep 6, 2022 at 8:10 PM John Johansen
>>>> <john.johansen@canonical.com> wrote:
>>>>> On 9/6/22 16:24, Paul Moore wrote:
>>>>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>>>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>> ..
>>>>
>>>>>> If you are running AppArmor on the host system and SELinux in a
>>>>>> container you are likely going to have some *very* bizarre behavior as
>>>>>> the SELinux policy you load in the container will apply to the entire
>>>>>> system, including processes which started *before* the SELinux policy
>>>>>> was loaded. While I understand the point you are trying to make, I
>>>>>> don't believe the example you chose is going to work without a lot of
>>>>>> other changes.
>>>>> correct but the reverse does work ...
>>>> Sure, that doesn't surprise me, but that isn't the example Casey brought up.
>>> I said that I'm not sure how they go about doing Android on Ubuntu.
>>> I brought it up because I've seen it.
>> Addressed in the other portion of this thread, but the quick response
>> here is: No, you were mistaken, that was not proper Android, SELinux
>> was disabled.
>>
>>>> I'm sympathetic that this
>>>> work has been going on for some time, but that is no reason to push
>>>> through a bad design; look at the ACKs/reviews on the combined-label
>>>> patches vs the others in the series, that's a pretty good indication
>>>> that no one is really excited about that design.
>>> The kernel developers aren't the consumers of these APIs. There
>>> has been considerable feedback from system application developers
>>> on the interfaces. This included dbus and systemd. Kernel developers
>>> aren't interested in these APIs because they don't care one way or
>>> the other. That, and as you are painfully aware, some of them are
>>> really busy on their own projects.
>> Yes, everyone is busy yet they found time to ACK/review the other
>> patches in the patchset. I'm not buying the "busy" argument here.
>>
>> Yes, you are also correct in that the kernel devs are not likely to be
>> the main consumers of any kernel/userspace API, but we do have to
>> support these APIs and find ways to handle the inevitable misuse and
>> abuse of these APIs. Further, while I do believe that you've talked
>> to some application developers about the current proposed API, I'm
>> reasonably confident that it isn't the only API they would be happy
>> supporting in their applications.
>>
>> As far as kernel developers not being interested in these APIs, I
>> think the recent conversation in this thread proves the exact opposite
>> ;)
>>
>>> Am I really happy with the "hideous" format? Yeah, because it makes
>>> the end user happy. Am I happy with interface_lsm? Other than the
>>> name, which was the result of feedback, yes, because it in the
>>> simplest way to accomplish the goal.
>>>
>>> I am curious about what you think is "bad" about the current design.
>>> The interfaces aren't exciting. They don't need to be.
>> I don't even know what an exciting interface would look like ... ?
>
> io_uring? :)
>
>> I
>> just want an interface that is clearly defined, has reasonable
>> capacity to be extended in the future as needed, and is easy(ish) to
>> use and support over extended periods of time (both from a kernel and
>> userspace perspective).
>>
>> The "smack_label\0apparmor_label\0selinux_label\0future_lsm_label\0"
>> string interface is none of these things.
>
> In this we disagree ....
>
>> It is not clearly defined
>> as it requires other interfaces to associate the labels with the
>> correct LSMs.
>
> The label follows the lsm name directly. What other association is required?
>
its a serialized message format, with all the data in the message
instead of pointer to external memory. If you want nicer to handle
you wrap a lib around it, this is pretty common. That is why I don't
see it as that different from the syscall.
>> It has no provision for extension beyond adding a new
>> LSM.
>
> I grant that. But the purpose of the format is to present LSM/context
> pairs. What other information would make sense? We could add an "aux"
> field, but that seems somewhat arbitrary.
>
or you know a header that gives potential future, also potentially a
count, ...
>> The ease-of-use quality is a bit subjective, but it does need
>> another interface to use properly and it requires string parsing which
>> history has shown to be an issue time and time again (although it is
>> relatively simple here).
>
> There was a lot of discussion regarding that. My proposed
> apparmor="unconfined",smack="User" format was panned for those same reasons.
> The nil byte format has been used elsewhere and suggested for that reason.
>
At this level the lib provides the ease of use, but I think that is
what we are going to need with a syscall too, as marshalling variable
number/length data is always somewhat ugly.
>>
>> Once again, the syscall example I tossed out was a quick strawman, but
>> it had clearly separated and defined labels conveyed in data
>> structures that didn't require string parsing to find the label
>> associated with an LSM.
>
> True, but it uses pointers internally and you can't do that in memory
> you're sending up from the system. What comes from the syscall has to
Well you can, see the mess that is ioctl. The point being those internal
pointers are going to have to be mapped/copied and doing that is a mess
as well. Either way you want a common set of code to handle it. The
advantage of the syscall, from a userspace perspective, is that all the
code to handle the mapping is in the kernel.
The problem from kernel perspective is that multiple copies to/from
userspace have races. You have to make sure you have marshalled/setup
all the data before you can do anything with it.
> look something like the nil byte format. The strawman would have to do
> the same sort of parsing in userspace that you are objecting to.
>
Not necessarily the nil byte format, but yeah it all has to be setup
nicely in advance.
>> It was also self-contained in that no other
>> interface was needed to interpret the results of the syscall (well,
>> beyond the header file definitions I guess). Finally, it made use of
>> flags and "reserved for future use" token values to allow for
>> additional data to be conveyed in the future.
>
> Can you describe potential flags or additional data? Planning for the future
> is a good idea, but throwing fields on "just in case" seems contrary to
> what I'm used to hearing from you.
>
Well a few potential ones I can think of
version - providing future flexibility
count - for how many lsm entries to expect
size - I don't think its really necessary here but in a message format it is
usually good to have a size of message value.
kind - some flags indicating the type of data. Eg. LSM name, LSM context pair
table - not necessary unless we want to get rid of the \0 separator so
that \0 could be allowed as value within the data, an index into
the message for each LSMs
data.
At this point I don't really care if its a syscall or a serialized message.
I see them as roughly equivalent, its just a matter of where you are going to
put the ugly.
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
@ 2022-09-08 0:19 ` John Johansen
0 siblings, 0 replies; 148+ messages in thread
From: John Johansen @ 2022-09-08 0:19 UTC (permalink / raw)
To: Casey Schaufler, Paul Moore
Cc: SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On 9/7/22 16:53, Casey Schaufler wrote:
> On 9/7/2022 4:27 PM, Paul Moore wrote:
>> On Wed, Sep 7, 2022 at 12:42 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>> On 9/7/2022 7:41 AM, Paul Moore wrote:
>>>> On Tue, Sep 6, 2022 at 8:10 PM John Johansen
>>>> <john.johansen@canonical.com> wrote:
>>>>> On 9/6/22 16:24, Paul Moore wrote:
>>>>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>>>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>> ..
>>>>
>>>>>> If you are running AppArmor on the host system and SELinux in a
>>>>>> container you are likely going to have some *very* bizarre behavior as
>>>>>> the SELinux policy you load in the container will apply to the entire
>>>>>> system, including processes which started *before* the SELinux policy
>>>>>> was loaded. While I understand the point you are trying to make, I
>>>>>> don't believe the example you chose is going to work without a lot of
>>>>>> other changes.
>>>>> correct but the reverse does work ...
>>>> Sure, that doesn't surprise me, but that isn't the example Casey brought up.
>>> I said that I'm not sure how they go about doing Android on Ubuntu.
>>> I brought it up because I've seen it.
>> Addressed in the other portion of this thread, but the quick response
>> here is: No, you were mistaken, that was not proper Android, SELinux
>> was disabled.
>>
>>>> I'm sympathetic that this
>>>> work has been going on for some time, but that is no reason to push
>>>> through a bad design; look at the ACKs/reviews on the combined-label
>>>> patches vs the others in the series, that's a pretty good indication
>>>> that no one is really excited about that design.
>>> The kernel developers aren't the consumers of these APIs. There
>>> has been considerable feedback from system application developers
>>> on the interfaces. This included dbus and systemd. Kernel developers
>>> aren't interested in these APIs because they don't care one way or
>>> the other. That, and as you are painfully aware, some of them are
>>> really busy on their own projects.
>> Yes, everyone is busy yet they found time to ACK/review the other
>> patches in the patchset. I'm not buying the "busy" argument here.
>>
>> Yes, you are also correct in that the kernel devs are not likely to be
>> the main consumers of any kernel/userspace API, but we do have to
>> support these APIs and find ways to handle the inevitable misuse and
>> abuse of these APIs. Further, while I do believe that you've talked
>> to some application developers about the current proposed API, I'm
>> reasonably confident that it isn't the only API they would be happy
>> supporting in their applications.
>>
>> As far as kernel developers not being interested in these APIs, I
>> think the recent conversation in this thread proves the exact opposite
>> ;)
>>
>>> Am I really happy with the "hideous" format? Yeah, because it makes
>>> the end user happy. Am I happy with interface_lsm? Other than the
>>> name, which was the result of feedback, yes, because it in the
>>> simplest way to accomplish the goal.
>>>
>>> I am curious about what you think is "bad" about the current design.
>>> The interfaces aren't exciting. They don't need to be.
>> I don't even know what an exciting interface would look like ... ?
>
> io_uring? :)
>
>> I
>> just want an interface that is clearly defined, has reasonable
>> capacity to be extended in the future as needed, and is easy(ish) to
>> use and support over extended periods of time (both from a kernel and
>> userspace perspective).
>>
>> The "smack_label\0apparmor_label\0selinux_label\0future_lsm_label\0"
>> string interface is none of these things.
>
> In this we disagree ....
>
>> It is not clearly defined
>> as it requires other interfaces to associate the labels with the
>> correct LSMs.
>
> The label follows the lsm name directly. What other association is required?
>
its a serialized message format, with all the data in the message
instead of pointer to external memory. If you want nicer to handle
you wrap a lib around it, this is pretty common. That is why I don't
see it as that different from the syscall.
>> It has no provision for extension beyond adding a new
>> LSM.
>
> I grant that. But the purpose of the format is to present LSM/context
> pairs. What other information would make sense? We could add an "aux"
> field, but that seems somewhat arbitrary.
>
or you know a header that gives potential future, also potentially a
count, ...
>> The ease-of-use quality is a bit subjective, but it does need
>> another interface to use properly and it requires string parsing which
>> history has shown to be an issue time and time again (although it is
>> relatively simple here).
>
> There was a lot of discussion regarding that. My proposed
> apparmor="unconfined",smack="User" format was panned for those same reasons.
> The nil byte format has been used elsewhere and suggested for that reason.
>
At this level the lib provides the ease of use, but I think that is
what we are going to need with a syscall too, as marshalling variable
number/length data is always somewhat ugly.
>>
>> Once again, the syscall example I tossed out was a quick strawman, but
>> it had clearly separated and defined labels conveyed in data
>> structures that didn't require string parsing to find the label
>> associated with an LSM.
>
> True, but it uses pointers internally and you can't do that in memory
> you're sending up from the system. What comes from the syscall has to
Well you can, see the mess that is ioctl. The point being those internal
pointers are going to have to be mapped/copied and doing that is a mess
as well. Either way you want a common set of code to handle it. The
advantage of the syscall, from a userspace perspective, is that all the
code to handle the mapping is in the kernel.
The problem from kernel perspective is that multiple copies to/from
userspace have races. You have to make sure you have marshalled/setup
all the data before you can do anything with it.
> look something like the nil byte format. The strawman would have to do
> the same sort of parsing in userspace that you are objecting to.
>
Not necessarily the nil byte format, but yeah it all has to be setup
nicely in advance.
>> It was also self-contained in that no other
>> interface was needed to interpret the results of the syscall (well,
>> beyond the header file definitions I guess). Finally, it made use of
>> flags and "reserved for future use" token values to allow for
>> additional data to be conveyed in the future.
>
> Can you describe potential flags or additional data? Planning for the future
> is a good idea, but throwing fields on "just in case" seems contrary to
> what I'm used to hearing from you.
>
Well a few potential ones I can think of
version - providing future flexibility
count - for how many lsm entries to expect
size - I don't think its really necessary here but in a message format it is
usually good to have a size of message value.
kind - some flags indicating the type of data. Eg. LSM name, LSM context pair
table - not necessary unless we want to get rid of the \0 separator so
that \0 could be allowed as value within the data, an index into
the message for each LSMs
data.
At this point I don't really care if its a syscall or a serialized message.
I see them as roughly equivalent, its just a matter of where you are going to
put the ugly.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-07 23:53 ` Casey Schaufler
@ 2022-09-08 3:57 ` Paul Moore
-1 siblings, 0 replies; 148+ messages in thread
From: Paul Moore @ 2022-09-08 3:57 UTC (permalink / raw)
To: Casey Schaufler
Cc: John Johansen, LSM List, James Morris, linux-audit, Mimi Zohar,
keescook, SElinux list
On Wed, Sep 7, 2022 at 7:53 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 9/7/2022 4:27 PM, Paul Moore wrote:
...
> > I
> > just want an interface that is clearly defined, has reasonable
> > capacity to be extended in the future as needed, and is easy(ish) to
> > use and support over extended periods of time (both from a kernel and
> > userspace perspective).
> >
> > The "smack_label\0apparmor_label\0selinux_label\0future_lsm_label\0"
> > string interface is none of these things.
>
> In this we disagree ....
I think we can both agree that there is a subjective aspect to this
argument and it may be that we never reach agreement on the "best"
approach, if there even is such a thing. What I am trying to do here
is describe a path that would allow me to be more comfortable merging
the LSM stacking functionality; I don't think you've had a clearly
defined path, of any sort, towards getting these patches merged, which
is a problem and I suspect the source of some of the frustration. My
comments, as objectionable as you may find them to be, are intended to
help you move forward with these patches.
> > It is not clearly defined
> > as it requires other interfaces to associate the labels with the
> > correct LSMs.
>
> The label follows the lsm name directly. What other association is required?
You need to know the order of the LSMs in order to
interpret/de-serialize the string.
> > The ease-of-use quality is a bit subjective, but it does need
> > another interface to use properly and it requires string parsing which
> > history has shown to be an issue time and time again (although it is
> > relatively simple here).
>
> There was a lot of discussion regarding that. My proposed
> apparmor="unconfined",smack="User" format was panned for those same reasons.
> The nil byte format has been used elsewhere and suggested for that reason.
Based on what I recall from those discussions, it was my impression
the nil byte label delimiter was suggested simply because no one was
entertaining the idea of using something other than the existing
procfs interface. It is my opinion that we've taken that interface
about as far as it can go, and while it needs to stay intact for
compatibility reasons, the LSM stacking functionality should move to a
different API that is better suited for it.
> > Once again, the syscall example I tossed out was a quick strawman, but
> > it had clearly separated and defined labels conveyed in data
> > structures that didn't require string parsing to find the label
> > associated with an LSM.
>
> True, but it uses pointers internally and you can't do that in memory
> you're sending up from the system. What comes from the syscall has to
> look something like the nil byte format. The strawman would have to do
> the same sort of parsing in userspace that you are objecting to.
Then we change the strawman. That's pretty much the definition of a
strawman example, it's something you toss out as starting point for
discussion and future improvements. If it was something much more
fully developed I would have submitted a patch .... sheesh.
In case it helps spur your imagination, here is a revised strawman:
/**
* struct lsm_ctx - LSM context
* @id: the LSM id number, see LSM_ID_XXX
* @flags: LSM specific flags, zero if unused
* @ctx_len: the size of @ctx
* @ctx: the LSM context
*/
struct lsm_ctx {
unsigned in id;
unsigned int flags;
size_t ctx_len;
unsigned char ctx[];
};
/**
* lsm_current_ctx - Return current tasks's LSM context
* @ctx: the LSM contexts
* @size: the size of @ctx, updated on return
* @flags: reserved for future use, must be zero
*
* Returns the calling task's LSM contexts. On success this
* function returns a positive number representing the number of
* @ctx array elements, which may be zero if there are no LSM
* contexts assigned to the caller. If the size of @ctx is
* insufficient, -E2BIG is returned and the minimum required
* size is returned via @count. In all other failure cases, a
* negative value indicating the error is returned.
*/
int lsm_current_ctx(struct lsm_ctx *ctx, size_t *size,
unsigned int flags);
> > It was also self-contained in that no other
> > interface was needed to interpret the results of the syscall (well,
> > beyond the header file definitions I guess). Finally, it made use of
> > flags and "reserved for future use" token values to allow for
> > additional data to be conveyed in the future.
>
> Can you describe potential flags or additional data? Planning for the future
> is a good idea, but throwing fields on "just in case" seems contrary to
> what I'm used to hearing from you.
Adding flags to a syscall is a fairly common practice. If you're
making the mistake of confusing this with the discussion that is
ongoing audit/fanotify discussion, you can think of the flags as
similar to adding a type/length field to a struct (which I support).
--
paul-moore.com
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
@ 2022-09-08 3:57 ` Paul Moore
0 siblings, 0 replies; 148+ messages in thread
From: Paul Moore @ 2022-09-08 3:57 UTC (permalink / raw)
To: Casey Schaufler
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On Wed, Sep 7, 2022 at 7:53 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 9/7/2022 4:27 PM, Paul Moore wrote:
...
> > I
> > just want an interface that is clearly defined, has reasonable
> > capacity to be extended in the future as needed, and is easy(ish) to
> > use and support over extended periods of time (both from a kernel and
> > userspace perspective).
> >
> > The "smack_label\0apparmor_label\0selinux_label\0future_lsm_label\0"
> > string interface is none of these things.
>
> In this we disagree ....
I think we can both agree that there is a subjective aspect to this
argument and it may be that we never reach agreement on the "best"
approach, if there even is such a thing. What I am trying to do here
is describe a path that would allow me to be more comfortable merging
the LSM stacking functionality; I don't think you've had a clearly
defined path, of any sort, towards getting these patches merged, which
is a problem and I suspect the source of some of the frustration. My
comments, as objectionable as you may find them to be, are intended to
help you move forward with these patches.
> > It is not clearly defined
> > as it requires other interfaces to associate the labels with the
> > correct LSMs.
>
> The label follows the lsm name directly. What other association is required?
You need to know the order of the LSMs in order to
interpret/de-serialize the string.
> > The ease-of-use quality is a bit subjective, but it does need
> > another interface to use properly and it requires string parsing which
> > history has shown to be an issue time and time again (although it is
> > relatively simple here).
>
> There was a lot of discussion regarding that. My proposed
> apparmor="unconfined",smack="User" format was panned for those same reasons.
> The nil byte format has been used elsewhere and suggested for that reason.
Based on what I recall from those discussions, it was my impression
the nil byte label delimiter was suggested simply because no one was
entertaining the idea of using something other than the existing
procfs interface. It is my opinion that we've taken that interface
about as far as it can go, and while it needs to stay intact for
compatibility reasons, the LSM stacking functionality should move to a
different API that is better suited for it.
> > Once again, the syscall example I tossed out was a quick strawman, but
> > it had clearly separated and defined labels conveyed in data
> > structures that didn't require string parsing to find the label
> > associated with an LSM.
>
> True, but it uses pointers internally and you can't do that in memory
> you're sending up from the system. What comes from the syscall has to
> look something like the nil byte format. The strawman would have to do
> the same sort of parsing in userspace that you are objecting to.
Then we change the strawman. That's pretty much the definition of a
strawman example, it's something you toss out as starting point for
discussion and future improvements. If it was something much more
fully developed I would have submitted a patch .... sheesh.
In case it helps spur your imagination, here is a revised strawman:
/**
* struct lsm_ctx - LSM context
* @id: the LSM id number, see LSM_ID_XXX
* @flags: LSM specific flags, zero if unused
* @ctx_len: the size of @ctx
* @ctx: the LSM context
*/
struct lsm_ctx {
unsigned in id;
unsigned int flags;
size_t ctx_len;
unsigned char ctx[];
};
/**
* lsm_current_ctx - Return current tasks's LSM context
* @ctx: the LSM contexts
* @size: the size of @ctx, updated on return
* @flags: reserved for future use, must be zero
*
* Returns the calling task's LSM contexts. On success this
* function returns a positive number representing the number of
* @ctx array elements, which may be zero if there are no LSM
* contexts assigned to the caller. If the size of @ctx is
* insufficient, -E2BIG is returned and the minimum required
* size is returned via @count. In all other failure cases, a
* negative value indicating the error is returned.
*/
int lsm_current_ctx(struct lsm_ctx *ctx, size_t *size,
unsigned int flags);
> > It was also self-contained in that no other
> > interface was needed to interpret the results of the syscall (well,
> > beyond the header file definitions I guess). Finally, it made use of
> > flags and "reserved for future use" token values to allow for
> > additional data to be conveyed in the future.
>
> Can you describe potential flags or additional data? Planning for the future
> is a good idea, but throwing fields on "just in case" seems contrary to
> what I'm used to hearing from you.
Adding flags to a syscall is a fairly common practice. If you're
making the mistake of confusing this with the discussion that is
ongoing audit/fanotify discussion, you can think of the flags as
similar to adding a type/length field to a struct (which I support).
--
paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
2022-09-08 3:57 ` Paul Moore
@ 2022-09-08 18:05 ` Casey Schaufler
-1 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-08 18:05 UTC (permalink / raw)
To: Paul Moore
Cc: John Johansen, LSM List, James Morris, linux-audit, Mimi Zohar,
keescook, SElinux list, casey
On 9/7/2022 8:57 PM, Paul Moore wrote:
> On Wed, Sep 7, 2022 at 7:53 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/7/2022 4:27 PM, Paul Moore wrote:
> ..
>
>>> I
>>> just want an interface that is clearly defined, has reasonable
>>> capacity to be extended in the future as needed, and is easy(ish) to
>>> use and support over extended periods of time (both from a kernel and
>>> userspace perspective).
>>>
>>> The "smack_label\0apparmor_label\0selinux_label\0future_lsm_label\0"
>>> string interface is none of these things.
That wasn't the proposal. The proposal was
"smack\0smack_label\0apparmor\0apparmor_label\0future_lsm\0future_lsm_label\0"
>> In this we disagree ....
> I think we can both agree that there is a subjective aspect to this
> argument and it may be that we never reach agreement on the "best"
> approach, if there even is such a thing. What I am trying to do here
> is describe a path that would allow me to be more comfortable merging
> the LSM stacking functionality; I don't think you've had a clearly
> defined path, of any sort, towards getting these patches merged, which
> is a problem and I suspect the source of some of the frustration. My
> comments, as objectionable as you may find them to be, are intended to
> help you move forward with these patches.
OK. Let's get'er done.
>>> It is not clearly defined
>>> as it requires other interfaces to associate the labels with the
>>> correct LSMs.
>> The label follows the lsm name directly. What other association is required?
> You need to know the order of the LSMs in order to
> interpret/de-serialize the string.
That's true for the string you included, but not for what I had
actually proposed.
>>> The ease-of-use quality is a bit subjective, but it does need
>>> another interface to use properly and it requires string parsing which
>>> history has shown to be an issue time and time again (although it is
>>> relatively simple here).
>> There was a lot of discussion regarding that. My proposed
>> apparmor="unconfined",smack="User" format was panned for those same reasons.
>> The nil byte format has been used elsewhere and suggested for that reason.
> Based on what I recall from those discussions, it was my impression
> the nil byte label delimiter was suggested simply because no one was
> entertaining the idea of using something other than the existing
> procfs interface. It is my opinion that we've taken that interface
> about as far as it can go, and while it needs to stay intact for
> compatibility reasons, the LSM stacking functionality should move to a
> different API that is better suited for it.
It's going to raise its ugly head again with SO_PEERCONTEXT for the
SELinux+Smack case. But we can cross that bridge when we come to it.
>>> Once again, the syscall example I tossed out was a quick strawman, but
>>> it had clearly separated and defined labels conveyed in data
>>> structures that didn't require string parsing to find the label
>>> associated with an LSM.
>> True, but it uses pointers internally and you can't do that in memory
>> you're sending up from the system. What comes from the syscall has to
>> look something like the nil byte format. The strawman would have to do
>> the same sort of parsing in userspace that you are objecting to.
> Then we change the strawman. That's pretty much the definition of a
> strawman example, it's something you toss out as starting point for
> discussion and future improvements. If it was something much more
> fully developed I would have submitted a patch .... sheesh.
Fair enough.
> In case it helps spur your imagination, here is a revised strawman:
>
> /**
> * struct lsm_ctx - LSM context
> * @id: the LSM id number, see LSM_ID_XXX
A LSM ID hard coded in a kernel header makes it harder to develop new
security modules. The security module can't be self contained. I say
that, but I acknowledge that I've done the same kind of thing with the
definition of the struct lsmblob. That isn't part of an external API
however. It may also interfere with Tetsuo's long standing request that
we don't do things that prevent the possibility of loadable security
modules at some point in the future. I will also mention the out-of-tree
security module objection, not because I care, but because someone most
likely will bring it up.
On the other hand, there's no great way to include two variable length
strings in a structure like this. So unless we adopt something as ugly
as the nil byte scheme this is supposed to replace I expect we're stuck
with an LSM ID.
>
> * @flags: LSM specific flags, zero if unused
For an API shouldn't this be a specific size? u32? I'm not really
up to date on the guidance regarding which it should be.
> * @ctx_len: the size of @ctx
> * @ctx: the LSM context
> */
> struct lsm_ctx {
> unsigned in id;
> unsigned int flags;
> size_t ctx_len;
> unsigned char ctx[];
> };
>
> /**
> * lsm_current_ctx - Return current tasks's LSM context
> * @ctx: the LSM contexts
> * @size: the size of @ctx, updated on return
> * @flags: reserved for future use, must be zero
> *
> * Returns the calling task's LSM contexts. On success this
> * function returns a positive number representing the number of
> * @ctx array elements, which may be zero if there are no LSM
> * contexts assigned to the caller. If the size of @ctx is
> * insufficient, -E2BIG is returned and the minimum required
> * size is returned via @count. In all other failure cases, a
s/count/size/ - but I get what you meant.
> * negative value indicating the error is returned.
> */
> int lsm_current_ctx(struct lsm_ctx *ctx, size_t *size,
> unsigned int flags);
This is a workable interface. Certainly more friendly than the
nil byte format.
> It was also self-contained in that no other
> interface was needed to interpret the results of the syscall (well,
> beyond the header file definitions I guess). Finally, it made use of
> flags and "reserved for future use" token values to allow for
> additional data to be conveyed in the future.
>> Can you describe potential flags or additional data? Planning for the future
>> is a good idea, but throwing fields on "just in case" seems contrary to
>> what I'm used to hearing from you.
> Adding flags to a syscall is a fairly common practice. If you're
> making the mistake of confusing this with the discussion that is
> ongoing audit/fanotify discussion, you can think of the flags as
> similar to adding a type/length field to a struct (which I support).
OK. I can see potential.
I will head in this direction. A couple questions:
Would we want lsm_prev_ctx() as well as lsm_current_ctx(),
or should we use the lsm_ctx->flags to identify the provided
context? If we did that we should have an lsm_ctx() system call
that returns the current, prev, and whatever other security
module specific attributes might be associated with the process,
each identified in the flags field. While the "current" context
is usually what we're after, there may be cases where the other
attributes are desired.
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
@ 2022-09-08 18:05 ` Casey Schaufler
0 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-08 18:05 UTC (permalink / raw)
To: Paul Moore
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On 9/7/2022 8:57 PM, Paul Moore wrote:
> On Wed, Sep 7, 2022 at 7:53 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/7/2022 4:27 PM, Paul Moore wrote:
> ..
>
>>> I
>>> just want an interface that is clearly defined, has reasonable
>>> capacity to be extended in the future as needed, and is easy(ish) to
>>> use and support over extended periods of time (both from a kernel and
>>> userspace perspective).
>>>
>>> The "smack_label\0apparmor_label\0selinux_label\0future_lsm_label\0"
>>> string interface is none of these things.
That wasn't the proposal. The proposal was
"smack\0smack_label\0apparmor\0apparmor_label\0future_lsm\0future_lsm_label\0"
>> In this we disagree ....
> I think we can both agree that there is a subjective aspect to this
> argument and it may be that we never reach agreement on the "best"
> approach, if there even is such a thing. What I am trying to do here
> is describe a path that would allow me to be more comfortable merging
> the LSM stacking functionality; I don't think you've had a clearly
> defined path, of any sort, towards getting these patches merged, which
> is a problem and I suspect the source of some of the frustration. My
> comments, as objectionable as you may find them to be, are intended to
> help you move forward with these patches.
OK. Let's get'er done.
>>> It is not clearly defined
>>> as it requires other interfaces to associate the labels with the
>>> correct LSMs.
>> The label follows the lsm name directly. What other association is required?
> You need to know the order of the LSMs in order to
> interpret/de-serialize the string.
That's true for the string you included, but not for what I had
actually proposed.
>>> The ease-of-use quality is a bit subjective, but it does need
>>> another interface to use properly and it requires string parsing which
>>> history has shown to be an issue time and time again (although it is
>>> relatively simple here).
>> There was a lot of discussion regarding that. My proposed
>> apparmor="unconfined",smack="User" format was panned for those same reasons.
>> The nil byte format has been used elsewhere and suggested for that reason.
> Based on what I recall from those discussions, it was my impression
> the nil byte label delimiter was suggested simply because no one was
> entertaining the idea of using something other than the existing
> procfs interface. It is my opinion that we've taken that interface
> about as far as it can go, and while it needs to stay intact for
> compatibility reasons, the LSM stacking functionality should move to a
> different API that is better suited for it.
It's going to raise its ugly head again with SO_PEERCONTEXT for the
SELinux+Smack case. But we can cross that bridge when we come to it.
>>> Once again, the syscall example I tossed out was a quick strawman, but
>>> it had clearly separated and defined labels conveyed in data
>>> structures that didn't require string parsing to find the label
>>> associated with an LSM.
>> True, but it uses pointers internally and you can't do that in memory
>> you're sending up from the system. What comes from the syscall has to
>> look something like the nil byte format. The strawman would have to do
>> the same sort of parsing in userspace that you are objecting to.
> Then we change the strawman. That's pretty much the definition of a
> strawman example, it's something you toss out as starting point for
> discussion and future improvements. If it was something much more
> fully developed I would have submitted a patch .... sheesh.
Fair enough.
> In case it helps spur your imagination, here is a revised strawman:
>
> /**
> * struct lsm_ctx - LSM context
> * @id: the LSM id number, see LSM_ID_XXX
A LSM ID hard coded in a kernel header makes it harder to develop new
security modules. The security module can't be self contained. I say
that, but I acknowledge that I've done the same kind of thing with the
definition of the struct lsmblob. That isn't part of an external API
however. It may also interfere with Tetsuo's long standing request that
we don't do things that prevent the possibility of loadable security
modules at some point in the future. I will also mention the out-of-tree
security module objection, not because I care, but because someone most
likely will bring it up.
On the other hand, there's no great way to include two variable length
strings in a structure like this. So unless we adopt something as ugly
as the nil byte scheme this is supposed to replace I expect we're stuck
with an LSM ID.
>
> * @flags: LSM specific flags, zero if unused
For an API shouldn't this be a specific size? u32? I'm not really
up to date on the guidance regarding which it should be.
> * @ctx_len: the size of @ctx
> * @ctx: the LSM context
> */
> struct lsm_ctx {
> unsigned in id;
> unsigned int flags;
> size_t ctx_len;
> unsigned char ctx[];
> };
>
> /**
> * lsm_current_ctx - Return current tasks's LSM context
> * @ctx: the LSM contexts
> * @size: the size of @ctx, updated on return
> * @flags: reserved for future use, must be zero
> *
> * Returns the calling task's LSM contexts. On success this
> * function returns a positive number representing the number of
> * @ctx array elements, which may be zero if there are no LSM
> * contexts assigned to the caller. If the size of @ctx is
> * insufficient, -E2BIG is returned and the minimum required
> * size is returned via @count. In all other failure cases, a
s/count/size/ - but I get what you meant.
> * negative value indicating the error is returned.
> */
> int lsm_current_ctx(struct lsm_ctx *ctx, size_t *size,
> unsigned int flags);
This is a workable interface. Certainly more friendly than the
nil byte format.
> It was also self-contained in that no other
> interface was needed to interpret the results of the syscall (well,
> beyond the header file definitions I guess). Finally, it made use of
> flags and "reserved for future use" token values to allow for
> additional data to be conveyed in the future.
>> Can you describe potential flags or additional data? Planning for the future
>> is a good idea, but throwing fields on "just in case" seems contrary to
>> what I'm used to hearing from you.
> Adding flags to a syscall is a fairly common practice. If you're
> making the mistake of confusing this with the discussion that is
> ongoing audit/fanotify discussion, you can think of the flags as
> similar to adding a type/length field to a struct (which I support).
OK. I can see potential.
I will head in this direction. A couple questions:
Would we want lsm_prev_ctx() as well as lsm_current_ctx(),
or should we use the lsm_ctx->flags to identify the provided
context? If we did that we should have an lsm_ctx() system call
that returns the current, prev, and whatever other security
module specific attributes might be associated with the process,
each identified in the flags field. While the "current" context
is usually what we're after, there may be cases where the other
attributes are desired.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
2022-09-08 18:05 ` Casey Schaufler
@ 2022-09-08 18:35 ` John Johansen
-1 siblings, 0 replies; 148+ messages in thread
From: John Johansen @ 2022-09-08 18:35 UTC (permalink / raw)
To: Casey Schaufler, Paul Moore
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook, SElinux list
On 9/8/22 11:05, Casey Schaufler wrote:
> On 9/7/2022 8:57 PM, Paul Moore wrote:
>> On Wed, Sep 7, 2022 at 7:53 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>> On 9/7/2022 4:27 PM, Paul Moore wrote:
>> ..
>>
>>>> I
>>>> just want an interface that is clearly defined, has reasonable
>>>> capacity to be extended in the future as needed, and is easy(ish) to
>>>> use and support over extended periods of time (both from a kernel and
>>>> userspace perspective).
>>>>
>>>> The "smack_label\0apparmor_label\0selinux_label\0future_lsm_label\0"
>>>> string interface is none of these things.
>
> That wasn't the proposal. The proposal was
>
> "smack\0smack_label\0apparmor\0apparmor_label\0future_lsm\0future_lsm_label\0"
>
>>> In this we disagree ....
>> I think we can both agree that there is a subjective aspect to this
>> argument and it may be that we never reach agreement on the "best"
>> approach, if there even is such a thing. What I am trying to do here
>> is describe a path that would allow me to be more comfortable merging
>> the LSM stacking functionality; I don't think you've had a clearly
>> defined path, of any sort, towards getting these patches merged, which
>> is a problem and I suspect the source of some of the frustration. My
>> comments, as objectionable as you may find them to be, are intended to
>> help you move forward with these patches.
>
> OK. Let's get'er done.
>
>>>> It is not clearly defined
>>>> as it requires other interfaces to associate the labels with the
>>>> correct LSMs.
>>> The label follows the lsm name directly. What other association is required?
>> You need to know the order of the LSMs in order to
>> interpret/de-serialize the string.
>
> That's true for the string you included, but not for what I had
> actually proposed.
>
>>>> The ease-of-use quality is a bit subjective, but it does need
>>>> another interface to use properly and it requires string parsing which
>>>> history has shown to be an issue time and time again (although it is
>>>> relatively simple here).
>>> There was a lot of discussion regarding that. My proposed
>>> apparmor="unconfined",smack="User" format was panned for those same reasons.
>>> The nil byte format has been used elsewhere and suggested for that reason.
>> Based on what I recall from those discussions, it was my impression
>> the nil byte label delimiter was suggested simply because no one was
>> entertaining the idea of using something other than the existing
>> procfs interface. It is my opinion that we've taken that interface
>> about as far as it can go, and while it needs to stay intact for
>> compatibility reasons, the LSM stacking functionality should move to a
>> different API that is better suited for it.
>
> It's going to raise its ugly head again with SO_PEERCONTEXT for the
> SELinux+Smack case. But we can cross that bridge when we come to it.
>
AppArmor too, I am working on revising the out of tree af_unix mediation
>>>> Once again, the syscall example I tossed out was a quick strawman, but
>>>> it had clearly separated and defined labels conveyed in data
>>>> structures that didn't require string parsing to find the label
>>>> associated with an LSM.
>>> True, but it uses pointers internally and you can't do that in memory
>>> you're sending up from the system. What comes from the syscall has to
>>> look something like the nil byte format. The strawman would have to do
>>> the same sort of parsing in userspace that you are objecting to.
>> Then we change the strawman. That's pretty much the definition of a
>> strawman example, it's something you toss out as starting point for
>> discussion and future improvements. If it was something much more
>> fully developed I would have submitted a patch .... sheesh.
>
> Fair enough.
>
>> In case it helps spur your imagination, here is a revised strawman:
>>
>> /**
>> * struct lsm_ctx - LSM context
>> * @id: the LSM id number, see LSM_ID_XXX
>
> A LSM ID hard coded in a kernel header makes it harder to develop new
> security modules. The security module can't be self contained. I say
> that, but I acknowledge that I've done the same kind of thing with the
> definition of the struct lsmblob. That isn't part of an external API
> however. It may also interfere with Tetsuo's long standing request that
> we don't do things that prevent the possibility of loadable security
> modules at some point in the future. I will also mention the out-of-tree
> security module objection, not because I care, but because someone most
> likely will bring it up.
>
> On the other hand, there's no great way to include two variable length
> strings in a structure like this. So unless we adopt something as ugly
> as the nil byte scheme this is supposed to replace I expect we're stuck
> with an LSM ID.
>
well at a minimum we shouldn't export the kernel internal LSM_ID if its
exposed to userspace it needs to be something that can live with for a
long time
- Fixed length strings, which really are just a long LSM ID, Say 8 bytes.
Can still even look human readable. For most* LSMs this could just
be their name.
* only safesetid and capability don't fit atm
- and certainly uglier, for variable length use an index for one of the
variable length strings, with an embedded \0 inside the variable length
string
{
size_t lsm_id_len;
size_t lsm_id_ctx_index;
size_t ctx_len;
unsigned char ctx[];
}
with access to lsm id being ctx[lsm_id_ctx_index]
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
@ 2022-09-08 18:35 ` John Johansen
0 siblings, 0 replies; 148+ messages in thread
From: John Johansen @ 2022-09-08 18:35 UTC (permalink / raw)
To: Casey Schaufler, Paul Moore
Cc: SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On 9/8/22 11:05, Casey Schaufler wrote:
> On 9/7/2022 8:57 PM, Paul Moore wrote:
>> On Wed, Sep 7, 2022 at 7:53 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>> On 9/7/2022 4:27 PM, Paul Moore wrote:
>> ..
>>
>>>> I
>>>> just want an interface that is clearly defined, has reasonable
>>>> capacity to be extended in the future as needed, and is easy(ish) to
>>>> use and support over extended periods of time (both from a kernel and
>>>> userspace perspective).
>>>>
>>>> The "smack_label\0apparmor_label\0selinux_label\0future_lsm_label\0"
>>>> string interface is none of these things.
>
> That wasn't the proposal. The proposal was
>
> "smack\0smack_label\0apparmor\0apparmor_label\0future_lsm\0future_lsm_label\0"
>
>>> In this we disagree ....
>> I think we can both agree that there is a subjective aspect to this
>> argument and it may be that we never reach agreement on the "best"
>> approach, if there even is such a thing. What I am trying to do here
>> is describe a path that would allow me to be more comfortable merging
>> the LSM stacking functionality; I don't think you've had a clearly
>> defined path, of any sort, towards getting these patches merged, which
>> is a problem and I suspect the source of some of the frustration. My
>> comments, as objectionable as you may find them to be, are intended to
>> help you move forward with these patches.
>
> OK. Let's get'er done.
>
>>>> It is not clearly defined
>>>> as it requires other interfaces to associate the labels with the
>>>> correct LSMs.
>>> The label follows the lsm name directly. What other association is required?
>> You need to know the order of the LSMs in order to
>> interpret/de-serialize the string.
>
> That's true for the string you included, but not for what I had
> actually proposed.
>
>>>> The ease-of-use quality is a bit subjective, but it does need
>>>> another interface to use properly and it requires string parsing which
>>>> history has shown to be an issue time and time again (although it is
>>>> relatively simple here).
>>> There was a lot of discussion regarding that. My proposed
>>> apparmor="unconfined",smack="User" format was panned for those same reasons.
>>> The nil byte format has been used elsewhere and suggested for that reason.
>> Based on what I recall from those discussions, it was my impression
>> the nil byte label delimiter was suggested simply because no one was
>> entertaining the idea of using something other than the existing
>> procfs interface. It is my opinion that we've taken that interface
>> about as far as it can go, and while it needs to stay intact for
>> compatibility reasons, the LSM stacking functionality should move to a
>> different API that is better suited for it.
>
> It's going to raise its ugly head again with SO_PEERCONTEXT for the
> SELinux+Smack case. But we can cross that bridge when we come to it.
>
AppArmor too, I am working on revising the out of tree af_unix mediation
>>>> Once again, the syscall example I tossed out was a quick strawman, but
>>>> it had clearly separated and defined labels conveyed in data
>>>> structures that didn't require string parsing to find the label
>>>> associated with an LSM.
>>> True, but it uses pointers internally and you can't do that in memory
>>> you're sending up from the system. What comes from the syscall has to
>>> look something like the nil byte format. The strawman would have to do
>>> the same sort of parsing in userspace that you are objecting to.
>> Then we change the strawman. That's pretty much the definition of a
>> strawman example, it's something you toss out as starting point for
>> discussion and future improvements. If it was something much more
>> fully developed I would have submitted a patch .... sheesh.
>
> Fair enough.
>
>> In case it helps spur your imagination, here is a revised strawman:
>>
>> /**
>> * struct lsm_ctx - LSM context
>> * @id: the LSM id number, see LSM_ID_XXX
>
> A LSM ID hard coded in a kernel header makes it harder to develop new
> security modules. The security module can't be self contained. I say
> that, but I acknowledge that I've done the same kind of thing with the
> definition of the struct lsmblob. That isn't part of an external API
> however. It may also interfere with Tetsuo's long standing request that
> we don't do things that prevent the possibility of loadable security
> modules at some point in the future. I will also mention the out-of-tree
> security module objection, not because I care, but because someone most
> likely will bring it up.
>
> On the other hand, there's no great way to include two variable length
> strings in a structure like this. So unless we adopt something as ugly
> as the nil byte scheme this is supposed to replace I expect we're stuck
> with an LSM ID.
>
well at a minimum we shouldn't export the kernel internal LSM_ID if its
exposed to userspace it needs to be something that can live with for a
long time
- Fixed length strings, which really are just a long LSM ID, Say 8 bytes.
Can still even look human readable. For most* LSMs this could just
be their name.
* only safesetid and capability don't fit atm
- and certainly uglier, for variable length use an index for one of the
variable length strings, with an embedded \0 inside the variable length
string
{
size_t lsm_id_len;
size_t lsm_id_ctx_index;
size_t ctx_len;
unsigned char ctx[];
}
with access to lsm id being ctx[lsm_id_ctx_index]
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-08 18:05 ` Casey Schaufler
@ 2022-09-08 19:32 ` Paul Moore
-1 siblings, 0 replies; 148+ messages in thread
From: Paul Moore @ 2022-09-08 19:32 UTC (permalink / raw)
To: Casey Schaufler
Cc: John Johansen, LSM List, James Morris, linux-audit, Mimi Zohar,
keescook, SElinux list
On Thu, Sep 8, 2022 at 2:05 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 9/7/2022 8:57 PM, Paul Moore wrote:
> > On Wed, Sep 7, 2022 at 7:53 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >> On 9/7/2022 4:27 PM, Paul Moore wrote:
...
> >>> The ease-of-use quality is a bit subjective, but it does need
> >>> another interface to use properly and it requires string parsing which
> >>> history has shown to be an issue time and time again (although it is
> >>> relatively simple here).
> >> There was a lot of discussion regarding that. My proposed
> >> apparmor="unconfined",smack="User" format was panned for those same reasons.
> >> The nil byte format has been used elsewhere and suggested for that reason.
> > Based on what I recall from those discussions, it was my impression
> > the nil byte label delimiter was suggested simply because no one was
> > entertaining the idea of using something other than the existing
> > procfs interface. It is my opinion that we've taken that interface
> > about as far as it can go, and while it needs to stay intact for
> > compatibility reasons, the LSM stacking functionality should move to a
> > different API that is better suited for it.
>
> It's going to raise its ugly head again with SO_PEERCONTEXT for the
> SELinux+Smack case. But we can cross that bridge when we come to it.
There are also problems with IP_PASSSEC/SCM_SECURITY that we've never
fully resolved (and have gotten a bit lucky over the years); it very
well could be time to add support for IP_SECURITY as the multi-LSM
replacement for SCM_SECURITY. We could leverage the same LSM context
structures as in the other multi-LSM interfaces. Existing
applications could continue to use SCM_SECURITY; in fact I believe we
could have both SCM_SECURITY and IP_SECURITY in the same message for
maximum compatibility.
https://github.com/SELinuxProject/selinux-kernel/issues/24
For SO_PEERSEC, we should probably just introduce SO_PEERSEC2 or
similar, using the same multi-LSM context structures as the other
interfaces.
> > In case it helps spur your imagination, here is a revised strawman:
> >
> > /**
> > * struct lsm_ctx - LSM context
> > * @id: the LSM id number, see LSM_ID_XXX
>
> A LSM ID hard coded in a kernel header makes it harder to develop new
> security modules.
There is so much precedence for defining a token scalar value to
represent a "thing" that I don't know where to begin. Look at IANA,
there are entire organizations that exist to map "things" to numbers.
If you're objecting to assigning LSMs fixed integer numbers you've got
to give me some very explicit reasons (complete with examples) as to
why that would be a mistake.
> The security module can't be self contained. I say
> that, but I acknowledge that I've done the same kind of thing with the
> definition of the struct lsmblob. That isn't part of an external API
> however.
I'm not following you here. See my comment above about better examples.
> It may also interfere with Tetsuo's long standing request that
> we don't do things that prevent the possibility of loadable security
> modules at some point in the future.
I already replied to Tetsuo's email, and while this particular point
about LSM ID numbers wasn't directly addressed, my response there
seems to apply equally well here: it's not so much about loadable
LSMs, it's about out-of-tree LSMs. These are two very different
things, with different solutions.
> On the other hand, there's no great way to include two variable length
> strings in a structure like this. So unless we adopt something as ugly
> as the nil byte scheme this is supposed to replace I expect we're stuck
> with an LSM ID.
I don't like making general comments, but when in doubt, consider me
not-a-fan of string-based identifiers in APIs. Give me token scalar
values instead.
> > * @flags: LSM specific flags, zero if unused
>
> For an API shouldn't this be a specific size? u32? I'm not really
> up to date on the guidance regarding which it should be.
Enh, sure, whatever. You'll remember my initial comment about not
being a syscall stylist; if the discussion has moved to seriously
discussing the syscall prototypes we should likely start a new thread
and bring in the syscall folks ... I vaguely remember there was a
mailing list for syscalls and API changes ...
> I will head in this direction. A couple questions:
>
> Would we want lsm_prev_ctx() as well as lsm_current_ctx(),
I'm not sure I'm following your thinking, what would lsm_prev_ctx() do?
> or should we use the lsm_ctx->flags to identify the provided
> context? If we did that we should have an lsm_ctx() system call
> that returns the current, prev, and whatever other security
> module specific attributes might be associated with the process,
> each identified in the flags field. While the "current" context
> is usually what we're after, there may be cases where the other
> attributes are desired.
I don't understand what you mean by "prev"{ious} attributes. I'm
thinking of lsm_current_ctx() as a multi-LSM replacement for
/proc/self/attr/current. If, for example, we wanted something for
/proc/self/attr/exec I imagine we would create lsm_current_exec(), or
something similarly named, with a similar prototype.
Or perhaps we try to stick a bit closer to the procfs naming and go
with lsm_self_cur(...) and lsm_self_exec(...). All things to discuss.
--
paul-moore.com
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
@ 2022-09-08 19:32 ` Paul Moore
0 siblings, 0 replies; 148+ messages in thread
From: Paul Moore @ 2022-09-08 19:32 UTC (permalink / raw)
To: Casey Schaufler
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On Thu, Sep 8, 2022 at 2:05 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 9/7/2022 8:57 PM, Paul Moore wrote:
> > On Wed, Sep 7, 2022 at 7:53 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >> On 9/7/2022 4:27 PM, Paul Moore wrote:
...
> >>> The ease-of-use quality is a bit subjective, but it does need
> >>> another interface to use properly and it requires string parsing which
> >>> history has shown to be an issue time and time again (although it is
> >>> relatively simple here).
> >> There was a lot of discussion regarding that. My proposed
> >> apparmor="unconfined",smack="User" format was panned for those same reasons.
> >> The nil byte format has been used elsewhere and suggested for that reason.
> > Based on what I recall from those discussions, it was my impression
> > the nil byte label delimiter was suggested simply because no one was
> > entertaining the idea of using something other than the existing
> > procfs interface. It is my opinion that we've taken that interface
> > about as far as it can go, and while it needs to stay intact for
> > compatibility reasons, the LSM stacking functionality should move to a
> > different API that is better suited for it.
>
> It's going to raise its ugly head again with SO_PEERCONTEXT for the
> SELinux+Smack case. But we can cross that bridge when we come to it.
There are also problems with IP_PASSSEC/SCM_SECURITY that we've never
fully resolved (and have gotten a bit lucky over the years); it very
well could be time to add support for IP_SECURITY as the multi-LSM
replacement for SCM_SECURITY. We could leverage the same LSM context
structures as in the other multi-LSM interfaces. Existing
applications could continue to use SCM_SECURITY; in fact I believe we
could have both SCM_SECURITY and IP_SECURITY in the same message for
maximum compatibility.
https://github.com/SELinuxProject/selinux-kernel/issues/24
For SO_PEERSEC, we should probably just introduce SO_PEERSEC2 or
similar, using the same multi-LSM context structures as the other
interfaces.
> > In case it helps spur your imagination, here is a revised strawman:
> >
> > /**
> > * struct lsm_ctx - LSM context
> > * @id: the LSM id number, see LSM_ID_XXX
>
> A LSM ID hard coded in a kernel header makes it harder to develop new
> security modules.
There is so much precedence for defining a token scalar value to
represent a "thing" that I don't know where to begin. Look at IANA,
there are entire organizations that exist to map "things" to numbers.
If you're objecting to assigning LSMs fixed integer numbers you've got
to give me some very explicit reasons (complete with examples) as to
why that would be a mistake.
> The security module can't be self contained. I say
> that, but I acknowledge that I've done the same kind of thing with the
> definition of the struct lsmblob. That isn't part of an external API
> however.
I'm not following you here. See my comment above about better examples.
> It may also interfere with Tetsuo's long standing request that
> we don't do things that prevent the possibility of loadable security
> modules at some point in the future.
I already replied to Tetsuo's email, and while this particular point
about LSM ID numbers wasn't directly addressed, my response there
seems to apply equally well here: it's not so much about loadable
LSMs, it's about out-of-tree LSMs. These are two very different
things, with different solutions.
> On the other hand, there's no great way to include two variable length
> strings in a structure like this. So unless we adopt something as ugly
> as the nil byte scheme this is supposed to replace I expect we're stuck
> with an LSM ID.
I don't like making general comments, but when in doubt, consider me
not-a-fan of string-based identifiers in APIs. Give me token scalar
values instead.
> > * @flags: LSM specific flags, zero if unused
>
> For an API shouldn't this be a specific size? u32? I'm not really
> up to date on the guidance regarding which it should be.
Enh, sure, whatever. You'll remember my initial comment about not
being a syscall stylist; if the discussion has moved to seriously
discussing the syscall prototypes we should likely start a new thread
and bring in the syscall folks ... I vaguely remember there was a
mailing list for syscalls and API changes ...
> I will head in this direction. A couple questions:
>
> Would we want lsm_prev_ctx() as well as lsm_current_ctx(),
I'm not sure I'm following your thinking, what would lsm_prev_ctx() do?
> or should we use the lsm_ctx->flags to identify the provided
> context? If we did that we should have an lsm_ctx() system call
> that returns the current, prev, and whatever other security
> module specific attributes might be associated with the process,
> each identified in the flags field. While the "current" context
> is usually what we're after, there may be cases where the other
> attributes are desired.
I don't understand what you mean by "prev"{ious} attributes. I'm
thinking of lsm_current_ctx() as a multi-LSM replacement for
/proc/self/attr/current. If, for example, we wanted something for
/proc/self/attr/exec I imagine we would create lsm_current_exec(), or
something similarly named, with a similar prototype.
Or perhaps we try to stick a bit closer to the procfs naming and go
with lsm_self_cur(...) and lsm_self_exec(...). All things to discuss.
--
paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
2022-09-08 19:32 ` Paul Moore
@ 2022-09-08 22:56 ` Casey Schaufler
-1 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-08 22:56 UTC (permalink / raw)
To: Paul Moore
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On 9/8/2022 12:32 PM, Paul Moore wrote:
> On Thu, Sep 8, 2022 at 2:05 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/7/2022 8:57 PM, Paul Moore wrote:
>>> On Wed, Sep 7, 2022 at 7:53 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>> On 9/7/2022 4:27 PM, Paul Moore wrote:
> ..
>
>>>>> The ease-of-use quality is a bit subjective, but it does need
>>>>> another interface to use properly and it requires string parsing which
>>>>> history has shown to be an issue time and time again (although it is
>>>>> relatively simple here).
>>>> There was a lot of discussion regarding that. My proposed
>>>> apparmor="unconfined",smack="User" format was panned for those same reasons.
>>>> The nil byte format has been used elsewhere and suggested for that reason.
>>> Based on what I recall from those discussions, it was my impression
>>> the nil byte label delimiter was suggested simply because no one was
>>> entertaining the idea of using something other than the existing
>>> procfs interface. It is my opinion that we've taken that interface
>>> about as far as it can go, and while it needs to stay intact for
>>> compatibility reasons, the LSM stacking functionality should move to a
>>> different API that is better suited for it.
>> It's going to raise its ugly head again with SO_PEERCONTEXT for the
>> SELinux+Smack case. But we can cross that bridge when we come to it.
> There are also problems with IP_PASSSEC/SCM_SECURITY that we've never
> fully resolved (and have gotten a bit lucky over the years); it very
> well could be time to add support for IP_SECURITY as the multi-LSM
> replacement for SCM_SECURITY. We could leverage the same LSM context
> structures as in the other multi-LSM interfaces. Existing
> applications could continue to use SCM_SECURITY; in fact I believe we
> could have both SCM_SECURITY and IP_SECURITY in the same message for
> maximum compatibility.
Adding IP_SECURITY seems sensible. Having both at the same time leaves
us with the question of which security module's value to put in SCM_SECURITY
when there are multiple choices. I assume we'd use the first available
value, as determined by the LSM list order, or the interface_lsm if we're
supporting that concept. And again, that's a problem for the complete
stacking round.
> https://github.com/SELinuxProject/selinux-kernel/issues/24
>
> For SO_PEERSEC, we should probably just introduce SO_PEERSEC2 or
> similar, using the same multi-LSM context structures as the other
> interfaces.
Also sensible, although I think SO_PEERCONTEXT or SO_PEERCTX is a better
name than SO_PEERSEC2. Also a problem for complete stacking and it is
way to early for me to get into bikeshedding.
>>> In case it helps spur your imagination, here is a revised strawman:
>>>
>>> /**
>>> * struct lsm_ctx - LSM context
>>> * @id: the LSM id number, see LSM_ID_XXX
>> A LSM ID hard coded in a kernel header makes it harder to develop new
>> security modules.
> There is so much precedence for defining a token scalar value to
> represent a "thing" that I don't know where to begin. Look at IANA,
> there are entire organizations that exist to map "things" to numbers.
>
> If you're objecting to assigning LSMs fixed integer numbers you've got
> to give me some very explicit reasons (complete with examples) as to
> why that would be a mistake.
I talked myself out of the objection below. Thanks for listening.
>> The security module can't be self contained. I say
>> that, but I acknowledge that I've done the same kind of thing with the
>> definition of the struct lsmblob. That isn't part of an external API
>> however.
> I'm not following you here. See my comment above about better examples.
>
>> It may also interfere with Tetsuo's long standing request that
>> we don't do things that prevent the possibility of loadable security
>> modules at some point in the future.
> I already replied to Tetsuo's email, and while this particular point
> about LSM ID numbers wasn't directly addressed, my response there
> seems to apply equally well here: it's not so much about loadable
> LSMs, it's about out-of-tree LSMs. These are two very different
> things, with different solutions.
Agreed.
>> On the other hand, there's no great way to include two variable length
>> strings in a structure like this. So unless we adopt something as ugly
>> as the nil byte scheme this is supposed to replace I expect we're stuck
>> with an LSM ID.
> I don't like making general comments, but when in doubt, consider me
> not-a-fan of string-based identifiers in APIs. Give me token scalar
> values instead.
Works for me.
>>> * @flags: LSM specific flags, zero if unused
>> For an API shouldn't this be a specific size? u32? I'm not really
>> up to date on the guidance regarding which it should be.
> Enh, sure, whatever. You'll remember my initial comment about not
> being a syscall stylist; if the discussion has moved to seriously
> discussing the syscall prototypes we should likely start a new thread
> and bring in the syscall folks ... I vaguely remember there was a
> mailing list for syscalls and API changes ...
Good idea. I'm reading the official how-to-write-a-syscall documentation.
>> I will head in this direction. A couple questions:
>>
>> Would we want lsm_prev_ctx() as well as lsm_current_ctx(),
> I'm not sure I'm following your thinking, what would lsm_prev_ctx() do?
Instead of the values in /proc/.../attr/current you'd get the
values from /proc/.../attr/prev.
>> or should we use the lsm_ctx->flags to identify the provided
>> context? If we did that we should have an lsm_ctx() system call
>> that returns the current, prev, and whatever other security
>> module specific attributes might be associated with the process,
>> each identified in the flags field. While the "current" context
>> is usually what we're after, there may be cases where the other
>> attributes are desired.
> I don't understand what you mean by "prev"{ious} attributes. I'm
> thinking of lsm_current_ctx() as a multi-LSM replacement for
> /proc/self/attr/current. If, for example, we wanted something for
> /proc/self/attr/exec I imagine we would create lsm_current_exec(), or
> something similarly named, with a similar prototype.
>
> Or perhaps we try to stick a bit closer to the procfs naming and go
> with lsm_self_cur(...) and lsm_self_exec(...). All things to discuss.
I'm thinking that a syscall lsm_self_attr() would get all of the attributes
that are available from /proc/.../attr today. Flags would identify what
kind of attribute they are:
LSM_ATTR_CURRENT 0x0001 /* Current security context */
LSM_ATTR_PREV 0x0002 /* Previous security context */
LSM_ATTR_EXEC 0x0004 /* Exec security context */
...
LSM_ATTR_SOCREATE 0x0020 /* Socket creation context */
As you suggest above (with a touch of modification) lsm_self_current()
gets just the LSM_ATTR_CURRENT values, lsm_self_exec() gets the
LSM_ATTR_EXEC values. It would be easy to add new attributes and implement
library functions to filter them out rather than have to create new
syscalls every time a new attribute is added.
It might also be useful to have a flag value (See? You were right) for
the syscalls LSM_ATTR_INTERFACE_LSM which instructs the syscall to only
return the attribute values for the interface_lsm. Hmm. How about allowing
the caller to specify which security module they want the values for by
LSM ID? That could be useful although certainly not necessary. It could
make the user space processing more efficient. It would make converting
libselinux and libsmack to use the syscalls a little bit easier. I'm not
wedded to the LSM ID filter as the caller can always ignore data from
security modules it doesn't care about.
What about lsm_self_attr_set()? This seem rife with peril. Setting a group
of security attributes on a process could fail halfway through and then
require unwinding the preceding successes. I could see having this syscall
if it was only allowed to set a single attribute at a time.
lsm_pid_attr() would be like lsm_self_attr(), but would take a process id as
an additional parameter and get the values for the specified process. This
could make a bunch of dbus' /proc accesses unnecessary. It would have to be
quite a bit more complicated than lsm_self_attr() because it would have to
verify that the caller has appropriate access to the target process. We can
debate whether Smack can deny access to another process' SELinux context.
We can also debate whether an incomplete operation (you can get the SELinux
context, but not the AppArmor context) is an error.
I am going to start playing with these syscalls. Please help me understand
where I have suggested something stoopid.
Thank you.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
@ 2022-09-08 22:56 ` Casey Schaufler
0 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-08 22:56 UTC (permalink / raw)
To: Paul Moore
Cc: John Johansen, LSM List, James Morris, linux-audit, Mimi Zohar,
keescook, SElinux list, casey
On 9/8/2022 12:32 PM, Paul Moore wrote:
> On Thu, Sep 8, 2022 at 2:05 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/7/2022 8:57 PM, Paul Moore wrote:
>>> On Wed, Sep 7, 2022 at 7:53 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>> On 9/7/2022 4:27 PM, Paul Moore wrote:
> ..
>
>>>>> The ease-of-use quality is a bit subjective, but it does need
>>>>> another interface to use properly and it requires string parsing which
>>>>> history has shown to be an issue time and time again (although it is
>>>>> relatively simple here).
>>>> There was a lot of discussion regarding that. My proposed
>>>> apparmor="unconfined",smack="User" format was panned for those same reasons.
>>>> The nil byte format has been used elsewhere and suggested for that reason.
>>> Based on what I recall from those discussions, it was my impression
>>> the nil byte label delimiter was suggested simply because no one was
>>> entertaining the idea of using something other than the existing
>>> procfs interface. It is my opinion that we've taken that interface
>>> about as far as it can go, and while it needs to stay intact for
>>> compatibility reasons, the LSM stacking functionality should move to a
>>> different API that is better suited for it.
>> It's going to raise its ugly head again with SO_PEERCONTEXT for the
>> SELinux+Smack case. But we can cross that bridge when we come to it.
> There are also problems with IP_PASSSEC/SCM_SECURITY that we've never
> fully resolved (and have gotten a bit lucky over the years); it very
> well could be time to add support for IP_SECURITY as the multi-LSM
> replacement for SCM_SECURITY. We could leverage the same LSM context
> structures as in the other multi-LSM interfaces. Existing
> applications could continue to use SCM_SECURITY; in fact I believe we
> could have both SCM_SECURITY and IP_SECURITY in the same message for
> maximum compatibility.
Adding IP_SECURITY seems sensible. Having both at the same time leaves
us with the question of which security module's value to put in SCM_SECURITY
when there are multiple choices. I assume we'd use the first available
value, as determined by the LSM list order, or the interface_lsm if we're
supporting that concept. And again, that's a problem for the complete
stacking round.
> https://github.com/SELinuxProject/selinux-kernel/issues/24
>
> For SO_PEERSEC, we should probably just introduce SO_PEERSEC2 or
> similar, using the same multi-LSM context structures as the other
> interfaces.
Also sensible, although I think SO_PEERCONTEXT or SO_PEERCTX is a better
name than SO_PEERSEC2. Also a problem for complete stacking and it is
way to early for me to get into bikeshedding.
>>> In case it helps spur your imagination, here is a revised strawman:
>>>
>>> /**
>>> * struct lsm_ctx - LSM context
>>> * @id: the LSM id number, see LSM_ID_XXX
>> A LSM ID hard coded in a kernel header makes it harder to develop new
>> security modules.
> There is so much precedence for defining a token scalar value to
> represent a "thing" that I don't know where to begin. Look at IANA,
> there are entire organizations that exist to map "things" to numbers.
>
> If you're objecting to assigning LSMs fixed integer numbers you've got
> to give me some very explicit reasons (complete with examples) as to
> why that would be a mistake.
I talked myself out of the objection below. Thanks for listening.
>> The security module can't be self contained. I say
>> that, but I acknowledge that I've done the same kind of thing with the
>> definition of the struct lsmblob. That isn't part of an external API
>> however.
> I'm not following you here. See my comment above about better examples.
>
>> It may also interfere with Tetsuo's long standing request that
>> we don't do things that prevent the possibility of loadable security
>> modules at some point in the future.
> I already replied to Tetsuo's email, and while this particular point
> about LSM ID numbers wasn't directly addressed, my response there
> seems to apply equally well here: it's not so much about loadable
> LSMs, it's about out-of-tree LSMs. These are two very different
> things, with different solutions.
Agreed.
>> On the other hand, there's no great way to include two variable length
>> strings in a structure like this. So unless we adopt something as ugly
>> as the nil byte scheme this is supposed to replace I expect we're stuck
>> with an LSM ID.
> I don't like making general comments, but when in doubt, consider me
> not-a-fan of string-based identifiers in APIs. Give me token scalar
> values instead.
Works for me.
>>> * @flags: LSM specific flags, zero if unused
>> For an API shouldn't this be a specific size? u32? I'm not really
>> up to date on the guidance regarding which it should be.
> Enh, sure, whatever. You'll remember my initial comment about not
> being a syscall stylist; if the discussion has moved to seriously
> discussing the syscall prototypes we should likely start a new thread
> and bring in the syscall folks ... I vaguely remember there was a
> mailing list for syscalls and API changes ...
Good idea. I'm reading the official how-to-write-a-syscall documentation.
>> I will head in this direction. A couple questions:
>>
>> Would we want lsm_prev_ctx() as well as lsm_current_ctx(),
> I'm not sure I'm following your thinking, what would lsm_prev_ctx() do?
Instead of the values in /proc/.../attr/current you'd get the
values from /proc/.../attr/prev.
>> or should we use the lsm_ctx->flags to identify the provided
>> context? If we did that we should have an lsm_ctx() system call
>> that returns the current, prev, and whatever other security
>> module specific attributes might be associated with the process,
>> each identified in the flags field. While the "current" context
>> is usually what we're after, there may be cases where the other
>> attributes are desired.
> I don't understand what you mean by "prev"{ious} attributes. I'm
> thinking of lsm_current_ctx() as a multi-LSM replacement for
> /proc/self/attr/current. If, for example, we wanted something for
> /proc/self/attr/exec I imagine we would create lsm_current_exec(), or
> something similarly named, with a similar prototype.
>
> Or perhaps we try to stick a bit closer to the procfs naming and go
> with lsm_self_cur(...) and lsm_self_exec(...). All things to discuss.
I'm thinking that a syscall lsm_self_attr() would get all of the attributes
that are available from /proc/.../attr today. Flags would identify what
kind of attribute they are:
LSM_ATTR_CURRENT 0x0001 /* Current security context */
LSM_ATTR_PREV 0x0002 /* Previous security context */
LSM_ATTR_EXEC 0x0004 /* Exec security context */
...
LSM_ATTR_SOCREATE 0x0020 /* Socket creation context */
As you suggest above (with a touch of modification) lsm_self_current()
gets just the LSM_ATTR_CURRENT values, lsm_self_exec() gets the
LSM_ATTR_EXEC values. It would be easy to add new attributes and implement
library functions to filter them out rather than have to create new
syscalls every time a new attribute is added.
It might also be useful to have a flag value (See? You were right) for
the syscalls LSM_ATTR_INTERFACE_LSM which instructs the syscall to only
return the attribute values for the interface_lsm. Hmm. How about allowing
the caller to specify which security module they want the values for by
LSM ID? That could be useful although certainly not necessary. It could
make the user space processing more efficient. It would make converting
libselinux and libsmack to use the syscalls a little bit easier. I'm not
wedded to the LSM ID filter as the caller can always ignore data from
security modules it doesn't care about.
What about lsm_self_attr_set()? This seem rife with peril. Setting a group
of security attributes on a process could fail halfway through and then
require unwinding the preceding successes. I could see having this syscall
if it was only allowed to set a single attribute at a time.
lsm_pid_attr() would be like lsm_self_attr(), but would take a process id as
an additional parameter and get the values for the specified process. This
could make a bunch of dbus' /proc accesses unnecessary. It would have to be
quite a bit more complicated than lsm_self_attr() because it would have to
verify that the caller has appropriate access to the target process. We can
debate whether Smack can deny access to another process' SELinux context.
We can also debate whether an incomplete operation (you can get the SELinux
context, but not the AppArmor context) is an error.
I am going to start playing with these syscalls. Please help me understand
where I have suggested something stoopid.
Thank you.
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
2022-09-08 22:56 ` Casey Schaufler
@ 2022-09-10 4:17 ` Tetsuo Handa
-1 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-09-10 4:17 UTC (permalink / raw)
To: Casey Schaufler, Paul Moore
Cc: John Johansen, LSM List, James Morris, linux-audit, Mimi Zohar,
keescook, SElinux list
On 2022/09/09 7:56, Casey Schaufler wrote:
> Good idea. I'm reading the official how-to-write-a-syscall documentation.
Can't we use prctl() syscall? We can assign an LSM ID when an (built-in or loadable) LSM
is loaded, and pass that LSM ID as one of arguments for prctl().
Since we have security_task_prctl(option, arg2, arg3, arg4, arg5) inside prctl(), an LSM
which was assigned that LSM ID upon load checks arguments (including PID argument).
That will be something like ioctl() without open("/proc/pid/*/attr/*").
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
@ 2022-09-10 4:17 ` Tetsuo Handa
0 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-09-10 4:17 UTC (permalink / raw)
To: Casey Schaufler, Paul Moore
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On 2022/09/09 7:56, Casey Schaufler wrote:
> Good idea. I'm reading the official how-to-write-a-syscall documentation.
Can't we use prctl() syscall? We can assign an LSM ID when an (built-in or loadable) LSM
is loaded, and pass that LSM ID as one of arguments for prctl().
Since we have security_task_prctl(option, arg2, arg3, arg4, arg5) inside prctl(), an LSM
which was assigned that LSM ID upon load checks arguments (including PID argument).
That will be something like ioctl() without open("/proc/pid/*/attr/*").
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
2022-09-10 4:17 ` Tetsuo Handa
@ 2022-09-12 17:37 ` Casey Schaufler
-1 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-12 17:37 UTC (permalink / raw)
To: Tetsuo Handa, Paul Moore
Cc: John Johansen, LSM List, James Morris, linux-audit, Mimi Zohar,
keescook, SElinux list, casey
On 9/9/2022 9:17 PM, Tetsuo Handa wrote:
> On 2022/09/09 7:56, Casey Schaufler wrote:
>> Good idea. I'm reading the official how-to-write-a-syscall documentation.
> Can't we use prctl() syscall? We can assign an LSM ID when an (built-in or loadable) LSM
> is loaded, and pass that LSM ID as one of arguments for prctl().
I'm not the fan of an LSM ID that Paul is, but if we're going to use them I much
prefer a static value to a dynamic one. Libraries/programs that have to query the
system to get the ID ( int selinuxid = lsm_get_id("selinux"); ) are harder to
maintain. It would really push us toward requiring a liblsm, which I think we're
still trying to avoid.
That doesn't give us a good answer for loadable modules. The last time I looked
seriously at loadable modules I was considering that we'd need a security module
that manages them, very much like BPF manages the eBPF programs. Loadable modules
could use prctl, or some other mechanism, but they would have to be different
from built-in modules. You can't require built-in modules to conform to the
restrictions you'd have to impose on loadable ones. The Loadable Module Security
Module would have a static ID and somehow multiplex what lsm_self_attr() reports.
I think it could be made to work. I can't say that it is something I am likely to
get to soon.
>
> Since we have security_task_prctl(option, arg2, arg3, arg4, arg5) inside prctl(), an LSM
> which was assigned that LSM ID upon load checks arguments (including PID argument).
> That will be something like ioctl() without open("/proc/pid/*/attr/*").
>
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
@ 2022-09-12 17:37 ` Casey Schaufler
0 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-12 17:37 UTC (permalink / raw)
To: Tetsuo Handa, Paul Moore
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On 9/9/2022 9:17 PM, Tetsuo Handa wrote:
> On 2022/09/09 7:56, Casey Schaufler wrote:
>> Good idea. I'm reading the official how-to-write-a-syscall documentation.
> Can't we use prctl() syscall? We can assign an LSM ID when an (built-in or loadable) LSM
> is loaded, and pass that LSM ID as one of arguments for prctl().
I'm not the fan of an LSM ID that Paul is, but if we're going to use them I much
prefer a static value to a dynamic one. Libraries/programs that have to query the
system to get the ID ( int selinuxid = lsm_get_id("selinux"); ) are harder to
maintain. It would really push us toward requiring a liblsm, which I think we're
still trying to avoid.
That doesn't give us a good answer for loadable modules. The last time I looked
seriously at loadable modules I was considering that we'd need a security module
that manages them, very much like BPF manages the eBPF programs. Loadable modules
could use prctl, or some other mechanism, but they would have to be different
from built-in modules. You can't require built-in modules to conform to the
restrictions you'd have to impose on loadable ones. The Loadable Module Security
Module would have a static ID and somehow multiplex what lsm_self_attr() reports.
I think it could be made to work. I can't say that it is something I am likely to
get to soon.
>
> Since we have security_task_prctl(option, arg2, arg3, arg4, arg5) inside prctl(), an LSM
> which was assigned that LSM ID upon load checks arguments (including PID argument).
> That will be something like ioctl() without open("/proc/pid/*/attr/*").
>
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
2022-09-12 17:37 ` Casey Schaufler
@ 2022-09-13 10:47 ` Tetsuo Handa
-1 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-09-13 10:47 UTC (permalink / raw)
To: Casey Schaufler, Paul Moore
Cc: John Johansen, LSM List, James Morris, linux-audit, Mimi Zohar,
keescook, SElinux list
On 2022/09/13 2:37, Casey Schaufler wrote:
> That doesn't give us a good answer for loadable modules. The last time I looked
> seriously at loadable modules I was considering that we'd need a security module
> that manages them, very much like BPF manages the eBPF programs. Loadable modules
> could use prctl, or some other mechanism, but they would have to be different
> from built-in modules. You can't require built-in modules to conform to the
> restrictions you'd have to impose on loadable ones.
What I'm requesting (in other words, the biggest barrier I want to solve) is
security/security.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/security/security.c b/security/security.c
index 4b95de24bc8d..ed34e25af22b 100644
--- a/security/security.c
+++ b/security/security.c
@@ -73,6 +73,7 @@ const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
};
struct security_hook_heads security_hook_heads __lsm_ro_after_init;
+EXPORT_SYMBOL_GPL(security_hook_heads);
static BLOCKING_NOTIFIER_HEAD(blocking_lsm_notifier_chain);
static struct kmem_cache *lsm_file_cache;
--
2.18.4
and optionally (in other words, the second biggest barrier I want to solve is)
security/security.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/security.c b/security/security.c
index ed34e25af22b..4cc09e6cb32a 100644
--- a/security/security.c
+++ b/security/security.c
@@ -72,7 +72,7 @@ const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
};
-struct security_hook_heads security_hook_heads __lsm_ro_after_init;
+struct security_hook_heads security_hook_heads;
EXPORT_SYMBOL_GPL(security_hook_heads);
static BLOCKING_NOTIFIER_HEAD(blocking_lsm_notifier_chain);
--
2.18.4
. A security module that manages loadable LSM modules cannot give us a good answer
if there is a kernel config option to disable the manager security module.
As long as the death sentence remains, being able to disallow loadable LSMs
is a very stupid decision. If a loadable kernel module were malicious, that
module can do what AKARI/CaitSith are doing today using more disguised code.
There should be a chance for ethical loadable LSM modules.
Kernels which seriously need security should be built with CONFIG_MODULES=n.
Kernels which want to use loadable modules (not limited to LSM) but still need to
remain secure should consider using e.g. CONFIG_MODULE_SIG=y.
I consider that real bugs which may crash/compromise the kernel are reported by
fuzz testing. Rather than disallowing loadable module LSMs, fixing real bugs
should be the way to proceed.
> The Loadable Module Security
> Module would have a static ID and somehow multiplex what lsm_self_attr() reports.
I don't think loadable module LSM have a static ID. TOMOYO/AKARI/CaitSith are already
working without "struct lsm_blob_sizes blob_sizes", without /proc/pid/attr/ interface,
without modification of userspace programs. TOMOYO/AKARI/CaitSith are designed to avoid
interface/resource conflicts you are trying to solve.
> I think it could be made to work. I can't say that it is something I am likely to
> get to soon.
The kernel config option and distribution's policy are preventing users from using
non-builtin LSMs in distributor's kernels. It is a trivial task to make TOMOYO work
in distributor's kernels if above-mentioned changes are accepted.
https://bugzilla.redhat.com/show_bug.cgi?id=542986
^ permalink raw reply related [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
@ 2022-09-13 10:47 ` Tetsuo Handa
0 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-09-13 10:47 UTC (permalink / raw)
To: Casey Schaufler, Paul Moore
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On 2022/09/13 2:37, Casey Schaufler wrote:
> That doesn't give us a good answer for loadable modules. The last time I looked
> seriously at loadable modules I was considering that we'd need a security module
> that manages them, very much like BPF manages the eBPF programs. Loadable modules
> could use prctl, or some other mechanism, but they would have to be different
> from built-in modules. You can't require built-in modules to conform to the
> restrictions you'd have to impose on loadable ones.
What I'm requesting (in other words, the biggest barrier I want to solve) is
security/security.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/security/security.c b/security/security.c
index 4b95de24bc8d..ed34e25af22b 100644
--- a/security/security.c
+++ b/security/security.c
@@ -73,6 +73,7 @@ const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
};
struct security_hook_heads security_hook_heads __lsm_ro_after_init;
+EXPORT_SYMBOL_GPL(security_hook_heads);
static BLOCKING_NOTIFIER_HEAD(blocking_lsm_notifier_chain);
static struct kmem_cache *lsm_file_cache;
--
2.18.4
and optionally (in other words, the second biggest barrier I want to solve is)
security/security.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/security/security.c b/security/security.c
index ed34e25af22b..4cc09e6cb32a 100644
--- a/security/security.c
+++ b/security/security.c
@@ -72,7 +72,7 @@ const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
[LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
};
-struct security_hook_heads security_hook_heads __lsm_ro_after_init;
+struct security_hook_heads security_hook_heads;
EXPORT_SYMBOL_GPL(security_hook_heads);
static BLOCKING_NOTIFIER_HEAD(blocking_lsm_notifier_chain);
--
2.18.4
. A security module that manages loadable LSM modules cannot give us a good answer
if there is a kernel config option to disable the manager security module.
As long as the death sentence remains, being able to disallow loadable LSMs
is a very stupid decision. If a loadable kernel module were malicious, that
module can do what AKARI/CaitSith are doing today using more disguised code.
There should be a chance for ethical loadable LSM modules.
Kernels which seriously need security should be built with CONFIG_MODULES=n.
Kernels which want to use loadable modules (not limited to LSM) but still need to
remain secure should consider using e.g. CONFIG_MODULE_SIG=y.
I consider that real bugs which may crash/compromise the kernel are reported by
fuzz testing. Rather than disallowing loadable module LSMs, fixing real bugs
should be the way to proceed.
> The Loadable Module Security
> Module would have a static ID and somehow multiplex what lsm_self_attr() reports.
I don't think loadable module LSM have a static ID. TOMOYO/AKARI/CaitSith are already
working without "struct lsm_blob_sizes blob_sizes", without /proc/pid/attr/ interface,
without modification of userspace programs. TOMOYO/AKARI/CaitSith are designed to avoid
interface/resource conflicts you are trying to solve.
> I think it could be made to work. I can't say that it is something I am likely to
> get to soon.
The kernel config option and distribution's policy are preventing users from using
non-builtin LSMs in distributor's kernels. It is a trivial task to make TOMOYO work
in distributor's kernels if above-mentioned changes are accepted.
https://bugzilla.redhat.com/show_bug.cgi?id=542986
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply related [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
2022-09-13 10:47 ` Tetsuo Handa
@ 2022-09-13 14:45 ` Casey Schaufler
-1 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-13 14:45 UTC (permalink / raw)
To: Tetsuo Handa, Paul Moore
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On 9/13/2022 3:47 AM, Tetsuo Handa wrote:
> On 2022/09/13 2:37, Casey Schaufler wrote:
>> That doesn't give us a good answer for loadable modules. The last time I looked
>> seriously at loadable modules I was considering that we'd need a security module
>> that manages them, very much like BPF manages the eBPF programs. Loadable modules
>> could use prctl, or some other mechanism, but they would have to be different
>> from built-in modules. You can't require built-in modules to conform to the
>> restrictions you'd have to impose on loadable ones.
> What I'm requesting (in other words, the biggest barrier I want to solve) is
>
> security/security.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/security/security.c b/security/security.c
> index 4b95de24bc8d..ed34e25af22b 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -73,6 +73,7 @@ const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
> };
>
> struct security_hook_heads security_hook_heads __lsm_ro_after_init;
> +EXPORT_SYMBOL_GPL(security_hook_heads);
> static BLOCKING_NOTIFIER_HEAD(blocking_lsm_notifier_chain);
>
> static struct kmem_cache *lsm_file_cache; --
> 2.18.4
>
> and optionally (in other words, the second biggest barrier I want to solve is)
>
> security/security.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/security.c b/security/security.c
> index ed34e25af22b..4cc09e6cb32a 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -72,7 +72,7 @@ const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
> [LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
> };
>
> -struct security_hook_heads security_hook_heads __lsm_ro_after_init;
> +struct security_hook_heads security_hook_heads;
> EXPORT_SYMBOL_GPL(security_hook_heads);
> static BLOCKING_NOTIFIER_HEAD(blocking_lsm_notifier_chain);
I don't see either of these changes happening. I'm not the right person
to argue either side, but I understand the rationale for keeping them
private. That's why I think we need to have a different mechanism for
loadable modules, and why it needs to be optional.
>
> --
> 2.18.4
>
> . A security module that manages loadable LSM modules cannot give us a good answer
> if there is a kernel config option to disable the manager security module.
The community that is absolutely opposed to loadable modules will disagree.
> As long as the death sentence remains, being able to disallow loadable LSMs
> is a very stupid decision. If a loadable kernel module were malicious, that
> module can do what AKARI/CaitSith are doing today using more disguised code.
> There should be a chance for ethical loadable LSM modules.
My understanding of the argument is that while an in-tree, built in module
will be subject to appropriate review, you can't say that about an out-of-tree,
loadable module.
> Kernels which seriously need security should be built with CONFIG_MODULES=n.
> Kernels which want to use loadable modules (not limited to LSM) but still need to
> remain secure should consider using e.g. CONFIG_MODULE_SIG=y.
>
> I consider that real bugs which may crash/compromise the kernel are reported by
> fuzz testing. Rather than disallowing loadable module LSMs, fixing real bugs
> should be the way to proceed.
A significant portion (maybe the majority) of security work being done
today is based on the notion that we can't fix all the bugs or exclude all
the malicious code, so we better protect specific bits of code from the
rest. Fuzz testing is a wonderful tool, but won't find everything.
> > The Loadable Module Security
> > Module would have a static ID and somehow multiplex what lsm_self_attr() reports.
>
> I don't think loadable module LSM have a static ID. TOMOYO/AKARI/CaitSith are already
> working without "struct lsm_blob_sizes blob_sizes", without /proc/pid/attr/ interface,
> without modification of userspace programs. TOMOYO/AKARI/CaitSith are designed to avoid
> interface/resource conflicts you are trying to solve.
A loadable module would have to be managed differently from a built-in one.
Hence the notion of a loadable module manager.
> > I think it could be made to work. I can't say that it is something I am likely to
> > get to soon.
>
> The kernel config option and distribution's policy are preventing users from using
> non-builtin LSMs in distributor's kernels. It is a trivial task to make TOMOYO work
> in distributor's kernels if above-mentioned changes are accepted.
You should be able to use TOMOYO as a built-in along side other security modules
today. Aside from getting the distribution to include it in their kernel
configuration, which is admittedly no mean feat, and getting any user-space you
need included, you should already have what you need.
> https://bugzilla.redhat.com/show_bug.cgi?id=542986
Ten years ago they said "Don't want to, aren't going to". Sadly, I doubt
there would be a different attitude today. The decision to support a security
module in a distribution is serious. I can definitely see how Redhat would
have their hands full supporting SELinux.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
@ 2022-09-13 14:45 ` Casey Schaufler
0 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-13 14:45 UTC (permalink / raw)
To: Tetsuo Handa, Paul Moore
Cc: John Johansen, LSM List, James Morris, linux-audit, Mimi Zohar,
keescook, SElinux list, casey
On 9/13/2022 3:47 AM, Tetsuo Handa wrote:
> On 2022/09/13 2:37, Casey Schaufler wrote:
>> That doesn't give us a good answer for loadable modules. The last time I looked
>> seriously at loadable modules I was considering that we'd need a security module
>> that manages them, very much like BPF manages the eBPF programs. Loadable modules
>> could use prctl, or some other mechanism, but they would have to be different
>> from built-in modules. You can't require built-in modules to conform to the
>> restrictions you'd have to impose on loadable ones.
> What I'm requesting (in other words, the biggest barrier I want to solve) is
>
> security/security.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/security/security.c b/security/security.c
> index 4b95de24bc8d..ed34e25af22b 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -73,6 +73,7 @@ const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
> };
>
> struct security_hook_heads security_hook_heads __lsm_ro_after_init;
> +EXPORT_SYMBOL_GPL(security_hook_heads);
> static BLOCKING_NOTIFIER_HEAD(blocking_lsm_notifier_chain);
>
> static struct kmem_cache *lsm_file_cache; --
> 2.18.4
>
> and optionally (in other words, the second biggest barrier I want to solve is)
>
> security/security.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/security/security.c b/security/security.c
> index ed34e25af22b..4cc09e6cb32a 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -72,7 +72,7 @@ const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = {
> [LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality",
> };
>
> -struct security_hook_heads security_hook_heads __lsm_ro_after_init;
> +struct security_hook_heads security_hook_heads;
> EXPORT_SYMBOL_GPL(security_hook_heads);
> static BLOCKING_NOTIFIER_HEAD(blocking_lsm_notifier_chain);
I don't see either of these changes happening. I'm not the right person
to argue either side, but I understand the rationale for keeping them
private. That's why I think we need to have a different mechanism for
loadable modules, and why it needs to be optional.
>
> --
> 2.18.4
>
> . A security module that manages loadable LSM modules cannot give us a good answer
> if there is a kernel config option to disable the manager security module.
The community that is absolutely opposed to loadable modules will disagree.
> As long as the death sentence remains, being able to disallow loadable LSMs
> is a very stupid decision. If a loadable kernel module were malicious, that
> module can do what AKARI/CaitSith are doing today using more disguised code.
> There should be a chance for ethical loadable LSM modules.
My understanding of the argument is that while an in-tree, built in module
will be subject to appropriate review, you can't say that about an out-of-tree,
loadable module.
> Kernels which seriously need security should be built with CONFIG_MODULES=n.
> Kernels which want to use loadable modules (not limited to LSM) but still need to
> remain secure should consider using e.g. CONFIG_MODULE_SIG=y.
>
> I consider that real bugs which may crash/compromise the kernel are reported by
> fuzz testing. Rather than disallowing loadable module LSMs, fixing real bugs
> should be the way to proceed.
A significant portion (maybe the majority) of security work being done
today is based on the notion that we can't fix all the bugs or exclude all
the malicious code, so we better protect specific bits of code from the
rest. Fuzz testing is a wonderful tool, but won't find everything.
> > The Loadable Module Security
> > Module would have a static ID and somehow multiplex what lsm_self_attr() reports.
>
> I don't think loadable module LSM have a static ID. TOMOYO/AKARI/CaitSith are already
> working without "struct lsm_blob_sizes blob_sizes", without /proc/pid/attr/ interface,
> without modification of userspace programs. TOMOYO/AKARI/CaitSith are designed to avoid
> interface/resource conflicts you are trying to solve.
A loadable module would have to be managed differently from a built-in one.
Hence the notion of a loadable module manager.
> > I think it could be made to work. I can't say that it is something I am likely to
> > get to soon.
>
> The kernel config option and distribution's policy are preventing users from using
> non-builtin LSMs in distributor's kernels. It is a trivial task to make TOMOYO work
> in distributor's kernels if above-mentioned changes are accepted.
You should be able to use TOMOYO as a built-in along side other security modules
today. Aside from getting the distribution to include it in their kernel
configuration, which is admittedly no mean feat, and getting any user-space you
need included, you should already have what you need.
> https://bugzilla.redhat.com/show_bug.cgi?id=542986
Ten years ago they said "Don't want to, aren't going to". Sadly, I doubt
there would be a different attitude today. The decision to support a security
module in a distribution is serious. I can definitely see how Redhat would
have their hands full supporting SELinux.
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
2022-09-13 14:45 ` Casey Schaufler
@ 2022-09-14 13:57 ` Tetsuo Handa
-1 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-09-14 13:57 UTC (permalink / raw)
To: Casey Schaufler, Paul Moore
Cc: John Johansen, LSM List, James Morris, linux-audit, Mimi Zohar,
keescook, SElinux list
On 2022/09/13 23:45, Casey Schaufler wrote:
>> . A security module that manages loadable LSM modules cannot give us a good answer
>> if there is a kernel config option to disable the manager security module.
>
> The community that is absolutely opposed to loadable modules will disagree.
Who are members of that community?
Hiding security_hook_heads from /proc/kallsyms has no value from security
perspective, for malicious loadable kernel modules can calculate the address
of security_hook_heads based on addresses of relevant functions and byte-code
in the relevant functions.
Keeping __lsm_ro_after_init might have a little value, but at the same time
it might make kernel less secure (or more prone to memory corruption) due to
the need to pass rodata=0 kernel command line option when a loadable module
LSM is loaded.
>> The kernel config option and distribution's policy are preventing users from using
>> non-builtin LSMs in distributor's kernels. It is a trivial task to make TOMOYO work
>> in distributor's kernels if above-mentioned changes are accepted.
>
> You should be able to use TOMOYO as a built-in along side other security modules
> today. Aside from getting the distribution to include it in their kernel
> configuration, which is admittedly no mean feat, and getting any user-space you
> need included, you should already have what you need.
That's a chicken-and-egg problem.
Yes, we can use TOMOYO as a built-in along side other security modules for
_user-built_ kernels. But no, we can't use TOMOYO for _distributor-built_ kernels
(namely, Fedora/CentOS Stream/RHEL kernels).
>> https://bugzilla.redhat.com/show_bug.cgi?id=542986
>
> Ten years ago they said "Don't want to, aren't going to". Sadly, I doubt
> there would be a different attitude today. The decision to support a security
> module in a distribution is serious. I can definitely see how Redhat would
> have their hands full supporting SELinux.
Please distinguish the difference between "enable" and "support" at
https://bugzilla.redhat.com/show_bug.cgi?id=542986#c7 . (By the way,
I hate the word "support", for nobody can share agreed definition.)
"enable" is something like "available", "allow to exist".
"support" is something like "guaranteed", "provide efforts for fixing bugs".
However, in the Red Hat's world, "enable" == "support". The kernel config options
enabled by Red Hat is supported by Red Hat, and the kernel config options Red Hat
cannot support cannot be enabled by Red Hat.
On the contrary, in the vanilla kernel's world, the in-tree version of TOMOYO
cannot be built as a loadable module LSM. And it is impossible to built TOMOYO
as a loadable module LSM (so that TOMOYO can be used without the "support" by
Red Hat). As a result, users cannot try LSMs (either in-tree or out-of-tree)
other than SELinux.
The negative effect is not limited to TOMOYO.
Like Paul Moore said
However, I will caution that it is becoming increasingly difficult for people
to find time to review potential new LSMs so it may a while to attract sufficient
comments and feedback.
, being unable to legally use loadable LSMs deprives of chances to develop/try
new LSMs, and makes LSM interface more and more unattractive. The consequence
would be "The LSM interface is dead. We will give up implementing as LSMs."
It is exactly "only in-tree and supported by distributors is correct" crap.
I don't like closed-source kernel modules that rewrite syscall tables (e.g.
used by AntiVirus), for I can't analyze problems when something went wrong.
If LSMs were available to open-source out-of-tree kernel modules, this situation
could be improved.
I think that syzbot is the most aggressive tester of TOMOYO security module.
But how many bugs did syzbot found in TOMOYO? How many distributors that
enabled TOMOYO in their kernels got bug reports regarding TOMOYO?
There might be reports like "When do you start providing ready-made policy
configurations?", but what Josh Boyer worried at
https://bugzilla.redhat.com/show_bug.cgi?id=542986#c8
Simply put, we do not have the time to deal with any potential kernel bug
reports that would come from enabling TOMOYO. It would be a disservice to
our users to enable something we have no intention of attempting to fix
when it is broken.
did not happen, and
Even if it was 100% perfect code and caused no bug reports for the kernel,
it is still bloat and while it might not seem like it we are actually
trying to cut down on the size of our installed kernels.
can be solved by allowing loadable module LSMs.
Loadable module LSM also breaks distributor's "enable" == "support" spell.
> A loadable module would have to be managed differently from a built-in one.
> Hence the notion of a loadable module manager.
We can make management up to module authors, like the comment of security_delete_hooks().
(Well, I'm not proposing ability to unload. I'm proposing only ability to load LSMs
as loadable kernel modules.)
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-09-14 13:57 ` Tetsuo Handa
0 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-09-14 13:57 UTC (permalink / raw)
To: Casey Schaufler, Paul Moore
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On 2022/09/13 23:45, Casey Schaufler wrote:
>> . A security module that manages loadable LSM modules cannot give us a good answer
>> if there is a kernel config option to disable the manager security module.
>
> The community that is absolutely opposed to loadable modules will disagree.
Who are members of that community?
Hiding security_hook_heads from /proc/kallsyms has no value from security
perspective, for malicious loadable kernel modules can calculate the address
of security_hook_heads based on addresses of relevant functions and byte-code
in the relevant functions.
Keeping __lsm_ro_after_init might have a little value, but at the same time
it might make kernel less secure (or more prone to memory corruption) due to
the need to pass rodata=0 kernel command line option when a loadable module
LSM is loaded.
>> The kernel config option and distribution's policy are preventing users from using
>> non-builtin LSMs in distributor's kernels. It is a trivial task to make TOMOYO work
>> in distributor's kernels if above-mentioned changes are accepted.
>
> You should be able to use TOMOYO as a built-in along side other security modules
> today. Aside from getting the distribution to include it in their kernel
> configuration, which is admittedly no mean feat, and getting any user-space you
> need included, you should already have what you need.
That's a chicken-and-egg problem.
Yes, we can use TOMOYO as a built-in along side other security modules for
_user-built_ kernels. But no, we can't use TOMOYO for _distributor-built_ kernels
(namely, Fedora/CentOS Stream/RHEL kernels).
>> https://bugzilla.redhat.com/show_bug.cgi?id=542986
>
> Ten years ago they said "Don't want to, aren't going to". Sadly, I doubt
> there would be a different attitude today. The decision to support a security
> module in a distribution is serious. I can definitely see how Redhat would
> have their hands full supporting SELinux.
Please distinguish the difference between "enable" and "support" at
https://bugzilla.redhat.com/show_bug.cgi?id=542986#c7 . (By the way,
I hate the word "support", for nobody can share agreed definition.)
"enable" is something like "available", "allow to exist".
"support" is something like "guaranteed", "provide efforts for fixing bugs".
However, in the Red Hat's world, "enable" == "support". The kernel config options
enabled by Red Hat is supported by Red Hat, and the kernel config options Red Hat
cannot support cannot be enabled by Red Hat.
On the contrary, in the vanilla kernel's world, the in-tree version of TOMOYO
cannot be built as a loadable module LSM. And it is impossible to built TOMOYO
as a loadable module LSM (so that TOMOYO can be used without the "support" by
Red Hat). As a result, users cannot try LSMs (either in-tree or out-of-tree)
other than SELinux.
The negative effect is not limited to TOMOYO.
Like Paul Moore said
However, I will caution that it is becoming increasingly difficult for people
to find time to review potential new LSMs so it may a while to attract sufficient
comments and feedback.
, being unable to legally use loadable LSMs deprives of chances to develop/try
new LSMs, and makes LSM interface more and more unattractive. The consequence
would be "The LSM interface is dead. We will give up implementing as LSMs."
It is exactly "only in-tree and supported by distributors is correct" crap.
I don't like closed-source kernel modules that rewrite syscall tables (e.g.
used by AntiVirus), for I can't analyze problems when something went wrong.
If LSMs were available to open-source out-of-tree kernel modules, this situation
could be improved.
I think that syzbot is the most aggressive tester of TOMOYO security module.
But how many bugs did syzbot found in TOMOYO? How many distributors that
enabled TOMOYO in their kernels got bug reports regarding TOMOYO?
There might be reports like "When do you start providing ready-made policy
configurations?", but what Josh Boyer worried at
https://bugzilla.redhat.com/show_bug.cgi?id=542986#c8
Simply put, we do not have the time to deal with any potential kernel bug
reports that would come from enabling TOMOYO. It would be a disservice to
our users to enable something we have no intention of attempting to fix
when it is broken.
did not happen, and
Even if it was 100% perfect code and caused no bug reports for the kernel,
it is still bloat and while it might not seem like it we are actually
trying to cut down on the size of our installed kernels.
can be solved by allowing loadable module LSMs.
Loadable module LSM also breaks distributor's "enable" == "support" spell.
> A loadable module would have to be managed differently from a built-in one.
> Hence the notion of a loadable module manager.
We can make management up to module authors, like the comment of security_delete_hooks().
(Well, I'm not proposing ability to unload. I'm proposing only ability to load LSMs
as loadable kernel modules.)
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-14 13:57 ` Tetsuo Handa
@ 2022-09-14 15:50 ` Casey Schaufler
-1 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-14 15:50 UTC (permalink / raw)
To: Tetsuo Handa, Paul Moore
Cc: John Johansen, LSM List, James Morris, linux-audit, Mimi Zohar,
keescook, SElinux list, casey
On 9/14/2022 6:57 AM, Tetsuo Handa wrote:
> On 2022/09/13 23:45, Casey Schaufler wrote:
>>> . A security module that manages loadable LSM modules cannot give us a good answer
>>> if there is a kernel config option to disable the manager security module.
>> The community that is absolutely opposed to loadable modules will disagree.
> Who are members of that community?
>
> Hiding security_hook_heads from /proc/kallsyms has no value from security
> perspective, for malicious loadable kernel modules can calculate the address
> of security_hook_heads based on addresses of relevant functions and byte-code
> in the relevant functions.
>
> Keeping __lsm_ro_after_init might have a little value, but at the same time
> it might make kernel less secure (or more prone to memory corruption) due to
> the need to pass rodata=0 kernel command line option when a loadable module
> LSM is loaded.
>
>
>
>>> The kernel config option and distribution's policy are preventing users from using
>>> non-builtin LSMs in distributor's kernels. It is a trivial task to make TOMOYO work
>>> in distributor's kernels if above-mentioned changes are accepted.
>> You should be able to use TOMOYO as a built-in along side other security modules
>> today. Aside from getting the distribution to include it in their kernel
>> configuration, which is admittedly no mean feat, and getting any user-space you
>> need included, you should already have what you need.
> That's a chicken-and-egg problem.
>
> Yes, we can use TOMOYO as a built-in along side other security modules for
> _user-built_ kernels. But no, we can't use TOMOYO for _distributor-built_ kernels
> (namely, Fedora/CentOS Stream/RHEL kernels).
>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=542986
>> Ten years ago they said "Don't want to, aren't going to". Sadly, I doubt
>> there would be a different attitude today. The decision to support a security
>> module in a distribution is serious. I can definitely see how Redhat would
>> have their hands full supporting SELinux.
> Please distinguish the difference between "enable" and "support" at
> https://bugzilla.redhat.com/show_bug.cgi?id=542986#c7 . (By the way,
> I hate the word "support", for nobody can share agreed definition.)
>
> "enable" is something like "available", "allow to exist".
>
> "support" is something like "guaranteed", "provide efforts for fixing bugs".
>
> However, in the Red Hat's world, "enable" == "support". The kernel config options
> enabled by Red Hat is supported by Red Hat, and the kernel config options Red Hat
> cannot support cannot be enabled by Red Hat.
The "enable" == "support" model in consistent with the expectations of
paying customers.
> On the contrary, in the vanilla kernel's world, the in-tree version of TOMOYO
> cannot be built as a loadable module LSM. And it is impossible to built TOMOYO
> as a loadable module LSM (so that TOMOYO can be used without the "support" by
> Red Hat). As a result, users cannot try LSMs (either in-tree or out-of-tree)
> other than SELinux.
That is correct. Redhat has chosen to support only SELinux. If you want
TOMOYO to be enabled in a distribution you need to sell the value to a
distributor (really, really hard) Or (not recommended) become one yourself.
> The negative effect is not limited to TOMOYO.
> Like Paul Moore said
>
> However, I will caution that it is becoming increasingly difficult for people
> to find time to review potential new LSMs so it may a while to attract sufficient
> comments and feedback.
>
> , being unable to legally use loadable LSMs deprives of chances to develop/try
> new LSMs, and makes LSM interface more and more unattractive. The consequence
> would be "The LSM interface is dead. We will give up implementing as LSMs."
>
> It is exactly "only in-tree and supported by distributors is correct" crap.
That's not quite the position. "Only in-tree, and someone has to want to use it
in the real world" is more accurate. Android isn't a distribution, neither is
Tizen. Having a major distributor include the LSM is a big plus.
>
> I don't like closed-source kernel modules that rewrite syscall tables (e.g.
> used by AntiVirus), for I can't analyze problems when something went wrong.
> If LSMs were available to open-source out-of-tree kernel modules, this situation
> could be improved.
>
>
>
> I think that syzbot is the most aggressive tester of TOMOYO security module.
> But how many bugs did syzbot found in TOMOYO? How many distributors that
> enabled TOMOYO in their kernels got bug reports regarding TOMOYO?
>
> There might be reports like "When do you start providing ready-made policy
> configurations?", but what Josh Boyer worried at
> https://bugzilla.redhat.com/show_bug.cgi?id=542986#c8
>
> Simply put, we do not have the time to deal with any potential kernel bug
> reports that would come from enabling TOMOYO. It would be a disservice to
> our users to enable something we have no intention of attempting to fix
> when it is broken.
>
> did not happen, and
>
> Even if it was 100% perfect code and caused no bug reports for the kernel,
> it is still bloat and while it might not seem like it we are actually
> trying to cut down on the size of our installed kernels.
>
> can be solved by allowing loadable module LSMs.
>
> Loadable module LSM also breaks distributor's "enable" == "support" spell.
It sure does. I'm waiting to see what happens if eBPF security modules
become popular. I can easily see distributions turning the BPF LSM off.
>> A loadable module would have to be managed differently from a built-in one.
>> Hence the notion of a loadable module manager.
> We can make management up to module authors, like the comment of security_delete_hooks().
> (Well, I'm not proposing ability to unload. I'm proposing only ability to load LSMs
> as loadable kernel modules.)
Exactly. A module would have to chose between being built-in and being loadable.
Before I go any further, I think that the loadable module manager LSM would be
very hard to get upstream. Most of the arguments against general support for
loadable modules would still apply. It is possible that an acceptable module
could be created, but it would have to address a lot of issues. It is a challenge
I don't expect to accept in this lifetime.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-09-14 15:50 ` Casey Schaufler
0 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-14 15:50 UTC (permalink / raw)
To: Tetsuo Handa, Paul Moore
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On 9/14/2022 6:57 AM, Tetsuo Handa wrote:
> On 2022/09/13 23:45, Casey Schaufler wrote:
>>> . A security module that manages loadable LSM modules cannot give us a good answer
>>> if there is a kernel config option to disable the manager security module.
>> The community that is absolutely opposed to loadable modules will disagree.
> Who are members of that community?
>
> Hiding security_hook_heads from /proc/kallsyms has no value from security
> perspective, for malicious loadable kernel modules can calculate the address
> of security_hook_heads based on addresses of relevant functions and byte-code
> in the relevant functions.
>
> Keeping __lsm_ro_after_init might have a little value, but at the same time
> it might make kernel less secure (or more prone to memory corruption) due to
> the need to pass rodata=0 kernel command line option when a loadable module
> LSM is loaded.
>
>
>
>>> The kernel config option and distribution's policy are preventing users from using
>>> non-builtin LSMs in distributor's kernels. It is a trivial task to make TOMOYO work
>>> in distributor's kernels if above-mentioned changes are accepted.
>> You should be able to use TOMOYO as a built-in along side other security modules
>> today. Aside from getting the distribution to include it in their kernel
>> configuration, which is admittedly no mean feat, and getting any user-space you
>> need included, you should already have what you need.
> That's a chicken-and-egg problem.
>
> Yes, we can use TOMOYO as a built-in along side other security modules for
> _user-built_ kernels. But no, we can't use TOMOYO for _distributor-built_ kernels
> (namely, Fedora/CentOS Stream/RHEL kernels).
>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=542986
>> Ten years ago they said "Don't want to, aren't going to". Sadly, I doubt
>> there would be a different attitude today. The decision to support a security
>> module in a distribution is serious. I can definitely see how Redhat would
>> have their hands full supporting SELinux.
> Please distinguish the difference between "enable" and "support" at
> https://bugzilla.redhat.com/show_bug.cgi?id=542986#c7 . (By the way,
> I hate the word "support", for nobody can share agreed definition.)
>
> "enable" is something like "available", "allow to exist".
>
> "support" is something like "guaranteed", "provide efforts for fixing bugs".
>
> However, in the Red Hat's world, "enable" == "support". The kernel config options
> enabled by Red Hat is supported by Red Hat, and the kernel config options Red Hat
> cannot support cannot be enabled by Red Hat.
The "enable" == "support" model in consistent with the expectations of
paying customers.
> On the contrary, in the vanilla kernel's world, the in-tree version of TOMOYO
> cannot be built as a loadable module LSM. And it is impossible to built TOMOYO
> as a loadable module LSM (so that TOMOYO can be used without the "support" by
> Red Hat). As a result, users cannot try LSMs (either in-tree or out-of-tree)
> other than SELinux.
That is correct. Redhat has chosen to support only SELinux. If you want
TOMOYO to be enabled in a distribution you need to sell the value to a
distributor (really, really hard) Or (not recommended) become one yourself.
> The negative effect is not limited to TOMOYO.
> Like Paul Moore said
>
> However, I will caution that it is becoming increasingly difficult for people
> to find time to review potential new LSMs so it may a while to attract sufficient
> comments and feedback.
>
> , being unable to legally use loadable LSMs deprives of chances to develop/try
> new LSMs, and makes LSM interface more and more unattractive. The consequence
> would be "The LSM interface is dead. We will give up implementing as LSMs."
>
> It is exactly "only in-tree and supported by distributors is correct" crap.
That's not quite the position. "Only in-tree, and someone has to want to use it
in the real world" is more accurate. Android isn't a distribution, neither is
Tizen. Having a major distributor include the LSM is a big plus.
>
> I don't like closed-source kernel modules that rewrite syscall tables (e.g.
> used by AntiVirus), for I can't analyze problems when something went wrong.
> If LSMs were available to open-source out-of-tree kernel modules, this situation
> could be improved.
>
>
>
> I think that syzbot is the most aggressive tester of TOMOYO security module.
> But how many bugs did syzbot found in TOMOYO? How many distributors that
> enabled TOMOYO in their kernels got bug reports regarding TOMOYO?
>
> There might be reports like "When do you start providing ready-made policy
> configurations?", but what Josh Boyer worried at
> https://bugzilla.redhat.com/show_bug.cgi?id=542986#c8
>
> Simply put, we do not have the time to deal with any potential kernel bug
> reports that would come from enabling TOMOYO. It would be a disservice to
> our users to enable something we have no intention of attempting to fix
> when it is broken.
>
> did not happen, and
>
> Even if it was 100% perfect code and caused no bug reports for the kernel,
> it is still bloat and while it might not seem like it we are actually
> trying to cut down on the size of our installed kernels.
>
> can be solved by allowing loadable module LSMs.
>
> Loadable module LSM also breaks distributor's "enable" == "support" spell.
It sure does. I'm waiting to see what happens if eBPF security modules
become popular. I can easily see distributions turning the BPF LSM off.
>> A loadable module would have to be managed differently from a built-in one.
>> Hence the notion of a loadable module manager.
> We can make management up to module authors, like the comment of security_delete_hooks().
> (Well, I'm not proposing ability to unload. I'm proposing only ability to load LSMs
> as loadable kernel modules.)
Exactly. A module would have to chose between being built-in and being loadable.
Before I go any further, I think that the loadable module manager LSM would be
very hard to get upstream. Most of the arguments against general support for
loadable modules would still apply. It is possible that an acceptable module
could be created, but it would have to address a lot of issues. It is a challenge
I don't expect to accept in this lifetime.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-14 15:50 ` Casey Schaufler
@ 2022-09-15 14:27 ` Tetsuo Handa
-1 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-09-15 14:27 UTC (permalink / raw)
To: Casey Schaufler, Paul Moore
Cc: John Johansen, LSM List, James Morris, linux-audit, Mimi Zohar,
keescook, SElinux list
On 2022/09/15 0:50, Casey Schaufler wrote:
> On 9/14/2022 6:57 AM, Tetsuo Handa wrote:
>> Please distinguish the difference between "enable" and "support" at
>> https://bugzilla.redhat.com/show_bug.cgi?id=542986#c7 . (By the way,
>> I hate the word "support", for nobody can share agreed definition.)
>>
>> "enable" is something like "available", "allow to exist".
>>
>> "support" is something like "guaranteed", "provide efforts for fixing bugs".
>>
>> However, in the Red Hat's world, "enable" == "support". The kernel config options
>> enabled by Red Hat is supported by Red Hat, and the kernel config options Red Hat
>> cannot support cannot be enabled by Red Hat.
>
> The "enable" == "support" model in consistent with the expectations of
> paying customers.
Regarding CONFIG_MODULES=y,
"Vendor-A enables module-A" == "Vendor-A provides support for module-A" and
"Vendor-B enables module-B" == "Vendor-B provides support for module-B".
Regarding CONFIG_SECURITY=y (namely in the RH world),
"Distributor-A enables LSM-A" == "Distributor-A provides support for LSM-A".
However, "Distributor-A does not enable LSM-B" == "Some vendor is impossible to
provide support for LSM-B".
"Distributor-A does not enable module-B" == "Distributor-A is not responsible for
providing support for module-B" and "Vendor-B enables LSM-B" == "Vendor-B provides
support for LSM-B" are what I expect.
Current LSM interface does not allow LSM-B to exist in Distributor-A's systems.
The "enable" == "support" model should be allowed for LSM interface as well.
What a strange asymmetry rule!
>> On the contrary, in the vanilla kernel's world, the in-tree version of TOMOYO
>> cannot be built as a loadable module LSM. And it is impossible to built TOMOYO
>> as a loadable module LSM (so that TOMOYO can be used without the "support" by
>> Red Hat). As a result, users cannot try LSMs (either in-tree or out-of-tree)
>> other than SELinux.
>
> That is correct. Redhat has chosen to support only SELinux. If you want
> TOMOYO to be enabled in a distribution you need to sell the value to a
> distributor (really, really hard) Or (not recommended) become one yourself.
What I'm asking is "allow non-SELinux to exist in RH systems".
I'm not asking RH to "provide efforts for fixing non-SELinux".
Being able to build in-tree version of TOMOYO via "make M=security/tomoyo"
releases RH from the "enable" == "support" spell.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-09-15 14:27 ` Tetsuo Handa
0 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-09-15 14:27 UTC (permalink / raw)
To: Casey Schaufler, Paul Moore
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On 2022/09/15 0:50, Casey Schaufler wrote:
> On 9/14/2022 6:57 AM, Tetsuo Handa wrote:
>> Please distinguish the difference between "enable" and "support" at
>> https://bugzilla.redhat.com/show_bug.cgi?id=542986#c7 . (By the way,
>> I hate the word "support", for nobody can share agreed definition.)
>>
>> "enable" is something like "available", "allow to exist".
>>
>> "support" is something like "guaranteed", "provide efforts for fixing bugs".
>>
>> However, in the Red Hat's world, "enable" == "support". The kernel config options
>> enabled by Red Hat is supported by Red Hat, and the kernel config options Red Hat
>> cannot support cannot be enabled by Red Hat.
>
> The "enable" == "support" model in consistent with the expectations of
> paying customers.
Regarding CONFIG_MODULES=y,
"Vendor-A enables module-A" == "Vendor-A provides support for module-A" and
"Vendor-B enables module-B" == "Vendor-B provides support for module-B".
Regarding CONFIG_SECURITY=y (namely in the RH world),
"Distributor-A enables LSM-A" == "Distributor-A provides support for LSM-A".
However, "Distributor-A does not enable LSM-B" == "Some vendor is impossible to
provide support for LSM-B".
"Distributor-A does not enable module-B" == "Distributor-A is not responsible for
providing support for module-B" and "Vendor-B enables LSM-B" == "Vendor-B provides
support for LSM-B" are what I expect.
Current LSM interface does not allow LSM-B to exist in Distributor-A's systems.
The "enable" == "support" model should be allowed for LSM interface as well.
What a strange asymmetry rule!
>> On the contrary, in the vanilla kernel's world, the in-tree version of TOMOYO
>> cannot be built as a loadable module LSM. And it is impossible to built TOMOYO
>> as a loadable module LSM (so that TOMOYO can be used without the "support" by
>> Red Hat). As a result, users cannot try LSMs (either in-tree or out-of-tree)
>> other than SELinux.
>
> That is correct. Redhat has chosen to support only SELinux. If you want
> TOMOYO to be enabled in a distribution you need to sell the value to a
> distributor (really, really hard) Or (not recommended) become one yourself.
What I'm asking is "allow non-SELinux to exist in RH systems".
I'm not asking RH to "provide efforts for fixing non-SELinux".
Being able to build in-tree version of TOMOYO via "make M=security/tomoyo"
releases RH from the "enable" == "support" spell.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-15 14:27 ` Tetsuo Handa
@ 2022-09-15 14:54 ` John Johansen
-1 siblings, 0 replies; 148+ messages in thread
From: John Johansen @ 2022-09-15 14:54 UTC (permalink / raw)
To: Tetsuo Handa, Casey Schaufler, Paul Moore
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook, SElinux list
On 9/15/22 07:27, Tetsuo Handa wrote:
> On 2022/09/15 0:50, Casey Schaufler wrote:
>> On 9/14/2022 6:57 AM, Tetsuo Handa wrote:
>>> Please distinguish the difference between "enable" and "support" at
>>> https://bugzilla.redhat.com/show_bug.cgi?id=542986#c7 . (By the way,
>>> I hate the word "support", for nobody can share agreed definition.)
>>>
>>> "enable" is something like "available", "allow to exist".
>>>
>>> "support" is something like "guaranteed", "provide efforts for fixing bugs".
>>>
>>> However, in the Red Hat's world, "enable" == "support". The kernel config options
>>> enabled by Red Hat is supported by Red Hat, and the kernel config options Red Hat
>>> cannot support cannot be enabled by Red Hat.
>>
>> The "enable" == "support" model in consistent with the expectations of
>> paying customers.
>
> Regarding CONFIG_MODULES=y,
> "Vendor-A enables module-A" == "Vendor-A provides support for module-A" and
> "Vendor-B enables module-B" == "Vendor-B provides support for module-B".
>
> Regarding CONFIG_SECURITY=y (namely in the RH world),
> "Distributor-A enables LSM-A" == "Distributor-A provides support for LSM-A".
> However, "Distributor-A does not enable LSM-B" == "Some vendor is impossible to
> provide support for LSM-B".
>
> "Distributor-A does not enable module-B" == "Distributor-A is not responsible for
> providing support for module-B" and "Vendor-B enables LSM-B" == "Vendor-B provides
> support for LSM-B" are what I expect.
>
> Current LSM interface does not allow LSM-B to exist in Distributor-A's systems.
> The "enable" == "support" model should be allowed for LSM interface as well.
> What a strange asymmetry rule!
>
>
>
>>> On the contrary, in the vanilla kernel's world, the in-tree version of TOMOYO
>>> cannot be built as a loadable module LSM. And it is impossible to built TOMOYO
>>> as a loadable module LSM (so that TOMOYO can be used without the "support" by
>>> Red Hat). As a result, users cannot try LSMs (either in-tree or out-of-tree)
>>> other than SELinux.
>>
>> That is correct. Redhat has chosen to support only SELinux. If you want
>> TOMOYO to be enabled in a distribution you need to sell the value to a
>> distributor (really, really hard) Or (not recommended) become one yourself.
>
> What I'm asking is "allow non-SELinux to exist in RH systems".
> I'm not asking RH to "provide efforts for fixing non-SELinux".
> Being able to build in-tree version of TOMOYO via "make M=security/tomoyo"
> releases RH from the "enable" == "support" spell.
>
I am sympathetic, I want this too. But RH choices are not a technical problem,
they could easily enable and not support other LSMs (eg. Ubuntu does). It is a
political problem and I don't see loadable LSMs changing this.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-09-15 14:54 ` John Johansen
0 siblings, 0 replies; 148+ messages in thread
From: John Johansen @ 2022-09-15 14:54 UTC (permalink / raw)
To: Tetsuo Handa, Casey Schaufler, Paul Moore
Cc: SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On 9/15/22 07:27, Tetsuo Handa wrote:
> On 2022/09/15 0:50, Casey Schaufler wrote:
>> On 9/14/2022 6:57 AM, Tetsuo Handa wrote:
>>> Please distinguish the difference between "enable" and "support" at
>>> https://bugzilla.redhat.com/show_bug.cgi?id=542986#c7 . (By the way,
>>> I hate the word "support", for nobody can share agreed definition.)
>>>
>>> "enable" is something like "available", "allow to exist".
>>>
>>> "support" is something like "guaranteed", "provide efforts for fixing bugs".
>>>
>>> However, in the Red Hat's world, "enable" == "support". The kernel config options
>>> enabled by Red Hat is supported by Red Hat, and the kernel config options Red Hat
>>> cannot support cannot be enabled by Red Hat.
>>
>> The "enable" == "support" model in consistent with the expectations of
>> paying customers.
>
> Regarding CONFIG_MODULES=y,
> "Vendor-A enables module-A" == "Vendor-A provides support for module-A" and
> "Vendor-B enables module-B" == "Vendor-B provides support for module-B".
>
> Regarding CONFIG_SECURITY=y (namely in the RH world),
> "Distributor-A enables LSM-A" == "Distributor-A provides support for LSM-A".
> However, "Distributor-A does not enable LSM-B" == "Some vendor is impossible to
> provide support for LSM-B".
>
> "Distributor-A does not enable module-B" == "Distributor-A is not responsible for
> providing support for module-B" and "Vendor-B enables LSM-B" == "Vendor-B provides
> support for LSM-B" are what I expect.
>
> Current LSM interface does not allow LSM-B to exist in Distributor-A's systems.
> The "enable" == "support" model should be allowed for LSM interface as well.
> What a strange asymmetry rule!
>
>
>
>>> On the contrary, in the vanilla kernel's world, the in-tree version of TOMOYO
>>> cannot be built as a loadable module LSM. And it is impossible to built TOMOYO
>>> as a loadable module LSM (so that TOMOYO can be used without the "support" by
>>> Red Hat). As a result, users cannot try LSMs (either in-tree or out-of-tree)
>>> other than SELinux.
>>
>> That is correct. Redhat has chosen to support only SELinux. If you want
>> TOMOYO to be enabled in a distribution you need to sell the value to a
>> distributor (really, really hard) Or (not recommended) become one yourself.
>
> What I'm asking is "allow non-SELinux to exist in RH systems".
> I'm not asking RH to "provide efforts for fixing non-SELinux".
> Being able to build in-tree version of TOMOYO via "make M=security/tomoyo"
> releases RH from the "enable" == "support" spell.
>
I am sympathetic, I want this too. But RH choices are not a technical problem,
they could easily enable and not support other LSMs (eg. Ubuntu does). It is a
political problem and I don't see loadable LSMs changing this.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-14 13:57 ` Tetsuo Handa
@ 2022-09-15 7:45 ` John Johansen
-1 siblings, 0 replies; 148+ messages in thread
From: John Johansen @ 2022-09-15 7:45 UTC (permalink / raw)
To: Tetsuo Handa, Casey Schaufler, Paul Moore
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook, SElinux list
On 9/14/22 06:57, Tetsuo Handa wrote:
> On 2022/09/13 23:45, Casey Schaufler wrote:
>>> . A security module that manages loadable LSM modules cannot give us a good answer
>>> if there is a kernel config option to disable the manager security module.
>>
>> The community that is absolutely opposed to loadable modules will disagree.
>
> Who are members of that community?
>
> Hiding security_hook_heads from /proc/kallsyms has no value from security
> perspective, for malicious loadable kernel modules can calculate the address
> of security_hook_heads based on addresses of relevant functions and byte-code
> in the relevant functions.
>
> Keeping __lsm_ro_after_init might have a little value, but at the same time
> it might make kernel less secure (or more prone to memory corruption) due to
> the need to pass rodata=0 kernel command line option when a loadable module
> LSM is loaded.
>
>
>
>>> The kernel config option and distribution's policy are preventing users from using
>>> non-builtin LSMs in distributor's kernels. It is a trivial task to make TOMOYO work
>>> in distributor's kernels if above-mentioned changes are accepted.
>>
>> You should be able to use TOMOYO as a built-in along side other security modules
>> today. Aside from getting the distribution to include it in their kernel
>> configuration, which is admittedly no mean feat, and getting any user-space you
>> need included, you should already have what you need.
>
> That's a chicken-and-egg problem.
>
> Yes, we can use TOMOYO as a built-in along side other security modules for
> _user-built_ kernels. But no, we can't use TOMOYO for _distributor-built_ kernels
> (namely, Fedora/CentOS Stream/RHEL kernels).
>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=542986
>>
>> Ten years ago they said "Don't want to, aren't going to". Sadly, I doubt
>> there would be a different attitude today. The decision to support a security
>> module in a distribution is serious. I can definitely see how Redhat would
>> have their hands full supporting SELinux.
>
> Please distinguish the difference between "enable" and "support" at
> https://bugzilla.redhat.com/show_bug.cgi?id=542986#c7 . (By the way,
> I hate the word "support", for nobody can share agreed definition.)
>
> "enable" is something like "available", "allow to exist".
>
> "support" is something like "guaranteed", "provide efforts for fixing bugs".
>
> However, in the Red Hat's world, "enable" == "support". The kernel config options
> enabled by Red Hat is supported by Red Hat, and the kernel config options Red Hat
> cannot support cannot be enabled by Red Hat.
>
> On the contrary, in the vanilla kernel's world, the in-tree version of TOMOYO
> cannot be built as a loadable module LSM. And it is impossible to built TOMOYO
> as a loadable module LSM (so that TOMOYO can be used without the "support" by
> Red Hat). As a result, users cannot try LSMs (either in-tree or out-of-tree)
> other than SELinux.
>
> The negative effect is not limited to TOMOYO.
> Like Paul Moore said
>
> However, I will caution that it is becoming increasingly difficult for people
> to find time to review potential new LSMs so it may a while to attract sufficient
> comments and feedback.
>
> , being unable to legally use loadable LSMs deprives of chances to develop/try
> new LSMs, and makes LSM interface more and more unattractive. The consequence
> would be "The LSM interface is dead. We will give up implementing as LSMs."
>
> It is exactly "only in-tree and supported by distributors is correct" crap.
>
for some users, but having a very well defined support surface also has its
place. From a distro POV support is expensive and its amazing what users
will do and try to hide while trying to get support.
Personally I prefer splitting enable and support but there are situations
where that isn't even allowed (some certifications). So I can understand
where they are coming from.
It just sucks for the users and projects that aren't "supported".
> I don't like closed-source kernel modules that rewrite syscall tables (e.g.
> used by AntiVirus), for I can't analyze problems when something went wrong.
Does anyone?
> If LSMs were available to open-source out-of-tree kernel modules, this situation
> could be improved.
>
you are more optimistic than I am. What makes you think a distro like RH will
enable loading out-of-tree kernel modules if they aren't enabling TOMOYO
that is already in the kernel.
If loadable LSM modules are allowed, there will likely be a kernel config
to disable them and there will definitely be an interface that allows
blocking them. So whether via config option or run time control I don't
see RH allowing them.
>
>
> I think that syzbot is the most aggressive tester of TOMOYO security module.
> But how many bugs did syzbot found in TOMOYO? How many distributors that
> enabled TOMOYO in their kernels got bug reports regarding TOMOYO?
>
> There might be reports like "When do you start providing ready-made policy
> configurations?", but what Josh Boyer worried at
> https://bugzilla.redhat.com/show_bug.cgi?id=542986#c8
>
> Simply put, we do not have the time to deal with any potential kernel bug
> reports that would come from enabling TOMOYO. It would be a disservice to
> our users to enable something we have no intention of attempting to fix
> when it is broken.
>
> did not happen, and
>
> Even if it was 100% perfect code and caused no bug reports for the kernel,
> it is still bloat and while it might not seem like it we are actually
> trying to cut down on the size of our installed kernels.
>
> can be solved by allowing loadable module LSMs.
>
> Loadable module LSM also breaks distributor's "enable" == "support" spell.
>
sadly I really don't think it will
>
>
>> A loadable module would have to be managed differently from a built-in one.
>> Hence the notion of a loadable module manager.
>
> We can make management up to module authors, like the comment of security_delete_hooks().
> (Well, I'm not proposing ability to unload. I'm proposing only ability to load LSMs
> as loadable kernel modules.)
>
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-09-15 7:45 ` John Johansen
0 siblings, 0 replies; 148+ messages in thread
From: John Johansen @ 2022-09-15 7:45 UTC (permalink / raw)
To: Tetsuo Handa, Casey Schaufler, Paul Moore
Cc: SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On 9/14/22 06:57, Tetsuo Handa wrote:
> On 2022/09/13 23:45, Casey Schaufler wrote:
>>> . A security module that manages loadable LSM modules cannot give us a good answer
>>> if there is a kernel config option to disable the manager security module.
>>
>> The community that is absolutely opposed to loadable modules will disagree.
>
> Who are members of that community?
>
> Hiding security_hook_heads from /proc/kallsyms has no value from security
> perspective, for malicious loadable kernel modules can calculate the address
> of security_hook_heads based on addresses of relevant functions and byte-code
> in the relevant functions.
>
> Keeping __lsm_ro_after_init might have a little value, but at the same time
> it might make kernel less secure (or more prone to memory corruption) due to
> the need to pass rodata=0 kernel command line option when a loadable module
> LSM is loaded.
>
>
>
>>> The kernel config option and distribution's policy are preventing users from using
>>> non-builtin LSMs in distributor's kernels. It is a trivial task to make TOMOYO work
>>> in distributor's kernels if above-mentioned changes are accepted.
>>
>> You should be able to use TOMOYO as a built-in along side other security modules
>> today. Aside from getting the distribution to include it in their kernel
>> configuration, which is admittedly no mean feat, and getting any user-space you
>> need included, you should already have what you need.
>
> That's a chicken-and-egg problem.
>
> Yes, we can use TOMOYO as a built-in along side other security modules for
> _user-built_ kernels. But no, we can't use TOMOYO for _distributor-built_ kernels
> (namely, Fedora/CentOS Stream/RHEL kernels).
>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=542986
>>
>> Ten years ago they said "Don't want to, aren't going to". Sadly, I doubt
>> there would be a different attitude today. The decision to support a security
>> module in a distribution is serious. I can definitely see how Redhat would
>> have their hands full supporting SELinux.
>
> Please distinguish the difference between "enable" and "support" at
> https://bugzilla.redhat.com/show_bug.cgi?id=542986#c7 . (By the way,
> I hate the word "support", for nobody can share agreed definition.)
>
> "enable" is something like "available", "allow to exist".
>
> "support" is something like "guaranteed", "provide efforts for fixing bugs".
>
> However, in the Red Hat's world, "enable" == "support". The kernel config options
> enabled by Red Hat is supported by Red Hat, and the kernel config options Red Hat
> cannot support cannot be enabled by Red Hat.
>
> On the contrary, in the vanilla kernel's world, the in-tree version of TOMOYO
> cannot be built as a loadable module LSM. And it is impossible to built TOMOYO
> as a loadable module LSM (so that TOMOYO can be used without the "support" by
> Red Hat). As a result, users cannot try LSMs (either in-tree or out-of-tree)
> other than SELinux.
>
> The negative effect is not limited to TOMOYO.
> Like Paul Moore said
>
> However, I will caution that it is becoming increasingly difficult for people
> to find time to review potential new LSMs so it may a while to attract sufficient
> comments and feedback.
>
> , being unable to legally use loadable LSMs deprives of chances to develop/try
> new LSMs, and makes LSM interface more and more unattractive. The consequence
> would be "The LSM interface is dead. We will give up implementing as LSMs."
>
> It is exactly "only in-tree and supported by distributors is correct" crap.
>
for some users, but having a very well defined support surface also has its
place. From a distro POV support is expensive and its amazing what users
will do and try to hide while trying to get support.
Personally I prefer splitting enable and support but there are situations
where that isn't even allowed (some certifications). So I can understand
where they are coming from.
It just sucks for the users and projects that aren't "supported".
> I don't like closed-source kernel modules that rewrite syscall tables (e.g.
> used by AntiVirus), for I can't analyze problems when something went wrong.
Does anyone?
> If LSMs were available to open-source out-of-tree kernel modules, this situation
> could be improved.
>
you are more optimistic than I am. What makes you think a distro like RH will
enable loading out-of-tree kernel modules if they aren't enabling TOMOYO
that is already in the kernel.
If loadable LSM modules are allowed, there will likely be a kernel config
to disable them and there will definitely be an interface that allows
blocking them. So whether via config option or run time control I don't
see RH allowing them.
>
>
> I think that syzbot is the most aggressive tester of TOMOYO security module.
> But how many bugs did syzbot found in TOMOYO? How many distributors that
> enabled TOMOYO in their kernels got bug reports regarding TOMOYO?
>
> There might be reports like "When do you start providing ready-made policy
> configurations?", but what Josh Boyer worried at
> https://bugzilla.redhat.com/show_bug.cgi?id=542986#c8
>
> Simply put, we do not have the time to deal with any potential kernel bug
> reports that would come from enabling TOMOYO. It would be a disservice to
> our users to enable something we have no intention of attempting to fix
> when it is broken.
>
> did not happen, and
>
> Even if it was 100% perfect code and caused no bug reports for the kernel,
> it is still bloat and while it might not seem like it we are actually
> trying to cut down on the size of our installed kernels.
>
> can be solved by allowing loadable module LSMs.
>
> Loadable module LSM also breaks distributor's "enable" == "support" spell.
>
sadly I really don't think it will
>
>
>> A loadable module would have to be managed differently from a built-in one.
>> Hence the notion of a loadable module manager.
>
> We can make management up to module authors, like the comment of security_delete_hooks().
> (Well, I'm not proposing ability to unload. I'm proposing only ability to load LSMs
> as loadable kernel modules.)
>
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-15 7:45 ` John Johansen
@ 2022-09-15 14:27 ` Tetsuo Handa
-1 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-09-15 14:27 UTC (permalink / raw)
To: John Johansen, Casey Schaufler, Paul Moore
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook, SElinux list
On 2022/09/15 16:45, John Johansen wrote:
> On 9/14/22 06:57, Tetsuo Handa wrote:
> for some users, but having a very well defined support surface also has its
> place. From a distro POV support is expensive and its amazing what users
> will do and try to hide while trying to get support.
>
I know support is expensive. But distributors are not the only organizations
who provide support. Non-distributors can provide efforts for fixing bugs.
(In fact, I'm debugging problems where distributors would not care/support.)
> Personally I prefer splitting enable and support but there are situations
> where that isn't even allowed (some certifications). So I can understand
> where they are coming from.
What certifications require that an LSM must not be loaded as a loadable kernel
module?
I can imagine that certification becomes void if uncertified/extra kernel modules
are loaded. But I can't imagine that ability to load some kernel module (either
LSM or not) is relevant to certification.
>> I don't like closed-source kernel modules that rewrite syscall tables (e.g.
>> used by AntiVirus), for I can't analyze problems when something went wrong.
>
> Does anyone?
Yes. It took me whole 2 years to prove that a timeout problem happening in a RHEL
system using TrendMicro's DeepSecurity is caused by a loadable kernel module used
by DeepSecurity. It is really difficult to analyze problems with closed-source
kernel modules, for I can't guess what is happening from source code.
You can browse how a loadable kernel module (for TrendMicro's ServerProtect) would look like
at https://files.trendmicro.com/products/splx/splx_kernel_module-3.0.1.0024-src.tar.gz .
I'm expecting that such loadable kernel module becomes cleaner by legally allowing
loadable LSM modules.
>
>> If LSMs were available to open-source out-of-tree kernel modules, this situation
>> could be improved.
>>
> you are more optimistic than I am. What makes you think a distro like RH will
> enable loading out-of-tree kernel modules if they aren't enabling TOMOYO
> that is already in the kernel.
>
> If loadable LSM modules are allowed, there will likely be a kernel config
> to disable them and there will definitely be an interface that allows
> blocking them. So whether via config option or run time control I don't
> see RH allowing them.
An interface that allows blocking unwanted loadable kernel module (either LSM or not)
will be e.g. module signature verification. No special switch for LSM is needed.
The "Vendor-A enables module-A" == "Vendor-A provides support for module-A" and
"Vendor-B enables module-B" == "Vendor-B provides support for module-B" rule can
apply to non-SELinux LSMs.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-09-15 14:27 ` Tetsuo Handa
0 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-09-15 14:27 UTC (permalink / raw)
To: John Johansen, Casey Schaufler, Paul Moore
Cc: SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On 2022/09/15 16:45, John Johansen wrote:
> On 9/14/22 06:57, Tetsuo Handa wrote:
> for some users, but having a very well defined support surface also has its
> place. From a distro POV support is expensive and its amazing what users
> will do and try to hide while trying to get support.
>
I know support is expensive. But distributors are not the only organizations
who provide support. Non-distributors can provide efforts for fixing bugs.
(In fact, I'm debugging problems where distributors would not care/support.)
> Personally I prefer splitting enable and support but there are situations
> where that isn't even allowed (some certifications). So I can understand
> where they are coming from.
What certifications require that an LSM must not be loaded as a loadable kernel
module?
I can imagine that certification becomes void if uncertified/extra kernel modules
are loaded. But I can't imagine that ability to load some kernel module (either
LSM or not) is relevant to certification.
>> I don't like closed-source kernel modules that rewrite syscall tables (e.g.
>> used by AntiVirus), for I can't analyze problems when something went wrong.
>
> Does anyone?
Yes. It took me whole 2 years to prove that a timeout problem happening in a RHEL
system using TrendMicro's DeepSecurity is caused by a loadable kernel module used
by DeepSecurity. It is really difficult to analyze problems with closed-source
kernel modules, for I can't guess what is happening from source code.
You can browse how a loadable kernel module (for TrendMicro's ServerProtect) would look like
at https://files.trendmicro.com/products/splx/splx_kernel_module-3.0.1.0024-src.tar.gz .
I'm expecting that such loadable kernel module becomes cleaner by legally allowing
loadable LSM modules.
>
>> If LSMs were available to open-source out-of-tree kernel modules, this situation
>> could be improved.
>>
> you are more optimistic than I am. What makes you think a distro like RH will
> enable loading out-of-tree kernel modules if they aren't enabling TOMOYO
> that is already in the kernel.
>
> If loadable LSM modules are allowed, there will likely be a kernel config
> to disable them and there will definitely be an interface that allows
> blocking them. So whether via config option or run time control I don't
> see RH allowing them.
An interface that allows blocking unwanted loadable kernel module (either LSM or not)
will be e.g. module signature verification. No special switch for LSM is needed.
The "Vendor-A enables module-A" == "Vendor-A provides support for module-A" and
"Vendor-B enables module-B" == "Vendor-B provides support for module-B" rule can
apply to non-SELinux LSMs.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-14 13:57 ` Tetsuo Handa
@ 2022-10-25 9:48 ` Tetsuo Handa
-1 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-10-25 9:48 UTC (permalink / raw)
To: Casey Schaufler, Paul Moore
Cc: John Johansen, LSM List, James Morris, linux-audit, Mimi Zohar,
keescook, SElinux list
On 2022/10/25 1:37, Casey Schaufler wrote:
>> What I'm insisting is that "warrant the freedom to load
>> loadable LSM modules without recompiling the whole kernel".
>
> Since security modules are optional and the LSM infrastructure
> itself is optional you can't ensure that any given kernel would
> support a loadable security module.
Like I propose adding EXPORT_SYMBOL_GPL(security_hook_heads),
I'm not taking about distributors who choose CONFIG_SECURITY=n.
>> Adding EXPORT_SYMBOL_GPL(security_hook_heads) is the only way that can "allow
>> LSM modules which distributors cannot support to be legally loaded".
>
> I believe that I've identified an alternative. It isn't easy or cheap.
No. You are just handwaving/postponing the problem using something unknown
that is not yet shown as a workable code. Anything that can be disabled via
kernel config option cannot be an alternative.
Quoting from https://lkml.kernel.org/r/2225aec6-f0f3-d38e-ee3c-6139a7c25a37@I-love.SAKURA.ne.jp
> Like Paul Moore said
>
> However, I will caution that it is becoming increasingly difficult for people
> to find time to review potential new LSMs so it may a while to attract sufficient
> comments and feedback.
>
> , being unable to legally use loadable LSMs deprives of chances to develop/try
> new LSMs, and makes LSM interface more and more unattractive. The consequence
> would be "The LSM interface is dead. We will give up implementing as LSMs."
The biggest problem is that quite few developers show interest in loadable LSM modules.
How many developers responded to this topic? Once the ability to allow loadable LSM
modules is technically lost, nobody shall be able to revive it. You will be happy with
ignoring poor people.
You are already and completely trapped into "only in-tree and supported by distributors
is correct" crap.
> Of course the upstream kernel isn't going to have LSM IDs for out-of-tree
> security modules. That's one of many reasons loadable modules are going to
> have to be treated differently from built-in modules, if they're allowed
> at all.
Then, I have to hate your idea of having fixed sized array.
Nacked-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-10-25 9:48 ` Tetsuo Handa
0 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-10-25 9:48 UTC (permalink / raw)
To: Casey Schaufler, Paul Moore
Cc: John Johansen, keescook, SElinux list, James Morris, Mimi Zohar,
LSM List, linux-audit
On 2022/10/25 1:37, Casey Schaufler wrote:
>> What I'm insisting is that "warrant the freedom to load
>> loadable LSM modules without recompiling the whole kernel".
>
> Since security modules are optional and the LSM infrastructure
> itself is optional you can't ensure that any given kernel would
> support a loadable security module.
Like I propose adding EXPORT_SYMBOL_GPL(security_hook_heads),
I'm not taking about distributors who choose CONFIG_SECURITY=n.
>> Adding EXPORT_SYMBOL_GPL(security_hook_heads) is the only way that can "allow
>> LSM modules which distributors cannot support to be legally loaded".
>
> I believe that I've identified an alternative. It isn't easy or cheap.
No. You are just handwaving/postponing the problem using something unknown
that is not yet shown as a workable code. Anything that can be disabled via
kernel config option cannot be an alternative.
Quoting from https://lkml.kernel.org/r/2225aec6-f0f3-d38e-ee3c-6139a7c25a37@I-love.SAKURA.ne.jp
> Like Paul Moore said
>
> However, I will caution that it is becoming increasingly difficult for people
> to find time to review potential new LSMs so it may a while to attract sufficient
> comments and feedback.
>
> , being unable to legally use loadable LSMs deprives of chances to develop/try
> new LSMs, and makes LSM interface more and more unattractive. The consequence
> would be "The LSM interface is dead. We will give up implementing as LSMs."
The biggest problem is that quite few developers show interest in loadable LSM modules.
How many developers responded to this topic? Once the ability to allow loadable LSM
modules is technically lost, nobody shall be able to revive it. You will be happy with
ignoring poor people.
You are already and completely trapped into "only in-tree and supported by distributors
is correct" crap.
> Of course the upstream kernel isn't going to have LSM IDs for out-of-tree
> security modules. That's one of many reasons loadable modules are going to
> have to be treated differently from built-in modules, if they're allowed
> at all.
Then, I have to hate your idea of having fixed sized array.
Nacked-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-10-25 9:48 ` Tetsuo Handa
@ 2022-10-25 10:26 ` John Johansen
-1 siblings, 0 replies; 148+ messages in thread
From: John Johansen @ 2022-10-25 10:26 UTC (permalink / raw)
To: Tetsuo Handa, Casey Schaufler, Paul Moore
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook, SElinux list
On 10/25/22 02:48, Tetsuo Handa wrote:
> On 2022/10/25 1:37, Casey Schaufler wrote:
>>> What I'm insisting is that "warrant the freedom to load
>>> loadable LSM modules without recompiling the whole kernel".
>>
>> Since security modules are optional and the LSM infrastructure
>> itself is optional you can't ensure that any given kernel would
>> support a loadable security module.
>
> Like I propose adding EXPORT_SYMBOL_GPL(security_hook_heads),
> I'm not taking about distributors who choose CONFIG_SECURITY=n.
>
>>> Adding EXPORT_SYMBOL_GPL(security_hook_heads) is the only way that can "allow
>>> LSM modules which distributors cannot support to be legally loaded".
>>
>> I believe that I've identified an alternative. It isn't easy or cheap.
>
> No. You are just handwaving/postponing the problem using something unknown
> that is not yet shown as a workable code. Anything that can be disabled via
> kernel config option cannot be an alternative.
>
Uhmmm, loadable LSM modules if they ever happen will have a kernel config.
If not distros will carry a patch just like they have for unprivileged
user namespaces. Trying to force distros to allow out of tree code just
isn't going to work.
> Quoting from https://lkml.kernel.org/r/2225aec6-f0f3-d38e-ee3c-6139a7c25a37@I-love.SAKURA.ne.jp
> > Like Paul Moore said
> >
> > However, I will caution that it is becoming increasingly difficult for people
> > to find time to review potential new LSMs so it may a while to attract sufficient
> > comments and feedback.
> >
> > , being unable to legally use loadable LSMs deprives of chances to develop/try
> > new LSMs, and makes LSM interface more and more unattractive. The consequence
> > would be "The LSM interface is dead. We will give up implementing as LSMs."
>
> The biggest problem is that quite few developers show interest in loadable LSM modules.
> How many developers responded to this topic? Once the ability to allow loadable LSM
> modules is technically lost, nobody shall be able to revive it. You will be happy with
> ignoring poor people.
>
> You are already and completely trapped into "only in-tree and supported by distributors
> is correct" crap.
>
no, Casey is not. He is trying to find a path forward to get LSM
stacking upstream sooner than later. He has made proposals that
admittedly you have not liked, but he has at least tried to propose
ideas that could work within the insane set of constraints.
>> Of course the upstream kernel isn't going to have LSM IDs for out-of-tree
>> security modules. That's one of many reasons loadable modules are going to
>> have to be treated differently from built-in modules, if they're allowed
>> at all.
>
> Then, I have to hate your idea of having fixed sized array.
>
> Nacked-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
>
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-10-25 10:26 ` John Johansen
0 siblings, 0 replies; 148+ messages in thread
From: John Johansen @ 2022-10-25 10:26 UTC (permalink / raw)
To: Tetsuo Handa, Casey Schaufler, Paul Moore
Cc: keescook, SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On 10/25/22 02:48, Tetsuo Handa wrote:
> On 2022/10/25 1:37, Casey Schaufler wrote:
>>> What I'm insisting is that "warrant the freedom to load
>>> loadable LSM modules without recompiling the whole kernel".
>>
>> Since security modules are optional and the LSM infrastructure
>> itself is optional you can't ensure that any given kernel would
>> support a loadable security module.
>
> Like I propose adding EXPORT_SYMBOL_GPL(security_hook_heads),
> I'm not taking about distributors who choose CONFIG_SECURITY=n.
>
>>> Adding EXPORT_SYMBOL_GPL(security_hook_heads) is the only way that can "allow
>>> LSM modules which distributors cannot support to be legally loaded".
>>
>> I believe that I've identified an alternative. It isn't easy or cheap.
>
> No. You are just handwaving/postponing the problem using something unknown
> that is not yet shown as a workable code. Anything that can be disabled via
> kernel config option cannot be an alternative.
>
Uhmmm, loadable LSM modules if they ever happen will have a kernel config.
If not distros will carry a patch just like they have for unprivileged
user namespaces. Trying to force distros to allow out of tree code just
isn't going to work.
> Quoting from https://lkml.kernel.org/r/2225aec6-f0f3-d38e-ee3c-6139a7c25a37@I-love.SAKURA.ne.jp
> > Like Paul Moore said
> >
> > However, I will caution that it is becoming increasingly difficult for people
> > to find time to review potential new LSMs so it may a while to attract sufficient
> > comments and feedback.
> >
> > , being unable to legally use loadable LSMs deprives of chances to develop/try
> > new LSMs, and makes LSM interface more and more unattractive. The consequence
> > would be "The LSM interface is dead. We will give up implementing as LSMs."
>
> The biggest problem is that quite few developers show interest in loadable LSM modules.
> How many developers responded to this topic? Once the ability to allow loadable LSM
> modules is technically lost, nobody shall be able to revive it. You will be happy with
> ignoring poor people.
>
> You are already and completely trapped into "only in-tree and supported by distributors
> is correct" crap.
>
no, Casey is not. He is trying to find a path forward to get LSM
stacking upstream sooner than later. He has made proposals that
admittedly you have not liked, but he has at least tried to propose
ideas that could work within the insane set of constraints.
>> Of course the upstream kernel isn't going to have LSM IDs for out-of-tree
>> security modules. That's one of many reasons loadable modules are going to
>> have to be treated differently from built-in modules, if they're allowed
>> at all.
>
> Then, I have to hate your idea of having fixed sized array.
>
> Nacked-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
>
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-10-25 10:26 ` John Johansen
@ 2022-10-25 11:20 ` Tetsuo Handa
-1 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-10-25 11:20 UTC (permalink / raw)
To: John Johansen, Casey Schaufler, Paul Moore
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook, SElinux list
On 2022/10/25 19:26, John Johansen wrote:
> no, Casey is not. He is trying to find a path forward to get LSM
> stacking upstream sooner than later. He has made proposals that
> admittedly you have not liked, but he has at least tried to propose
> ideas that could work within the insane set of constraints.
I'm OK with getting LSM stacking upstream. But changes made based on
only built-in modules are bad. If LSM id cannot be assigned to loadable
LSM modules at runtime because not all loadable LSM modules will be
in-tree in order to get an LSM id assigned, loadable LSM modules won't
be able to utilize e.g. lsm_module_list system call (or whatever
changes made while trying to unshare resources/interfaces currently
shared among SELinux/Smack/AppArmor).
It will be a complete reinvention of Linux security framework which is
merely borrowing hooks provided by LSM. That is no different from
duplicating existing LSM hooks and managing via completely different
set of interfaces (e.g. /proc/$pid/attr2/$lsmname/$filename ,
/sys/kernel/security2/$lsmname/$filename ). Such implementation is
no longer loadable LSM. It is LSM version 2. And I don't think that
such implementation will be accepted unless you agree to kill current
LSM (say, LSM version 1).
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-10-25 11:20 ` Tetsuo Handa
0 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-10-25 11:20 UTC (permalink / raw)
To: John Johansen, Casey Schaufler, Paul Moore
Cc: keescook, SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On 2022/10/25 19:26, John Johansen wrote:
> no, Casey is not. He is trying to find a path forward to get LSM
> stacking upstream sooner than later. He has made proposals that
> admittedly you have not liked, but he has at least tried to propose
> ideas that could work within the insane set of constraints.
I'm OK with getting LSM stacking upstream. But changes made based on
only built-in modules are bad. If LSM id cannot be assigned to loadable
LSM modules at runtime because not all loadable LSM modules will be
in-tree in order to get an LSM id assigned, loadable LSM modules won't
be able to utilize e.g. lsm_module_list system call (or whatever
changes made while trying to unshare resources/interfaces currently
shared among SELinux/Smack/AppArmor).
It will be a complete reinvention of Linux security framework which is
merely borrowing hooks provided by LSM. That is no different from
duplicating existing LSM hooks and managing via completely different
set of interfaces (e.g. /proc/$pid/attr2/$lsmname/$filename ,
/sys/kernel/security2/$lsmname/$filename ). Such implementation is
no longer loadable LSM. It is LSM version 2. And I don't think that
such implementation will be accepted unless you agree to kill current
LSM (say, LSM version 1).
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-10-25 11:20 ` Tetsuo Handa
@ 2022-10-25 14:12 ` Casey Schaufler
-1 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-10-25 14:12 UTC (permalink / raw)
To: Tetsuo Handa, John Johansen, Paul Moore
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook,
SElinux list, casey
On 10/25/2022 4:20 AM, Tetsuo Handa wrote:
> On 2022/10/25 19:26, John Johansen wrote:
>> no, Casey is not. He is trying to find a path forward to get LSM
>> stacking upstream sooner than later. He has made proposals that
>> admittedly you have not liked, but he has at least tried to propose
>> ideas that could work within the insane set of constraints.
> I'm OK with getting LSM stacking upstream. But changes made based on
> only built-in modules are bad. If LSM id cannot be assigned to loadable
> LSM modules at runtime because not all loadable LSM modules will be
> in-tree in order to get an LSM id assigned, loadable LSM modules won't
> be able to utilize e.g. lsm_module_list system call (or whatever
> changes made while trying to unshare resources/interfaces currently
> shared among SELinux/Smack/AppArmor).
>
> It will be a complete reinvention of Linux security framework which is
> merely borrowing hooks provided by LSM. That is no different from
> duplicating existing LSM hooks and managing via completely different
> set of interfaces (e.g. /proc/$pid/attr2/$lsmname/$filename ,
> /sys/kernel/security2/$lsmname/$filename ). Such implementation is
> no longer loadable LSM. It is LSM version 2. And I don't think that
> such implementation will be accepted unless you agree to kill current
> LSM (say, LSM version 1).
The counter argument to this statement is that BPF has been accepted
upstream. eBPF programs are different from built-in security modules.
There is no reason that a well implemented LSM that accepts loadable
modules *that are different* from built-in modules couldn't be created.
I seriously doubt that it would get upstream for all the reasons
usually cited. But there is nothing about the implementation I've proposed
that would prevent it.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-10-25 14:12 ` Casey Schaufler
0 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-10-25 14:12 UTC (permalink / raw)
To: Tetsuo Handa, John Johansen, Paul Moore
Cc: keescook, SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On 10/25/2022 4:20 AM, Tetsuo Handa wrote:
> On 2022/10/25 19:26, John Johansen wrote:
>> no, Casey is not. He is trying to find a path forward to get LSM
>> stacking upstream sooner than later. He has made proposals that
>> admittedly you have not liked, but he has at least tried to propose
>> ideas that could work within the insane set of constraints.
> I'm OK with getting LSM stacking upstream. But changes made based on
> only built-in modules are bad. If LSM id cannot be assigned to loadable
> LSM modules at runtime because not all loadable LSM modules will be
> in-tree in order to get an LSM id assigned, loadable LSM modules won't
> be able to utilize e.g. lsm_module_list system call (or whatever
> changes made while trying to unshare resources/interfaces currently
> shared among SELinux/Smack/AppArmor).
>
> It will be a complete reinvention of Linux security framework which is
> merely borrowing hooks provided by LSM. That is no different from
> duplicating existing LSM hooks and managing via completely different
> set of interfaces (e.g. /proc/$pid/attr2/$lsmname/$filename ,
> /sys/kernel/security2/$lsmname/$filename ). Such implementation is
> no longer loadable LSM. It is LSM version 2. And I don't think that
> such implementation will be accepted unless you agree to kill current
> LSM (say, LSM version 1).
The counter argument to this statement is that BPF has been accepted
upstream. eBPF programs are different from built-in security modules.
There is no reason that a well implemented LSM that accepts loadable
modules *that are different* from built-in modules couldn't be created.
I seriously doubt that it would get upstream for all the reasons
usually cited. But there is nothing about the implementation I've proposed
that would prevent it.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-10-25 14:12 ` Casey Schaufler
@ 2022-10-25 22:12 ` Tetsuo Handa
-1 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-10-25 22:12 UTC (permalink / raw)
To: Casey Schaufler, John Johansen, Paul Moore
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook, SElinux list
On 2022/10/25 23:12, Casey Schaufler wrote:
> On 10/25/2022 4:20 AM, Tetsuo Handa wrote:
>> On 2022/10/25 19:26, John Johansen wrote:
>>> no, Casey is not. He is trying to find a path forward to get LSM
>>> stacking upstream sooner than later. He has made proposals that
>>> admittedly you have not liked, but he has at least tried to propose
>>> ideas that could work within the insane set of constraints.
>> I'm OK with getting LSM stacking upstream. But changes made based on
>> only built-in modules are bad. If LSM id cannot be assigned to loadable
>> LSM modules at runtime because not all loadable LSM modules will be
>> in-tree in order to get an LSM id assigned, loadable LSM modules won't
>> be able to utilize e.g. lsm_module_list system call (or whatever
>> changes made while trying to unshare resources/interfaces currently
>> shared among SELinux/Smack/AppArmor).
>>
>> It will be a complete reinvention of Linux security framework which is
>> merely borrowing hooks provided by LSM. That is no different from
>> duplicating existing LSM hooks and managing via completely different
>> set of interfaces (e.g. /proc/$pid/attr2/$lsmname/$filename ,
>> /sys/kernel/security2/$lsmname/$filename ). Such implementation is
>> no longer loadable LSM. It is LSM version 2. And I don't think that
>> such implementation will be accepted unless you agree to kill current
>> LSM (say, LSM version 1).
>
> The counter argument to this statement is that BPF has been accepted
> upstream. eBPF programs are different from built-in security modules.
> There is no reason that a well implemented LSM that accepts loadable
> modules *that are different* from built-in modules couldn't be created.
> I seriously doubt that it would get upstream for all the reasons
> usually cited. But there is nothing about the implementation I've proposed
> that would prevent it.
>
As an easy example, please show me an eBPF program that allows restricting where
to chroot to and allows configuring where to chroot to using /sys/kernel/security/
interface.
An loadable LSM consists of hooks (for filtering access requests) and interface
(for configuring rules whether to filter access requests).
Your LSM id approach makes it impossible to use interface (due to lack of LSM id
for loadable LSM modules) by loadable LSM modules. LSM id must not be limited to
built-in LSM modules.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-10-25 22:12 ` Tetsuo Handa
0 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-10-25 22:12 UTC (permalink / raw)
To: Casey Schaufler, John Johansen, Paul Moore
Cc: keescook, SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On 2022/10/25 23:12, Casey Schaufler wrote:
> On 10/25/2022 4:20 AM, Tetsuo Handa wrote:
>> On 2022/10/25 19:26, John Johansen wrote:
>>> no, Casey is not. He is trying to find a path forward to get LSM
>>> stacking upstream sooner than later. He has made proposals that
>>> admittedly you have not liked, but he has at least tried to propose
>>> ideas that could work within the insane set of constraints.
>> I'm OK with getting LSM stacking upstream. But changes made based on
>> only built-in modules are bad. If LSM id cannot be assigned to loadable
>> LSM modules at runtime because not all loadable LSM modules will be
>> in-tree in order to get an LSM id assigned, loadable LSM modules won't
>> be able to utilize e.g. lsm_module_list system call (or whatever
>> changes made while trying to unshare resources/interfaces currently
>> shared among SELinux/Smack/AppArmor).
>>
>> It will be a complete reinvention of Linux security framework which is
>> merely borrowing hooks provided by LSM. That is no different from
>> duplicating existing LSM hooks and managing via completely different
>> set of interfaces (e.g. /proc/$pid/attr2/$lsmname/$filename ,
>> /sys/kernel/security2/$lsmname/$filename ). Such implementation is
>> no longer loadable LSM. It is LSM version 2. And I don't think that
>> such implementation will be accepted unless you agree to kill current
>> LSM (say, LSM version 1).
>
> The counter argument to this statement is that BPF has been accepted
> upstream. eBPF programs are different from built-in security modules.
> There is no reason that a well implemented LSM that accepts loadable
> modules *that are different* from built-in modules couldn't be created.
> I seriously doubt that it would get upstream for all the reasons
> usually cited. But there is nothing about the implementation I've proposed
> that would prevent it.
>
As an easy example, please show me an eBPF program that allows restricting where
to chroot to and allows configuring where to chroot to using /sys/kernel/security/
interface.
An loadable LSM consists of hooks (for filtering access requests) and interface
(for configuring rules whether to filter access requests).
Your LSM id approach makes it impossible to use interface (due to lack of LSM id
for loadable LSM modules) by loadable LSM modules. LSM id must not be limited to
built-in LSM modules.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-10-25 22:12 ` Tetsuo Handa
@ 2022-10-25 22:41 ` Casey Schaufler
-1 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-10-25 22:41 UTC (permalink / raw)
To: Tetsuo Handa, John Johansen, Paul Moore
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook,
SElinux list, casey
On 10/25/2022 3:12 PM, Tetsuo Handa wrote:
> On 2022/10/25 23:12, Casey Schaufler wrote:
>> On 10/25/2022 4:20 AM, Tetsuo Handa wrote:
>>> On 2022/10/25 19:26, John Johansen wrote:
>>>> no, Casey is not. He is trying to find a path forward to get LSM
>>>> stacking upstream sooner than later. He has made proposals that
>>>> admittedly you have not liked, but he has at least tried to propose
>>>> ideas that could work within the insane set of constraints.
>>> I'm OK with getting LSM stacking upstream. But changes made based on
>>> only built-in modules are bad. If LSM id cannot be assigned to loadable
>>> LSM modules at runtime because not all loadable LSM modules will be
>>> in-tree in order to get an LSM id assigned, loadable LSM modules won't
>>> be able to utilize e.g. lsm_module_list system call (or whatever
>>> changes made while trying to unshare resources/interfaces currently
>>> shared among SELinux/Smack/AppArmor).
>>>
>>> It will be a complete reinvention of Linux security framework which is
>>> merely borrowing hooks provided by LSM. That is no different from
>>> duplicating existing LSM hooks and managing via completely different
>>> set of interfaces (e.g. /proc/$pid/attr2/$lsmname/$filename ,
>>> /sys/kernel/security2/$lsmname/$filename ). Such implementation is
>>> no longer loadable LSM. It is LSM version 2. And I don't think that
>>> such implementation will be accepted unless you agree to kill current
>>> LSM (say, LSM version 1).
>> The counter argument to this statement is that BPF has been accepted
>> upstream. eBPF programs are different from built-in security modules.
>> There is no reason that a well implemented LSM that accepts loadable
>> modules *that are different* from built-in modules couldn't be created.
>> I seriously doubt that it would get upstream for all the reasons
>> usually cited. But there is nothing about the implementation I've proposed
>> that would prevent it.
>>
> As an easy example, please show me an eBPF program that allows restricting where
> to chroot to and allows configuring where to chroot to using /sys/kernel/security/
> interface.
>
> An loadable LSM consists of hooks (for filtering access requests) and interface
> (for configuring rules whether to filter access requests).
>
> Your LSM id approach makes it impossible to use interface (due to lack of LSM id
> for loadable LSM modules) by loadable LSM modules. LSM id must not be limited to
> built-in LSM modules.
I'm sorry that I am failing to communicate my understanding of why this
isn't true. You need a built-in LSM that loads and manages loadable
security modules. That LSM would have an LSM ID just like the BPF LSM
has a LSM ID. I have no doubt that there are multiple workable implementations,
as I have looked into many different ways to implement the stacking for
built-in modules. I am also sorry that I don't expect to have enough working
years left to even consider spending any more time on the problem. This is
a development effort for The Next Generation.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-10-25 22:41 ` Casey Schaufler
0 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-10-25 22:41 UTC (permalink / raw)
To: Tetsuo Handa, John Johansen, Paul Moore
Cc: keescook, SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On 10/25/2022 3:12 PM, Tetsuo Handa wrote:
> On 2022/10/25 23:12, Casey Schaufler wrote:
>> On 10/25/2022 4:20 AM, Tetsuo Handa wrote:
>>> On 2022/10/25 19:26, John Johansen wrote:
>>>> no, Casey is not. He is trying to find a path forward to get LSM
>>>> stacking upstream sooner than later. He has made proposals that
>>>> admittedly you have not liked, but he has at least tried to propose
>>>> ideas that could work within the insane set of constraints.
>>> I'm OK with getting LSM stacking upstream. But changes made based on
>>> only built-in modules are bad. If LSM id cannot be assigned to loadable
>>> LSM modules at runtime because not all loadable LSM modules will be
>>> in-tree in order to get an LSM id assigned, loadable LSM modules won't
>>> be able to utilize e.g. lsm_module_list system call (or whatever
>>> changes made while trying to unshare resources/interfaces currently
>>> shared among SELinux/Smack/AppArmor).
>>>
>>> It will be a complete reinvention of Linux security framework which is
>>> merely borrowing hooks provided by LSM. That is no different from
>>> duplicating existing LSM hooks and managing via completely different
>>> set of interfaces (e.g. /proc/$pid/attr2/$lsmname/$filename ,
>>> /sys/kernel/security2/$lsmname/$filename ). Such implementation is
>>> no longer loadable LSM. It is LSM version 2. And I don't think that
>>> such implementation will be accepted unless you agree to kill current
>>> LSM (say, LSM version 1).
>> The counter argument to this statement is that BPF has been accepted
>> upstream. eBPF programs are different from built-in security modules.
>> There is no reason that a well implemented LSM that accepts loadable
>> modules *that are different* from built-in modules couldn't be created.
>> I seriously doubt that it would get upstream for all the reasons
>> usually cited. But there is nothing about the implementation I've proposed
>> that would prevent it.
>>
> As an easy example, please show me an eBPF program that allows restricting where
> to chroot to and allows configuring where to chroot to using /sys/kernel/security/
> interface.
>
> An loadable LSM consists of hooks (for filtering access requests) and interface
> (for configuring rules whether to filter access requests).
>
> Your LSM id approach makes it impossible to use interface (due to lack of LSM id
> for loadable LSM modules) by loadable LSM modules. LSM id must not be limited to
> built-in LSM modules.
I'm sorry that I am failing to communicate my understanding of why this
isn't true. You need a built-in LSM that loads and manages loadable
security modules. That LSM would have an LSM ID just like the BPF LSM
has a LSM ID. I have no doubt that there are multiple workable implementations,
as I have looked into many different ways to implement the stacking for
built-in modules. I am also sorry that I don't expect to have enough working
years left to even consider spending any more time on the problem. This is
a development effort for The Next Generation.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-10-25 22:41 ` Casey Schaufler
@ 2022-10-26 10:19 ` Tetsuo Handa
-1 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-10-26 10:19 UTC (permalink / raw)
To: Casey Schaufler, John Johansen, Paul Moore
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook, SElinux list
On 2022/10/26 7:41, Casey Schaufler wrote:
> You need a built-in LSM that loads and manages loadable
> security modules.
That is no longer loadable LSM modules. A loadable LSM module must be capable of
loading any code and using any interface that is allowed to loadable kernel modules
using /sbin/insmod command. That is my understanding of what you have promised (and
the reason I am allowing you to continue working on LSM stacking before I make
CONFIG_SECURITY_TOMOYO=m).
> That LSM would have an LSM ID just like the BPF LSM
> has a LSM ID.
There can't be a LSM that manages loadable security modules. TOMOYO can't be loaded
via such LSM, for TOMOYO needs to e.g. create /sys/kernel/security/tomoyo/ interface.
A contained program like BPF can't get such flexibility, and a LSM that manages
loadable security modules can't manage flexible/unconfined programs.
> That LSM would have an LSM ID just like the BPF LSM
> has a LSM ID.
Whatever LSM modules that are in-tree will have an LSM id. But you must remember
that not all LSM modules are in-tree (and won't be able to get in-tree).
The LSM id I'm talking about is for LSM modules that cannot get in-tree.
> I have no doubt that there are multiple workable implementations,
> as I have looked into many different ways to implement the stacking for
> built-in modules.
Please enumerate some that can satisfy our promise.
Even if there is a LSM that manages loadable LSMs, loadable LSMs can't get LSM id
because what loadable LSMs will do is beyond what the BPF LSM can do.
Loadable LSMs by nature needs to be able to have unique identifier (currently
module name, and you are trying to change from name to integer which some of
loadable LSMs cannot get).
> I am also sorry that I don't expect to have enough working
> years left to even consider spending any more time on the problem. This is
> a development effort for The Next Generation.
If you segregate built-in LSM modules and loadable LSM modules (remember,
not all LSM modules will be able to get in-tree and built-in), userspace won't be
able to use LSM id you are trying to introduce. Your LSM id makes LSM framework
worse than now.
You are killing The Next Generation due to "only in-tree and supported by
distributors is correct" crap.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-10-26 10:19 ` Tetsuo Handa
0 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-10-26 10:19 UTC (permalink / raw)
To: Casey Schaufler, John Johansen, Paul Moore
Cc: keescook, SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On 2022/10/26 7:41, Casey Schaufler wrote:
> You need a built-in LSM that loads and manages loadable
> security modules.
That is no longer loadable LSM modules. A loadable LSM module must be capable of
loading any code and using any interface that is allowed to loadable kernel modules
using /sbin/insmod command. That is my understanding of what you have promised (and
the reason I am allowing you to continue working on LSM stacking before I make
CONFIG_SECURITY_TOMOYO=m).
> That LSM would have an LSM ID just like the BPF LSM
> has a LSM ID.
There can't be a LSM that manages loadable security modules. TOMOYO can't be loaded
via such LSM, for TOMOYO needs to e.g. create /sys/kernel/security/tomoyo/ interface.
A contained program like BPF can't get such flexibility, and a LSM that manages
loadable security modules can't manage flexible/unconfined programs.
> That LSM would have an LSM ID just like the BPF LSM
> has a LSM ID.
Whatever LSM modules that are in-tree will have an LSM id. But you must remember
that not all LSM modules are in-tree (and won't be able to get in-tree).
The LSM id I'm talking about is for LSM modules that cannot get in-tree.
> I have no doubt that there are multiple workable implementations,
> as I have looked into many different ways to implement the stacking for
> built-in modules.
Please enumerate some that can satisfy our promise.
Even if there is a LSM that manages loadable LSMs, loadable LSMs can't get LSM id
because what loadable LSMs will do is beyond what the BPF LSM can do.
Loadable LSMs by nature needs to be able to have unique identifier (currently
module name, and you are trying to change from name to integer which some of
loadable LSMs cannot get).
> I am also sorry that I don't expect to have enough working
> years left to even consider spending any more time on the problem. This is
> a development effort for The Next Generation.
If you segregate built-in LSM modules and loadable LSM modules (remember,
not all LSM modules will be able to get in-tree and built-in), userspace won't be
able to use LSM id you are trying to introduce. Your LSM id makes LSM framework
worse than now.
You are killing The Next Generation due to "only in-tree and supported by
distributors is correct" crap.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-10-26 10:19 ` Tetsuo Handa
@ 2022-10-26 15:30 ` Casey Schaufler
-1 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-10-26 15:30 UTC (permalink / raw)
To: Tetsuo Handa, John Johansen, Paul Moore
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook,
SElinux list, casey
On 10/26/2022 3:19 AM, Tetsuo Handa wrote:
> On 2022/10/26 7:41, Casey Schaufler wrote:
>> You need a built-in LSM that loads and manages loadable
>> security modules.
> That is no longer loadable LSM modules. A loadable LSM module must be capable of
> loading any code and using any interface that is allowed to loadable kernel modules
> using /sbin/insmod command. That is my understanding of what you have promised (and
> the reason I am allowing you to continue working on LSM stacking before I make
> CONFIG_SECURITY_TOMOYO=m).
Loadable modules, in whatever form they take, will require the stacking
I'm proposing. They will also require the next phase of stacking, which
includes the networking bits that will allow universal stacking. Even if
the current work goes in tomorrow (demented giggles) that's at least a
year off. Then, and only then, will someone be able to tackle an
implementation of loadable modules. I will not be available for that job.
I have done everything I can to ensure that the stacking work won't
prevent it from being done. I have proposed how it might be done. But
I don't have 10 more years to spend on it, and it's not me that will
reject it in the end. I won't beat that dead horse's head against that
brick wall.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-10-26 15:30 ` Casey Schaufler
0 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-10-26 15:30 UTC (permalink / raw)
To: Tetsuo Handa, John Johansen, Paul Moore
Cc: keescook, SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On 10/26/2022 3:19 AM, Tetsuo Handa wrote:
> On 2022/10/26 7:41, Casey Schaufler wrote:
>> You need a built-in LSM that loads and manages loadable
>> security modules.
> That is no longer loadable LSM modules. A loadable LSM module must be capable of
> loading any code and using any interface that is allowed to loadable kernel modules
> using /sbin/insmod command. That is my understanding of what you have promised (and
> the reason I am allowing you to continue working on LSM stacking before I make
> CONFIG_SECURITY_TOMOYO=m).
Loadable modules, in whatever form they take, will require the stacking
I'm proposing. They will also require the next phase of stacking, which
includes the networking bits that will allow universal stacking. Even if
the current work goes in tomorrow (demented giggles) that's at least a
year off. Then, and only then, will someone be able to tackle an
implementation of loadable modules. I will not be available for that job.
I have done everything I can to ensure that the stacking work won't
prevent it from being done. I have proposed how it might be done. But
I don't have 10 more years to spend on it, and it's not me that will
reject it in the end. I won't beat that dead horse's head against that
brick wall.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-10-26 10:19 ` Tetsuo Handa
@ 2022-10-28 10:14 ` John Johansen
-1 siblings, 0 replies; 148+ messages in thread
From: John Johansen @ 2022-10-28 10:14 UTC (permalink / raw)
To: Tetsuo Handa, Casey Schaufler, Paul Moore
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook, SElinux list
On 10/26/22 03:19, Tetsuo Handa wrote:
> On 2022/10/26 7:41, Casey Schaufler wrote:
>> You need a built-in LSM that loads and manages loadable
>> security modules.
>
> That is no longer loadable LSM modules. A loadable LSM module must be capable of
> loading any code and using any interface that is allowed to loadable kernel modules
> using /sbin/insmod command. That is my understanding of what you have promised (and
> the reason I am allowing you to continue working on LSM stacking before I make
> CONFIG_SECURITY_TOMOYO=m).
>
Tetsuo, think of it this way. LSM stacking is going to make it much easier for new
LSM modules because they won't automatically be excluded because one of the other
LSMs is needed.
The problem of loadable LSM modules is orthogonal, and Casey shouldn't need to
solve it in this patch series. That is further work to be taken up by another,
as Casey has clearly stated its work he is not interested in doing.
However the real problem you are trying to solve won't be solved by loadable LSM
modules, though they may help. Just having loadable LSMs modules won't mean a
distro will build an LSM as a loadable module instead of disabling it, nor does
it mean a distro will allow loading an out of tree LSM module. Even if the
upstream kernel doesn't provide an option to block loading them, distros will.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-10-28 10:14 ` John Johansen
0 siblings, 0 replies; 148+ messages in thread
From: John Johansen @ 2022-10-28 10:14 UTC (permalink / raw)
To: Tetsuo Handa, Casey Schaufler, Paul Moore
Cc: keescook, SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On 10/26/22 03:19, Tetsuo Handa wrote:
> On 2022/10/26 7:41, Casey Schaufler wrote:
>> You need a built-in LSM that loads and manages loadable
>> security modules.
>
> That is no longer loadable LSM modules. A loadable LSM module must be capable of
> loading any code and using any interface that is allowed to loadable kernel modules
> using /sbin/insmod command. That is my understanding of what you have promised (and
> the reason I am allowing you to continue working on LSM stacking before I make
> CONFIG_SECURITY_TOMOYO=m).
>
Tetsuo, think of it this way. LSM stacking is going to make it much easier for new
LSM modules because they won't automatically be excluded because one of the other
LSMs is needed.
The problem of loadable LSM modules is orthogonal, and Casey shouldn't need to
solve it in this patch series. That is further work to be taken up by another,
as Casey has clearly stated its work he is not interested in doing.
However the real problem you are trying to solve won't be solved by loadable LSM
modules, though they may help. Just having loadable LSMs modules won't mean a
distro will build an LSM as a loadable module instead of disabling it, nor does
it mean a distro will allow loading an out of tree LSM module. Even if the
upstream kernel doesn't provide an option to block loading them, distros will.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-10-28 10:14 ` John Johansen
@ 2022-10-30 4:03 ` Tetsuo Handa
-1 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-10-30 4:03 UTC (permalink / raw)
To: John Johansen, Casey Schaufler, Paul Moore
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook, SElinux list
On 2022/10/28 19:14, John Johansen wrote:
> On 10/26/22 03:19, Tetsuo Handa wrote:
>> On 2022/10/26 7:41, Casey Schaufler wrote:
>>> You need a built-in LSM that loads and manages loadable
>>> security modules.
>>
>> That is no longer loadable LSM modules. A loadable LSM module must be capable of
>> loading any code and using any interface that is allowed to loadable kernel modules
>> using /sbin/insmod command. That is my understanding of what you have promised (and
>> the reason I am allowing you to continue working on LSM stacking before I make
>> CONFIG_SECURITY_TOMOYO=m).
>>
>
> Tetsuo, think of it this way. LSM stacking is going to make it much easier for new
> LSM modules because they won't automatically be excluded because one of the other
> LSMs is needed.
>
> The problem of loadable LSM modules is orthogonal, and Casey shouldn't need to
> solve it in this patch series. That is further work to be taken up by another,
> as Casey has clearly stated its work he is not interested in doing.
>
> However the real problem you are trying to solve won't be solved by loadable LSM
> modules, though they may help. Just having loadable LSMs modules won't mean a
> distro will build an LSM as a loadable module instead of disabling it, nor does
> it mean a distro will allow loading an out of tree LSM module. Even if the
> upstream kernel doesn't provide an option to block loading them, distros will.
>
What do you think the background of
Ultimately the challenge is getting userspace developers to accept a
change that is not part of the upstream Linux Kernel and thus not
guaranteed under the usual "don't break userspace" kernel API promise.
is? I consider that the reason is because
We do care about userspace programs and users who are using userspace programs.
. If we don't care about userspace and users, we would not mind breaking APIs.
This reasoning is more stronger than "we don't care about out-of-tree code"
reasoning.
Distributors have rights to block loading loadable kernel modules which are
not included in upstream kernels. But for example Red Hat is not excising
the rights to block loading loadable kernel modules (e.g.
https://access.redhat.com/solutions/1376133 ). What do you think about the
reasons of not blocking loading loadable kernel modules which are not included
in upstream kernels? I consider that the reason is because
Allowing loadable kernel modules which cannot be supported by distributors
to exist and to be loaded into distributor kernels is more beneficial for
users.
That is, we have been allowing out-of-tree kernel code to exist because
out-of-tree kernel code can be beneficial for users despite distributors cannot
afford supporting out-of-tree kernel code.
If you really think that we have the rights to lock out out-of-tree kernel code
and/or disable loading of out-of-tree kernel code via /sbin/insmod, firstly achieve
(1) Disallow loading of non-GPL kernel modules. (It is a trivial change.)
(2) Disallow loading of out-of-tree kernel code via /sbin/insmod .
(I don't know how we can technically enforce such change. Unlike not assigning
LSM id value to LSM modules, we need to somehow be able to check whether an
arbitrary file is in-tree (e.g. forbid "git add some_file") and unmodified
(e.g. forbid "patch -p1 < some_patch").
before you enforce requiring an LSM id value in order to register an LSM module.
I don't accept "I'm not interested in making such changes". It is your duty to
achieve if you use "we don't care about out-of-tree code" as a rationale for
requiring an LSM id value in order to register an LSM module.
Nowadays, many software is developed using programming languages which can generate code
for multiple operating systems. That is, people are getting indifferent with operating
systems they run their software. Then, what is an advantage of choosing Linux as operating
systems for running their software, if Linux kernel does not provide freedom for
customization depending on user's needs?
As web application developers increases, developers who can understand C language (and
system call) are decreasing. As a result, it is getting more and more difficult to let them
understand and manage fine-grained allowlisting-based access controls like SELinux. Then,
what is an advantage of choosing Linux as operating systems for running their software, if
LSM does not provide freedom for using whatever simpler LSM modules users want?
Windows operating system provides WSL (Windows Subsystem for Linux) which allows running
CUI programs and servers which are designed for Linux. Windows users can run CUI programs
and servers without requiring real Linux kernels and can run GUI programs via Windows
kernels. Neither SELinux nor AppArmor is required for protecting programs/servers, for
antivirus software for Windows will provide protection. Then, what is an advantage of using
real Linux kernels, if we cannot allow Linux kernels to use whatever LSM modules users want?
I believe that it is time to get out of "we don't care about out-of-tree code".
The "we don't care about out-of-tree code" reasoning is a brain freeze that leads to
forget about users who still continue using Linux as platform for running their software.
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
@ 2022-10-30 4:03 ` Tetsuo Handa
0 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-10-30 4:03 UTC (permalink / raw)
To: John Johansen, Casey Schaufler, Paul Moore
Cc: keescook, SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On 2022/10/28 19:14, John Johansen wrote:
> On 10/26/22 03:19, Tetsuo Handa wrote:
>> On 2022/10/26 7:41, Casey Schaufler wrote:
>>> You need a built-in LSM that loads and manages loadable
>>> security modules.
>>
>> That is no longer loadable LSM modules. A loadable LSM module must be capable of
>> loading any code and using any interface that is allowed to loadable kernel modules
>> using /sbin/insmod command. That is my understanding of what you have promised (and
>> the reason I am allowing you to continue working on LSM stacking before I make
>> CONFIG_SECURITY_TOMOYO=m).
>>
>
> Tetsuo, think of it this way. LSM stacking is going to make it much easier for new
> LSM modules because they won't automatically be excluded because one of the other
> LSMs is needed.
>
> The problem of loadable LSM modules is orthogonal, and Casey shouldn't need to
> solve it in this patch series. That is further work to be taken up by another,
> as Casey has clearly stated its work he is not interested in doing.
>
> However the real problem you are trying to solve won't be solved by loadable LSM
> modules, though they may help. Just having loadable LSMs modules won't mean a
> distro will build an LSM as a loadable module instead of disabling it, nor does
> it mean a distro will allow loading an out of tree LSM module. Even if the
> upstream kernel doesn't provide an option to block loading them, distros will.
>
What do you think the background of
Ultimately the challenge is getting userspace developers to accept a
change that is not part of the upstream Linux Kernel and thus not
guaranteed under the usual "don't break userspace" kernel API promise.
is? I consider that the reason is because
We do care about userspace programs and users who are using userspace programs.
. If we don't care about userspace and users, we would not mind breaking APIs.
This reasoning is more stronger than "we don't care about out-of-tree code"
reasoning.
Distributors have rights to block loading loadable kernel modules which are
not included in upstream kernels. But for example Red Hat is not excising
the rights to block loading loadable kernel modules (e.g.
https://access.redhat.com/solutions/1376133 ). What do you think about the
reasons of not blocking loading loadable kernel modules which are not included
in upstream kernels? I consider that the reason is because
Allowing loadable kernel modules which cannot be supported by distributors
to exist and to be loaded into distributor kernels is more beneficial for
users.
That is, we have been allowing out-of-tree kernel code to exist because
out-of-tree kernel code can be beneficial for users despite distributors cannot
afford supporting out-of-tree kernel code.
If you really think that we have the rights to lock out out-of-tree kernel code
and/or disable loading of out-of-tree kernel code via /sbin/insmod, firstly achieve
(1) Disallow loading of non-GPL kernel modules. (It is a trivial change.)
(2) Disallow loading of out-of-tree kernel code via /sbin/insmod .
(I don't know how we can technically enforce such change. Unlike not assigning
LSM id value to LSM modules, we need to somehow be able to check whether an
arbitrary file is in-tree (e.g. forbid "git add some_file") and unmodified
(e.g. forbid "patch -p1 < some_patch").
before you enforce requiring an LSM id value in order to register an LSM module.
I don't accept "I'm not interested in making such changes". It is your duty to
achieve if you use "we don't care about out-of-tree code" as a rationale for
requiring an LSM id value in order to register an LSM module.
Nowadays, many software is developed using programming languages which can generate code
for multiple operating systems. That is, people are getting indifferent with operating
systems they run their software. Then, what is an advantage of choosing Linux as operating
systems for running their software, if Linux kernel does not provide freedom for
customization depending on user's needs?
As web application developers increases, developers who can understand C language (and
system call) are decreasing. As a result, it is getting more and more difficult to let them
understand and manage fine-grained allowlisting-based access controls like SELinux. Then,
what is an advantage of choosing Linux as operating systems for running their software, if
LSM does not provide freedom for using whatever simpler LSM modules users want?
Windows operating system provides WSL (Windows Subsystem for Linux) which allows running
CUI programs and servers which are designed for Linux. Windows users can run CUI programs
and servers without requiring real Linux kernels and can run GUI programs via Windows
kernels. Neither SELinux nor AppArmor is required for protecting programs/servers, for
antivirus software for Windows will provide protection. Then, what is an advantage of using
real Linux kernels, if we cannot allow Linux kernels to use whatever LSM modules users want?
I believe that it is time to get out of "we don't care about out-of-tree code".
The "we don't care about out-of-tree code" reasoning is a brain freeze that leads to
forget about users who still continue using Linux as platform for running their software.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
2022-10-30 4:03 ` Tetsuo Handa
@ 2022-10-30 7:23 ` John Johansen
-1 siblings, 0 replies; 148+ messages in thread
From: John Johansen @ 2022-10-30 7:23 UTC (permalink / raw)
To: Tetsuo Handa, Casey Schaufler, Paul Moore
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook, SElinux list
On 10/29/22 21:03, Tetsuo Handa wrote:
> On 2022/10/28 19:14, John Johansen wrote:
>> On 10/26/22 03:19, Tetsuo Handa wrote:
>>> On 2022/10/26 7:41, Casey Schaufler wrote:
>>>> You need a built-in LSM that loads and manages loadable
>>>> security modules.
>>>
>>> That is no longer loadable LSM modules. A loadable LSM module must be capable of
>>> loading any code and using any interface that is allowed to loadable kernel modules
>>> using /sbin/insmod command. That is my understanding of what you have promised (and
>>> the reason I am allowing you to continue working on LSM stacking before I make
>>> CONFIG_SECURITY_TOMOYO=m).
>>>
>>
>> Tetsuo, think of it this way. LSM stacking is going to make it much easier for new
>> LSM modules because they won't automatically be excluded because one of the other
>> LSMs is needed.
>>
>> The problem of loadable LSM modules is orthogonal, and Casey shouldn't need to
>> solve it in this patch series. That is further work to be taken up by another,
>> as Casey has clearly stated its work he is not interested in doing.
>>
>> However the real problem you are trying to solve won't be solved by loadable LSM
>> modules, though they may help. Just having loadable LSMs modules won't mean a
>> distro will build an LSM as a loadable module instead of disabling it, nor does
>> it mean a distro will allow loading an out of tree LSM module. Even if the
>> upstream kernel doesn't provide an option to block loading them, distros will.
>>
>
> What do you think the background of
>
> Ultimately the challenge is getting userspace developers to accept a
> change that is not part of the upstream Linux Kernel and thus not
> guaranteed under the usual "don't break userspace" kernel API promise.
>
> is? I consider that the reason is because
>
> We do care about userspace programs and users who are using userspace programs.
>
> . If we don't care about userspace and users, we would not mind breaking APIs.
Like it or not kernel developers draw a very distinct line between userspace APIs
and what is considered kernel code.
> This reasoning is more stronger than "we don't care about out-of-tree code"
> reasoning.
>
Look many developers really just don't care about out of tree code, and others
well I won't say they don't care but its impossible task to monitor and think
about how the broad swath of different out of tree code bits could be affected
by kernel changes. So the only practical thing to do is make changes based on
what is in tree and let out of tree projects deal with making the adjustments
needed to adapt to the changing kernel.
This comes about because the kernel does NOT provide a stable ABI for out of
tree code. This is not a technical position as other projects do provide
stable ABIs for out of tree code, with varying degrees of success.
It is a community/political position that is certainly informed by technical
merits but also other considerations, like GPL, experience on the costs of
maintaining stable ABIs and a desire to where possible push for code inclusion
in the kernel.
> Distributors have rights to block loading loadable kernel modules which are
> not included in upstream kernels. But for example Red Hat is not excising
> the rights to block loading loadable kernel modules (e.g.
> https://access.redhat.com/solutions/1376133 ). What do you think about the
> reasons of not blocking loading loadable kernel modules which are not included
> in upstream kernels? I consider that the reason is because
>
> Allowing loadable kernel modules which cannot be supported by distributors
> to exist and to be loaded into distributor kernels is more beneficial for
> users.
>
For some users yes. I am not saying a distro will want to block it for everyone
one every kernel just that they need the option. Ubuntu has taken the position
to try to be as inclusive as possible on the base distro kernels but even with
that position we have special kernels that take a very different approach.
> That is, we have been allowing out-of-tree kernel code to exist because
> out-of-tree kernel code can be beneficial for users despite distributors cannot
> afford supporting out-of-tree kernel code.
>
yes, no argument
> If you really think that we have the rights to lock out out-of-tree kernel code
> and/or disable loading of out-of-tree kernel code via /sbin/insmod, firstly achieve
>
> (1) Disallow loading of non-GPL kernel modules. (It is a trivial change.)
>
I have no desire to get involved the that debate :)
> (2) Disallow loading of out-of-tree kernel code via /sbin/insmod .
Depending on the kernel we do it either by disabling the loading of modules or
via requiring modules to be signed. We have kernels that do this.
> (I don't know how we can technically enforce such change. Unlike not assigning
> LSM id value to LSM modules, we need to somehow be able to check whether an
> arbitrary file is in-tree (e.g. forbid "git add some_file") and unmodified
> (e.g. forbid "patch -p1 < some_patch").
>
Just because LSM ids are currently statically assigned doesn't mean that has to
be the case for all LSMs. I don't see a technical reason why an interface to
request and assign dynamic IDs can't be added in the future.
> before you enforce requiring an LSM id value in order to register an LSM module.
> I don't accept "I'm not interested in making such changes". It is your duty to
> achieve if you use "we don't care about out-of-tree code" as a rationale for
> requiring an LSM id value in order to register an LSM module.
>
As I said before, not a technical problem but a social/political one. I am
sympathetic. I do care about out of tree code, I do see benefit to it, but I also
understand the kernel community not wanting to have to try and make decisions
about kernel code based on it.
The LSM id is far from the only problem out of tree code has to deal with. It has
to deal with changing structures, functions parameters, hooks, functions going
away, changes to locking semantics (rt kernel changes). For out of tree code to
be built against multiple kernels it has to already deal with all of this.
I don't see the LSM id as that different of a barrier and there are certainly
potential paths forward like adding the ability to request an id.
> Nowadays, many software is developed using programming languages which can generate code
> for multiple operating systems. That is, people are getting indifferent with operating
> systems they run their software. Then, what is an advantage of choosing Linux as operating
> systems for running their software, if Linux kernel does not provide freedom for
> customization depending on user's needs?
>
Uhhmmm wow. They can customize Linux to their hearts content, the code is available.
Beyond that Linux has never offered a stable ABI for modules. Only modules built
with the kernel. Yes you can build modules out of tree, but then the module has
to adapt to kernel changes. The LSM id is far from the only change out of tree
code will have to deal with.
> As web application developers increases, developers who can understand C language (and
> system call) are decreasing. As a result, it is getting more and more difficult to let them
> understand and manage fine-grained allowlisting-based access controls like SELinux. Then,
> what is an advantage of choosing Linux as operating systems for running their software, if
> LSM does not provide freedom for using whatever simpler LSM modules users want?
>
Linux does allow this, its just not as easy as it could be, and it is not what
you want. And if this is what those application developers need then maybe Linux
is not the right platform for them.
Like it or not, not exporting the security_hook_heads was not a technical
decision. I am not opposed to
EXPORT_SYMBOL_GPL(security_hook_heads)
but others are and I don't know how to change that.
> Windows operating system provides WSL (Windows Subsystem for Linux) which allows running
> CUI programs and servers which are designed for Linux. Windows users can run CUI programs
> and servers without requiring real Linux kernels and can run GUI programs via Windows
> kernels. Neither SELinux nor AppArmor is required for protecting programs/servers, for
Actually WSL2 is now preferred over WSL and it does use the Linux kernel.
> antivirus software for Windows will provide protection. Then, what is an advantage of using
> real Linux kernels, if we cannot allow Linux kernels to use whatever LSM modules users want?
>
Sorry I don't see the argument. With that sad I will say the Window kernel
doesn't allow running arbitrary out of tree code. Modules must be signed and
the Kernel is closed source. So if you want something custom Linux is ahead
of the game there.
Would I like to see more LSM modules, yes. That is part of why I want stacking
to land. We have been faffing around on its details for 10+ years, and I
think we likely would have seen more modules by now if it had landed. I
also think having it landed would allow for people to propose patches to
extend and improve it instead of arguing about it.
> I believe that it is time to get out of "we don't care about out-of-tree code".
Unless Linux is willing to offer a stable ABIs to out of tree code this is
impossible. Developers just can't consider all the out of tree code when they
are making code changes. And I don't see Linux being willing to offer a
stable ABI to out of tree modules.
> The "we don't care about out-of-tree code" reasoning is a brain freeze that leads to
> forget about users who still continue using Linux as platform for running their software.
>
I get what you are saying. But again this isn't a technical problem and
I don't have a solution. What we need right now is constructive review
and preferably code to move patches forward so we can get stacking landed.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-10-30 7:23 ` John Johansen
0 siblings, 0 replies; 148+ messages in thread
From: John Johansen @ 2022-10-30 7:23 UTC (permalink / raw)
To: Tetsuo Handa, Casey Schaufler, Paul Moore
Cc: keescook, SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On 10/29/22 21:03, Tetsuo Handa wrote:
> On 2022/10/28 19:14, John Johansen wrote:
>> On 10/26/22 03:19, Tetsuo Handa wrote:
>>> On 2022/10/26 7:41, Casey Schaufler wrote:
>>>> You need a built-in LSM that loads and manages loadable
>>>> security modules.
>>>
>>> That is no longer loadable LSM modules. A loadable LSM module must be capable of
>>> loading any code and using any interface that is allowed to loadable kernel modules
>>> using /sbin/insmod command. That is my understanding of what you have promised (and
>>> the reason I am allowing you to continue working on LSM stacking before I make
>>> CONFIG_SECURITY_TOMOYO=m).
>>>
>>
>> Tetsuo, think of it this way. LSM stacking is going to make it much easier for new
>> LSM modules because they won't automatically be excluded because one of the other
>> LSMs is needed.
>>
>> The problem of loadable LSM modules is orthogonal, and Casey shouldn't need to
>> solve it in this patch series. That is further work to be taken up by another,
>> as Casey has clearly stated its work he is not interested in doing.
>>
>> However the real problem you are trying to solve won't be solved by loadable LSM
>> modules, though they may help. Just having loadable LSMs modules won't mean a
>> distro will build an LSM as a loadable module instead of disabling it, nor does
>> it mean a distro will allow loading an out of tree LSM module. Even if the
>> upstream kernel doesn't provide an option to block loading them, distros will.
>>
>
> What do you think the background of
>
> Ultimately the challenge is getting userspace developers to accept a
> change that is not part of the upstream Linux Kernel and thus not
> guaranteed under the usual "don't break userspace" kernel API promise.
>
> is? I consider that the reason is because
>
> We do care about userspace programs and users who are using userspace programs.
>
> . If we don't care about userspace and users, we would not mind breaking APIs.
Like it or not kernel developers draw a very distinct line between userspace APIs
and what is considered kernel code.
> This reasoning is more stronger than "we don't care about out-of-tree code"
> reasoning.
>
Look many developers really just don't care about out of tree code, and others
well I won't say they don't care but its impossible task to monitor and think
about how the broad swath of different out of tree code bits could be affected
by kernel changes. So the only practical thing to do is make changes based on
what is in tree and let out of tree projects deal with making the adjustments
needed to adapt to the changing kernel.
This comes about because the kernel does NOT provide a stable ABI for out of
tree code. This is not a technical position as other projects do provide
stable ABIs for out of tree code, with varying degrees of success.
It is a community/political position that is certainly informed by technical
merits but also other considerations, like GPL, experience on the costs of
maintaining stable ABIs and a desire to where possible push for code inclusion
in the kernel.
> Distributors have rights to block loading loadable kernel modules which are
> not included in upstream kernels. But for example Red Hat is not excising
> the rights to block loading loadable kernel modules (e.g.
> https://access.redhat.com/solutions/1376133 ). What do you think about the
> reasons of not blocking loading loadable kernel modules which are not included
> in upstream kernels? I consider that the reason is because
>
> Allowing loadable kernel modules which cannot be supported by distributors
> to exist and to be loaded into distributor kernels is more beneficial for
> users.
>
For some users yes. I am not saying a distro will want to block it for everyone
one every kernel just that they need the option. Ubuntu has taken the position
to try to be as inclusive as possible on the base distro kernels but even with
that position we have special kernels that take a very different approach.
> That is, we have been allowing out-of-tree kernel code to exist because
> out-of-tree kernel code can be beneficial for users despite distributors cannot
> afford supporting out-of-tree kernel code.
>
yes, no argument
> If you really think that we have the rights to lock out out-of-tree kernel code
> and/or disable loading of out-of-tree kernel code via /sbin/insmod, firstly achieve
>
> (1) Disallow loading of non-GPL kernel modules. (It is a trivial change.)
>
I have no desire to get involved the that debate :)
> (2) Disallow loading of out-of-tree kernel code via /sbin/insmod .
Depending on the kernel we do it either by disabling the loading of modules or
via requiring modules to be signed. We have kernels that do this.
> (I don't know how we can technically enforce such change. Unlike not assigning
> LSM id value to LSM modules, we need to somehow be able to check whether an
> arbitrary file is in-tree (e.g. forbid "git add some_file") and unmodified
> (e.g. forbid "patch -p1 < some_patch").
>
Just because LSM ids are currently statically assigned doesn't mean that has to
be the case for all LSMs. I don't see a technical reason why an interface to
request and assign dynamic IDs can't be added in the future.
> before you enforce requiring an LSM id value in order to register an LSM module.
> I don't accept "I'm not interested in making such changes". It is your duty to
> achieve if you use "we don't care about out-of-tree code" as a rationale for
> requiring an LSM id value in order to register an LSM module.
>
As I said before, not a technical problem but a social/political one. I am
sympathetic. I do care about out of tree code, I do see benefit to it, but I also
understand the kernel community not wanting to have to try and make decisions
about kernel code based on it.
The LSM id is far from the only problem out of tree code has to deal with. It has
to deal with changing structures, functions parameters, hooks, functions going
away, changes to locking semantics (rt kernel changes). For out of tree code to
be built against multiple kernels it has to already deal with all of this.
I don't see the LSM id as that different of a barrier and there are certainly
potential paths forward like adding the ability to request an id.
> Nowadays, many software is developed using programming languages which can generate code
> for multiple operating systems. That is, people are getting indifferent with operating
> systems they run their software. Then, what is an advantage of choosing Linux as operating
> systems for running their software, if Linux kernel does not provide freedom for
> customization depending on user's needs?
>
Uhhmmm wow. They can customize Linux to their hearts content, the code is available.
Beyond that Linux has never offered a stable ABI for modules. Only modules built
with the kernel. Yes you can build modules out of tree, but then the module has
to adapt to kernel changes. The LSM id is far from the only change out of tree
code will have to deal with.
> As web application developers increases, developers who can understand C language (and
> system call) are decreasing. As a result, it is getting more and more difficult to let them
> understand and manage fine-grained allowlisting-based access controls like SELinux. Then,
> what is an advantage of choosing Linux as operating systems for running their software, if
> LSM does not provide freedom for using whatever simpler LSM modules users want?
>
Linux does allow this, its just not as easy as it could be, and it is not what
you want. And if this is what those application developers need then maybe Linux
is not the right platform for them.
Like it or not, not exporting the security_hook_heads was not a technical
decision. I am not opposed to
EXPORT_SYMBOL_GPL(security_hook_heads)
but others are and I don't know how to change that.
> Windows operating system provides WSL (Windows Subsystem for Linux) which allows running
> CUI programs and servers which are designed for Linux. Windows users can run CUI programs
> and servers without requiring real Linux kernels and can run GUI programs via Windows
> kernels. Neither SELinux nor AppArmor is required for protecting programs/servers, for
Actually WSL2 is now preferred over WSL and it does use the Linux kernel.
> antivirus software for Windows will provide protection. Then, what is an advantage of using
> real Linux kernels, if we cannot allow Linux kernels to use whatever LSM modules users want?
>
Sorry I don't see the argument. With that sad I will say the Window kernel
doesn't allow running arbitrary out of tree code. Modules must be signed and
the Kernel is closed source. So if you want something custom Linux is ahead
of the game there.
Would I like to see more LSM modules, yes. That is part of why I want stacking
to land. We have been faffing around on its details for 10+ years, and I
think we likely would have seen more modules by now if it had landed. I
also think having it landed would allow for people to propose patches to
extend and improve it instead of arguing about it.
> I believe that it is time to get out of "we don't care about out-of-tree code".
Unless Linux is willing to offer a stable ABIs to out of tree code this is
impossible. Developers just can't consider all the out of tree code when they
are making code changes. And I don't see Linux being willing to offer a
stable ABI to out of tree modules.
> The "we don't care about out-of-tree code" reasoning is a brain freeze that leads to
> forget about users who still continue using Linux as platform for running their software.
>
I get what you are saying. But again this isn't a technical problem and
I don't have a solution. What we need right now is constructive review
and preferably code to move patches forward so we can get stacking landed.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-10-30 7:23 ` John Johansen
@ 2022-10-30 14:02 ` Tetsuo Handa
-1 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-10-30 14:02 UTC (permalink / raw)
To: John Johansen, Casey Schaufler, Paul Moore
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook, SElinux list
On 2022/10/30 16:23, John Johansen wrote:
>> This reasoning is more stronger than "we don't care about out-of-tree code"
>> reasoning.
>>
> Look many developers really just don't care about out of tree code, and others
> well I won't say they don't care but its impossible task to monitor and think
> about how the broad swath of different out of tree code bits could be affected
> by kernel changes. So the only practical thing to do is make changes based on
> what is in tree and let out of tree projects deal with making the adjustments
> needed to adapt to the changing kernel.
I don't care that out of tree projects have to deal with the burden of making
the adjustments needed to adapt to the changing kernel. But I do care that
out of tree projects are allowed to make the adjustments needed to adapt to
the changing kernel.
Think about the PCI ID Repository ( https://pci-ids.ucw.cz ) as an example.
A PCI ID value can be assigned to a hardware device, regardless of whether
a device driver for Linux kernel is available in the upstream kernel.
Casey's patchset is trying to provide LSM ID Repository for userspace programs.
But an LSM ID value cannot be assigned to that LSM unless that module is
available in the upstream kernel. This means that, developers are not allowed
to develop a new LSM module even with the intention to become available in the
upstream kernel, for there always is a risk of LSM ID collision which the LSM ID
Repository should have avoided from the beginning. Also, this means that, unlike
PCI devices, users are not allowed to use out-of-tree LSM modules which have to
remain out-of-tree due to proposed-but-not-accepted by the upstream kernel.
This is a serious bug; is LSM a proprietary/closed code where modification is
impossible due to an End-User License Agreement?
You have only three choices:
(1) allow assigning LSM ID integer value to all LSM modules (regardless of
whether that module was merged into upstream kernel)
(2) use module name string value as LSM ID
(3) dynamically assign LSM ID integer value when an LSM module is registered
There never is fourth choice:
(4) assigning LSM ID integer value to only LSM modules which were merged
into upstream kernel
The fourth choice is complete lockout of out of tree projects.
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
@ 2022-10-30 14:02 ` Tetsuo Handa
0 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-10-30 14:02 UTC (permalink / raw)
To: John Johansen, Casey Schaufler, Paul Moore
Cc: keescook, SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On 2022/10/30 16:23, John Johansen wrote:
>> This reasoning is more stronger than "we don't care about out-of-tree code"
>> reasoning.
>>
> Look many developers really just don't care about out of tree code, and others
> well I won't say they don't care but its impossible task to monitor and think
> about how the broad swath of different out of tree code bits could be affected
> by kernel changes. So the only practical thing to do is make changes based on
> what is in tree and let out of tree projects deal with making the adjustments
> needed to adapt to the changing kernel.
I don't care that out of tree projects have to deal with the burden of making
the adjustments needed to adapt to the changing kernel. But I do care that
out of tree projects are allowed to make the adjustments needed to adapt to
the changing kernel.
Think about the PCI ID Repository ( https://pci-ids.ucw.cz ) as an example.
A PCI ID value can be assigned to a hardware device, regardless of whether
a device driver for Linux kernel is available in the upstream kernel.
Casey's patchset is trying to provide LSM ID Repository for userspace programs.
But an LSM ID value cannot be assigned to that LSM unless that module is
available in the upstream kernel. This means that, developers are not allowed
to develop a new LSM module even with the intention to become available in the
upstream kernel, for there always is a risk of LSM ID collision which the LSM ID
Repository should have avoided from the beginning. Also, this means that, unlike
PCI devices, users are not allowed to use out-of-tree LSM modules which have to
remain out-of-tree due to proposed-but-not-accepted by the upstream kernel.
This is a serious bug; is LSM a proprietary/closed code where modification is
impossible due to an End-User License Agreement?
You have only three choices:
(1) allow assigning LSM ID integer value to all LSM modules (regardless of
whether that module was merged into upstream kernel)
(2) use module name string value as LSM ID
(3) dynamically assign LSM ID integer value when an LSM module is registered
There never is fourth choice:
(4) assigning LSM ID integer value to only LSM modules which were merged
into upstream kernel
The fourth choice is complete lockout of out of tree projects.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
2022-10-30 14:02 ` Tetsuo Handa
@ 2022-10-30 16:37 ` Kees Cook
-1 siblings, 0 replies; 148+ messages in thread
From: Kees Cook @ 2022-10-30 16:37 UTC (permalink / raw)
To: Tetsuo Handa, John Johansen, Casey Schaufler, Paul Moore
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook, SElinux list
On October 30, 2022 7:02:52 AM PDT, Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:
>Casey's patchset is trying to provide LSM ID Repository for userspace programs.
>But an LSM ID value cannot be assigned to that LSM unless that module is
>available in the upstream kernel. This means that, developers are not allowed
>to develop a new LSM module even with the intention to become available in the
>upstream kernel, for there always is a risk of LSM ID collision which the LSM ID
>Repository should have avoided from the beginning. Also, this means that, unlike
>PCI devices, users are not allowed to use out-of-tree LSM modules which have to
>remain out-of-tree due to proposed-but-not-accepted by the upstream kernel.
>This is a serious bug; is LSM a proprietary/closed code where modification is
>impossible due to an End-User License Agreement?
You are way off in the weeds with false equivalencies.
>You have only three choices:
>
> (1) allow assigning LSM ID integer value to all LSM modules (regardless of
> whether that module was merged into upstream kernel)
We are not hardware manufacturers.
> (2) use module name string value as LSM ID
This results is greater code complexity. If you see a way to do this, send a patch. Instead of unhelpfully saying "no, do it differently", show a solution.
> (3) dynamically assign LSM ID integer value when an LSM module is registered
Again, send a patch.
>There never is fourth choice:
>
> (4) assigning LSM ID integer value to only LSM modules which were merged
> into upstream kernel
>
>The fourth choice is complete lockout of out of tree projects.
This is just not a real outcome. How is this any different from syscalls, capability bits, prctl values, ELF flags, etc?
--
Kees Cook
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-10-30 16:37 ` Kees Cook
0 siblings, 0 replies; 148+ messages in thread
From: Kees Cook @ 2022-10-30 16:37 UTC (permalink / raw)
To: Tetsuo Handa, John Johansen, Casey Schaufler, Paul Moore
Cc: keescook, SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On October 30, 2022 7:02:52 AM PDT, Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:
>Casey's patchset is trying to provide LSM ID Repository for userspace programs.
>But an LSM ID value cannot be assigned to that LSM unless that module is
>available in the upstream kernel. This means that, developers are not allowed
>to develop a new LSM module even with the intention to become available in the
>upstream kernel, for there always is a risk of LSM ID collision which the LSM ID
>Repository should have avoided from the beginning. Also, this means that, unlike
>PCI devices, users are not allowed to use out-of-tree LSM modules which have to
>remain out-of-tree due to proposed-but-not-accepted by the upstream kernel.
>This is a serious bug; is LSM a proprietary/closed code where modification is
>impossible due to an End-User License Agreement?
You are way off in the weeds with false equivalencies.
>You have only three choices:
>
> (1) allow assigning LSM ID integer value to all LSM modules (regardless of
> whether that module was merged into upstream kernel)
We are not hardware manufacturers.
> (2) use module name string value as LSM ID
This results is greater code complexity. If you see a way to do this, send a patch. Instead of unhelpfully saying "no, do it differently", show a solution.
> (3) dynamically assign LSM ID integer value when an LSM module is registered
Again, send a patch.
>There never is fourth choice:
>
> (4) assigning LSM ID integer value to only LSM modules which were merged
> into upstream kernel
>
>The fourth choice is complete lockout of out of tree projects.
This is just not a real outcome. How is this any different from syscalls, capability bits, prctl values, ELF flags, etc?
--
Kees Cook
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-10-30 16:37 ` Kees Cook
@ 2022-10-30 20:56 ` Casey Schaufler
-1 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-10-30 20:56 UTC (permalink / raw)
To: Kees Cook, Tetsuo Handa, John Johansen, Paul Moore
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook,
SElinux list, casey
On 10/30/2022 9:37 AM, Kees Cook wrote:
> On October 30, 2022 7:02:52 AM PDT, Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:
>> Casey's patchset is trying to provide LSM ID Repository for userspace programs.
>> But an LSM ID value cannot be assigned to that LSM unless that module is
>> available in the upstream kernel. This means that, developers are not allowed
>> to develop a new LSM module even with the intention to become available in the
>> upstream kernel, for there always is a risk of LSM ID collision which the LSM ID
>> Repository should have avoided from the beginning. Also, this means that, unlike
>> PCI devices, users are not allowed to use out-of-tree LSM modules which have to
>> remain out-of-tree due to proposed-but-not-accepted by the upstream kernel.
>> This is a serious bug; is LSM a proprietary/closed code where modification is
>> impossible due to an End-User License Agreement?
> You are way off in the weeds with false equivalencies.
>
>> You have only three choices:
>>
>> (1) allow assigning LSM ID integer value to all LSM modules (regardless of
>> whether that module was merged into upstream kernel)
> We are not hardware manufacturers.
>
>> (2) use module name string value as LSM ID
> This results is greater code complexity. If you see a way to do this, send a patch. Instead of unhelpfully saying "no, do it differently", show a solution.
>
>> (3) dynamically assign LSM ID integer value when an LSM module is registered
> Again, send a patch.
>
>> There never is fourth choice:
>>
>> (4) assigning LSM ID integer value to only LSM modules which were merged
>> into upstream kernel
>>
>> The fourth choice is complete lockout of out of tree projects.
> This is just not a real outcome. How is this any different from syscalls, capability bits, prctl values, ELF flags, etc?
>
Loadability and the LSM ID are completely separate issues. Show me a patch
that implements loading modules and I will show you how to change it to
accommodate the LSM ID. That is, if it isn't obvious at that point.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-10-30 20:56 ` Casey Schaufler
0 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-10-30 20:56 UTC (permalink / raw)
To: Kees Cook, Tetsuo Handa, John Johansen, Paul Moore
Cc: keescook, SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On 10/30/2022 9:37 AM, Kees Cook wrote:
> On October 30, 2022 7:02:52 AM PDT, Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:
>> Casey's patchset is trying to provide LSM ID Repository for userspace programs.
>> But an LSM ID value cannot be assigned to that LSM unless that module is
>> available in the upstream kernel. This means that, developers are not allowed
>> to develop a new LSM module even with the intention to become available in the
>> upstream kernel, for there always is a risk of LSM ID collision which the LSM ID
>> Repository should have avoided from the beginning. Also, this means that, unlike
>> PCI devices, users are not allowed to use out-of-tree LSM modules which have to
>> remain out-of-tree due to proposed-but-not-accepted by the upstream kernel.
>> This is a serious bug; is LSM a proprietary/closed code where modification is
>> impossible due to an End-User License Agreement?
> You are way off in the weeds with false equivalencies.
>
>> You have only three choices:
>>
>> (1) allow assigning LSM ID integer value to all LSM modules (regardless of
>> whether that module was merged into upstream kernel)
> We are not hardware manufacturers.
>
>> (2) use module name string value as LSM ID
> This results is greater code complexity. If you see a way to do this, send a patch. Instead of unhelpfully saying "no, do it differently", show a solution.
>
>> (3) dynamically assign LSM ID integer value when an LSM module is registered
> Again, send a patch.
>
>> There never is fourth choice:
>>
>> (4) assigning LSM ID integer value to only LSM modules which were merged
>> into upstream kernel
>>
>> The fourth choice is complete lockout of out of tree projects.
> This is just not a real outcome. How is this any different from syscalls, capability bits, prctl values, ELF flags, etc?
>
Loadability and the LSM ID are completely separate issues. Show me a patch
that implements loading modules and I will show you how to change it to
accommodate the LSM ID. That is, if it isn't obvious at that point.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-10-30 16:37 ` Kees Cook
@ 2022-10-31 10:26 ` Tetsuo Handa
-1 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-10-31 10:26 UTC (permalink / raw)
To: Kees Cook, John Johansen, Casey Schaufler, Paul Moore
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook, SElinux list
On 2022/10/31 1:37, Kees Cook wrote:
>> You have only three choices:
>>
>> (1) allow assigning LSM ID integer value to all LSM modules (regardless of
>> whether that module was merged into upstream kernel)
>
> We are not hardware manufacturers.
>
Excuse me? We are not talking about whether we are hardware manufacturers.
We are talking about the policy for assigning identifier.
I don't like how LSM IDs are assigned, for Casey said
>> If the upstream kernel assigns an LSM id for all LSM modules including out-of-tree
>> and/or private LSM modules (that's why I described that the upstream kernel behaves
>> as if a DNS registerer), we can assign LSM id = 100 to "belllapadula" from A and
>> LSM id = 101 to "belllapadula" from B, and both "belllapadula" modules can work
>> without conflicts by using LSM id. Of course, this implies that we need to preserve
>> unused space in lsm_idlist[LSMID_ENTRIES] etc. for such LSM modules (if we use
>> fixed-sized array rather than a linked list).
>
> Of course the upstream kernel isn't going to have LSM IDs for out-of-tree
> security modules. That's one of many reasons loadable modules are going to
> have to be treated differently from built-in modules, if they're allowed
> at all.
at https://lkml.kernel.org/r/7263e155-9024-0508-370c-72692901b326@schaufler-ca.com and
Paul confirmed
>> Currently anyone can start writing new LSM modules using name as identifier. But
>> you are trying to forbid using name as identifier, and trying to force using integer
>> as identifier, but that integer will not be provided unless new LSM modules get
>> upstream.
>
> That is correct. In order to have a LSM identifier token the LSM must
> be upstream.
at https://lkml.kernel.org/r/CAHC9VhT2Azg1F-G3RQ4xL7JgA3OAtHafzS1_nvUyEUFsCJ9+SA@mail.gmail.com .
If we can agree that the upstream kernel never refuse to assign LSM IDs to whatever
LSM modules, I'm OK that we introduce LSM ID integer value itself.
My next concern is that we are trying to use fixed sized capacity as LSMID_ENTRIES,
commented
On 2022/10/13 19:04, Tetsuo Handa wrote:
> On 2022/09/28 4:53, Casey Schaufler wrote:
>> + if (lsm_id > LSMID_ENTRIES)
>> + panic("%s Too many LSMs registered.\n", __func__);
>
> I'm not happy with LSMID_ENTRIES. This is a way towards forever forbidding LKM-based LSMs.
at https://lkml.kernel.org/r/9907d724-4668-cd50-7454-1a8ca86542b0@I-love.SAKURA.ne.jp , for
struct lsm_id *lsm_idlist[LSMID_ENTRIES] __lsm_ro_after_init;
may cause out-of-tree LSM modules to fail to use the slot.
It is a strange hack that users have to enable in-tree LSM modules or rewrite the
definition of LSMID_ENTRIES in order to use out-of-tree (either built-in or loadable)
LSM modules, for LSMID_ENTRIES is defined based on only in-tree LSM modules.
#define LSMID_ENTRIES ( \
1 + /* capabilities */ \
(IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
(IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
(IS_ENABLED(CONFIG_SECURITY_TOMOYO) ? 1 : 0) + \
(IS_ENABLED(CONFIG_SECURITY_IMA) ? 1 : 0) + \
(IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
(IS_ENABLED(CONFIG_SECURITY_YAMA) ? 1 : 0) + \
(IS_ENABLED(CONFIG_SECURITY_LOADPIN) ? 1 : 0) + \
(IS_ENABLED(CONFIG_SECURITY_SAFESETID) ? 1 : 0) + \
(IS_ENABLED(CONFIG_SECURITY_LOCKDOWN) ? 1 : 0) + \
(IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0) + \
(IS_ENABLED(CONFIG_SECURITY_LANDLOCK) ? 1 : 0))
Although built-in out-of-tree LSM modules would be able to rewrite LSMID_ENTRIES definition
because users will rebuild the whole kernel, loadable out-of-tree LSM modules would not be
able to rewrite LSMID_ENTRIES definition because users will not rebuild the whole kernel.
It is still effectively a lock out for loadable out-of-tree LSM modules even if the problem
of assigning LSM ID integer value is solved.
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
@ 2022-10-31 10:26 ` Tetsuo Handa
0 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-10-31 10:26 UTC (permalink / raw)
To: Kees Cook, John Johansen, Casey Schaufler, Paul Moore
Cc: keescook, SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On 2022/10/31 1:37, Kees Cook wrote:
>> You have only three choices:
>>
>> (1) allow assigning LSM ID integer value to all LSM modules (regardless of
>> whether that module was merged into upstream kernel)
>
> We are not hardware manufacturers.
>
Excuse me? We are not talking about whether we are hardware manufacturers.
We are talking about the policy for assigning identifier.
I don't like how LSM IDs are assigned, for Casey said
>> If the upstream kernel assigns an LSM id for all LSM modules including out-of-tree
>> and/or private LSM modules (that's why I described that the upstream kernel behaves
>> as if a DNS registerer), we can assign LSM id = 100 to "belllapadula" from A and
>> LSM id = 101 to "belllapadula" from B, and both "belllapadula" modules can work
>> without conflicts by using LSM id. Of course, this implies that we need to preserve
>> unused space in lsm_idlist[LSMID_ENTRIES] etc. for such LSM modules (if we use
>> fixed-sized array rather than a linked list).
>
> Of course the upstream kernel isn't going to have LSM IDs for out-of-tree
> security modules. That's one of many reasons loadable modules are going to
> have to be treated differently from built-in modules, if they're allowed
> at all.
at https://lkml.kernel.org/r/7263e155-9024-0508-370c-72692901b326@schaufler-ca.com and
Paul confirmed
>> Currently anyone can start writing new LSM modules using name as identifier. But
>> you are trying to forbid using name as identifier, and trying to force using integer
>> as identifier, but that integer will not be provided unless new LSM modules get
>> upstream.
>
> That is correct. In order to have a LSM identifier token the LSM must
> be upstream.
at https://lkml.kernel.org/r/CAHC9VhT2Azg1F-G3RQ4xL7JgA3OAtHafzS1_nvUyEUFsCJ9+SA@mail.gmail.com .
If we can agree that the upstream kernel never refuse to assign LSM IDs to whatever
LSM modules, I'm OK that we introduce LSM ID integer value itself.
My next concern is that we are trying to use fixed sized capacity as LSMID_ENTRIES,
commented
On 2022/10/13 19:04, Tetsuo Handa wrote:
> On 2022/09/28 4:53, Casey Schaufler wrote:
>> + if (lsm_id > LSMID_ENTRIES)
>> + panic("%s Too many LSMs registered.\n", __func__);
>
> I'm not happy with LSMID_ENTRIES. This is a way towards forever forbidding LKM-based LSMs.
at https://lkml.kernel.org/r/9907d724-4668-cd50-7454-1a8ca86542b0@I-love.SAKURA.ne.jp , for
struct lsm_id *lsm_idlist[LSMID_ENTRIES] __lsm_ro_after_init;
may cause out-of-tree LSM modules to fail to use the slot.
It is a strange hack that users have to enable in-tree LSM modules or rewrite the
definition of LSMID_ENTRIES in order to use out-of-tree (either built-in or loadable)
LSM modules, for LSMID_ENTRIES is defined based on only in-tree LSM modules.
#define LSMID_ENTRIES ( \
1 + /* capabilities */ \
(IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
(IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
(IS_ENABLED(CONFIG_SECURITY_TOMOYO) ? 1 : 0) + \
(IS_ENABLED(CONFIG_SECURITY_IMA) ? 1 : 0) + \
(IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
(IS_ENABLED(CONFIG_SECURITY_YAMA) ? 1 : 0) + \
(IS_ENABLED(CONFIG_SECURITY_LOADPIN) ? 1 : 0) + \
(IS_ENABLED(CONFIG_SECURITY_SAFESETID) ? 1 : 0) + \
(IS_ENABLED(CONFIG_SECURITY_LOCKDOWN) ? 1 : 0) + \
(IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0) + \
(IS_ENABLED(CONFIG_SECURITY_LANDLOCK) ? 1 : 0))
Although built-in out-of-tree LSM modules would be able to rewrite LSMID_ENTRIES definition
because users will rebuild the whole kernel, loadable out-of-tree LSM modules would not be
able to rewrite LSMID_ENTRIES definition because users will not rebuild the whole kernel.
It is still effectively a lock out for loadable out-of-tree LSM modules even if the problem
of assigning LSM ID integer value is solved.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
2022-10-31 10:26 ` Tetsuo Handa
@ 2022-10-31 15:47 ` Casey Schaufler
-1 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-10-31 15:47 UTC (permalink / raw)
To: Tetsuo Handa, Kees Cook, John Johansen, Paul Moore
Cc: LSM List, James Morris, linux-audit, Mimi Zohar, keescook,
SElinux list, casey
On 10/31/2022 3:26 AM, Tetsuo Handa wrote:
> On 2022/10/31 1:37, Kees Cook wrote:
>>> You have only three choices:
>>>
>>> (1) allow assigning LSM ID integer value to all LSM modules (regardless of
>>> whether that module was merged into upstream kernel)
>> We are not hardware manufacturers.
>>
> Excuse me? We are not talking about whether we are hardware manufacturers.
> We are talking about the policy for assigning identifier.
>
> I don't like how LSM IDs are assigned, for Casey said
>
> >> If the upstream kernel assigns an LSM id for all LSM modules including out-of-tree
> >> and/or private LSM modules (that's why I described that the upstream kernel behaves
> >> as if a DNS registerer), we can assign LSM id = 100 to "belllapadula" from A and
> >> LSM id = 101 to "belllapadula" from B, and both "belllapadula" modules can work
> >> without conflicts by using LSM id. Of course, this implies that we need to preserve
> >> unused space in lsm_idlist[LSMID_ENTRIES] etc. for such LSM modules (if we use
> >> fixed-sized array rather than a linked list).
> >
> > Of course the upstream kernel isn't going to have LSM IDs for out-of-tree
> > security modules. That's one of many reasons loadable modules are going to
> > have to be treated differently from built-in modules, if they're allowed
> > at all.
>
> at https://lkml.kernel.org/r/7263e155-9024-0508-370c-72692901b326@schaufler-ca.com and
> Paul confirmed
>
> >> Currently anyone can start writing new LSM modules using name as identifier. But
> >> you are trying to forbid using name as identifier, and trying to force using integer
> >> as identifier, but that integer will not be provided unless new LSM modules get
> >> upstream.
> >
> > That is correct. In order to have a LSM identifier token the LSM must
> > be upstream.
>
> at https://lkml.kernel.org/r/CAHC9VhT2Azg1F-G3RQ4xL7JgA3OAtHafzS1_nvUyEUFsCJ9+SA@mail.gmail.com .
>
> If we can agree that the upstream kernel never refuse to assign LSM IDs to whatever
> LSM modules, I'm OK that we introduce LSM ID integer value itself.
>
>
>
> My next concern is that we are trying to use fixed sized capacity as LSMID_ENTRIES,
> commented
>
> On 2022/10/13 19:04, Tetsuo Handa wrote:
> > On 2022/09/28 4:53, Casey Schaufler wrote:
> >> + if (lsm_id > LSMID_ENTRIES)
> >> + panic("%s Too many LSMs registered.\n", __func__);
> >
> > I'm not happy with LSMID_ENTRIES. This is a way towards forever forbidding LKM-based LSMs.
>
> at https://lkml.kernel.org/r/9907d724-4668-cd50-7454-1a8ca86542b0@I-love.SAKURA.ne.jp , for
>
> struct lsm_id *lsm_idlist[LSMID_ENTRIES] __lsm_ro_after_init;
>
> may cause out-of-tree LSM modules to fail to use the slot.
>
> It is a strange hack that users have to enable in-tree LSM modules or rewrite the
> definition of LSMID_ENTRIES in order to use out-of-tree (either built-in or loadable)
> LSM modules, for LSMID_ENTRIES is defined based on only in-tree LSM modules.
>
> #define LSMID_ENTRIES ( \
> 1 + /* capabilities */ \
> (IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
> (IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
> (IS_ENABLED(CONFIG_SECURITY_TOMOYO) ? 1 : 0) + \
> (IS_ENABLED(CONFIG_SECURITY_IMA) ? 1 : 0) + \
> (IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
> (IS_ENABLED(CONFIG_SECURITY_YAMA) ? 1 : 0) + \
> (IS_ENABLED(CONFIG_SECURITY_LOADPIN) ? 1 : 0) + \
> (IS_ENABLED(CONFIG_SECURITY_SAFESETID) ? 1 : 0) + \
> (IS_ENABLED(CONFIG_SECURITY_LOCKDOWN) ? 1 : 0) + \
> (IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0) + \
> (IS_ENABLED(CONFIG_SECURITY_LANDLOCK) ? 1 : 0))
>
> Although built-in out-of-tree LSM modules would be able to rewrite LSMID_ENTRIES definition
> because users will rebuild the whole kernel, loadable out-of-tree LSM modules would not be
> able to rewrite LSMID_ENTRIES definition because users will not rebuild the whole kernel.
> It is still effectively a lock out for loadable out-of-tree LSM modules even if the problem
> of assigning LSM ID integer value is solved.
Propose an implementation of security module loading. If LSMID_ENTRIES is a problem
I will help you resolve the issue. My bet is that there will be an easy solution. It
may be as simple as adding (IS_ENABLED(CONFIG_SECURITY_LOADABLE) ? 1 : 0) + \ to the
code referenced above. But I can't say until I see how you're going to address all
of the real issues.
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
@ 2022-10-31 15:47 ` Casey Schaufler
0 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-10-31 15:47 UTC (permalink / raw)
To: Tetsuo Handa, Kees Cook, John Johansen, Paul Moore
Cc: keescook, SElinux list, James Morris, Mimi Zohar, LSM List, linux-audit
On 10/31/2022 3:26 AM, Tetsuo Handa wrote:
> On 2022/10/31 1:37, Kees Cook wrote:
>>> You have only three choices:
>>>
>>> (1) allow assigning LSM ID integer value to all LSM modules (regardless of
>>> whether that module was merged into upstream kernel)
>> We are not hardware manufacturers.
>>
> Excuse me? We are not talking about whether we are hardware manufacturers.
> We are talking about the policy for assigning identifier.
>
> I don't like how LSM IDs are assigned, for Casey said
>
> >> If the upstream kernel assigns an LSM id for all LSM modules including out-of-tree
> >> and/or private LSM modules (that's why I described that the upstream kernel behaves
> >> as if a DNS registerer), we can assign LSM id = 100 to "belllapadula" from A and
> >> LSM id = 101 to "belllapadula" from B, and both "belllapadula" modules can work
> >> without conflicts by using LSM id. Of course, this implies that we need to preserve
> >> unused space in lsm_idlist[LSMID_ENTRIES] etc. for such LSM modules (if we use
> >> fixed-sized array rather than a linked list).
> >
> > Of course the upstream kernel isn't going to have LSM IDs for out-of-tree
> > security modules. That's one of many reasons loadable modules are going to
> > have to be treated differently from built-in modules, if they're allowed
> > at all.
>
> at https://lkml.kernel.org/r/7263e155-9024-0508-370c-72692901b326@schaufler-ca.com and
> Paul confirmed
>
> >> Currently anyone can start writing new LSM modules using name as identifier. But
> >> you are trying to forbid using name as identifier, and trying to force using integer
> >> as identifier, but that integer will not be provided unless new LSM modules get
> >> upstream.
> >
> > That is correct. In order to have a LSM identifier token the LSM must
> > be upstream.
>
> at https://lkml.kernel.org/r/CAHC9VhT2Azg1F-G3RQ4xL7JgA3OAtHafzS1_nvUyEUFsCJ9+SA@mail.gmail.com .
>
> If we can agree that the upstream kernel never refuse to assign LSM IDs to whatever
> LSM modules, I'm OK that we introduce LSM ID integer value itself.
>
>
>
> My next concern is that we are trying to use fixed sized capacity as LSMID_ENTRIES,
> commented
>
> On 2022/10/13 19:04, Tetsuo Handa wrote:
> > On 2022/09/28 4:53, Casey Schaufler wrote:
> >> + if (lsm_id > LSMID_ENTRIES)
> >> + panic("%s Too many LSMs registered.\n", __func__);
> >
> > I'm not happy with LSMID_ENTRIES. This is a way towards forever forbidding LKM-based LSMs.
>
> at https://lkml.kernel.org/r/9907d724-4668-cd50-7454-1a8ca86542b0@I-love.SAKURA.ne.jp , for
>
> struct lsm_id *lsm_idlist[LSMID_ENTRIES] __lsm_ro_after_init;
>
> may cause out-of-tree LSM modules to fail to use the slot.
>
> It is a strange hack that users have to enable in-tree LSM modules or rewrite the
> definition of LSMID_ENTRIES in order to use out-of-tree (either built-in or loadable)
> LSM modules, for LSMID_ENTRIES is defined based on only in-tree LSM modules.
>
> #define LSMID_ENTRIES ( \
> 1 + /* capabilities */ \
> (IS_ENABLED(CONFIG_SECURITY_SELINUX) ? 1 : 0) + \
> (IS_ENABLED(CONFIG_SECURITY_SMACK) ? 1 : 0) + \
> (IS_ENABLED(CONFIG_SECURITY_TOMOYO) ? 1 : 0) + \
> (IS_ENABLED(CONFIG_SECURITY_IMA) ? 1 : 0) + \
> (IS_ENABLED(CONFIG_SECURITY_APPARMOR) ? 1 : 0) + \
> (IS_ENABLED(CONFIG_SECURITY_YAMA) ? 1 : 0) + \
> (IS_ENABLED(CONFIG_SECURITY_LOADPIN) ? 1 : 0) + \
> (IS_ENABLED(CONFIG_SECURITY_SAFESETID) ? 1 : 0) + \
> (IS_ENABLED(CONFIG_SECURITY_LOCKDOWN) ? 1 : 0) + \
> (IS_ENABLED(CONFIG_BPF_LSM) ? 1 : 0) + \
> (IS_ENABLED(CONFIG_SECURITY_LANDLOCK) ? 1 : 0))
>
> Although built-in out-of-tree LSM modules would be able to rewrite LSMID_ENTRIES definition
> because users will rebuild the whole kernel, loadable out-of-tree LSM modules would not be
> able to rewrite LSMID_ENTRIES definition because users will not rebuild the whole kernel.
> It is still effectively a lock out for loadable out-of-tree LSM modules even if the problem
> of assigning LSM ID integer value is solved.
Propose an implementation of security module loading. If LSMID_ENTRIES is a problem
I will help you resolve the issue. My bet is that there will be an easy solution. It
may be as simple as adding (IS_ENABLED(CONFIG_SECURITY_LOADABLE) ? 1 : 0) + \ to the
code referenced above. But I can't say until I see how you're going to address all
of the real issues.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-10-25 11:20 ` Tetsuo Handa
@ 2022-10-26 20:11 ` Paul Moore
-1 siblings, 0 replies; 148+ messages in thread
From: Paul Moore @ 2022-10-26 20:11 UTC (permalink / raw)
To: Tetsuo Handa
Cc: John Johansen, Casey Schaufler, LSM List, James Morris,
linux-audit, Mimi Zohar, keescook, SElinux list
On Tue, Oct 25, 2022 at 7:20 AM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> On 2022/10/25 19:26, John Johansen wrote:
> > no, Casey is not. He is trying to find a path forward to get LSM
> > stacking upstream sooner than later. He has made proposals that
> > admittedly you have not liked, but he has at least tried to propose
> > ideas that could work within the insane set of constraints.
>
> I'm OK with getting LSM stacking upstream. But changes made based on
> only built-in modules are bad. If LSM id cannot be assigned to loadable
> LSM modules at runtime because not all loadable LSM modules will be
> in-tree in order to get an LSM id assigned, loadable LSM modules won't
> be able to utilize e.g. lsm_module_list system call (or whatever
> changes made while trying to unshare resources/interfaces currently
> shared among SELinux/Smack/AppArmor).
As a reminder, the LSM layer, just like the rest of the kernel, has no
plans to provide any level of consideration or support for out-of-tree
kernel code. LSMs which are not part of the upstream Linux kernel are
not our concern here; if they fail to work with the syscall and/or LSM
stacking changes merged, that should not be considered a blocker to
upstream development.
--
paul-moore.com
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-10-26 20:11 ` Paul Moore
0 siblings, 0 replies; 148+ messages in thread
From: Paul Moore @ 2022-10-26 20:11 UTC (permalink / raw)
To: Tetsuo Handa
Cc: John Johansen, keescook, SElinux list, James Morris, Mimi Zohar,
LSM List, linux-audit
On Tue, Oct 25, 2022 at 7:20 AM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> On 2022/10/25 19:26, John Johansen wrote:
> > no, Casey is not. He is trying to find a path forward to get LSM
> > stacking upstream sooner than later. He has made proposals that
> > admittedly you have not liked, but he has at least tried to propose
> > ideas that could work within the insane set of constraints.
>
> I'm OK with getting LSM stacking upstream. But changes made based on
> only built-in modules are bad. If LSM id cannot be assigned to loadable
> LSM modules at runtime because not all loadable LSM modules will be
> in-tree in order to get an LSM id assigned, loadable LSM modules won't
> be able to utilize e.g. lsm_module_list system call (or whatever
> changes made while trying to unshare resources/interfaces currently
> shared among SELinux/Smack/AppArmor).
As a reminder, the LSM layer, just like the rest of the kernel, has no
plans to provide any level of consideration or support for out-of-tree
kernel code. LSMs which are not part of the upstream Linux kernel are
not our concern here; if they fail to work with the syscall and/or LSM
stacking changes merged, that should not be considered a blocker to
upstream development.
--
paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-10-26 20:11 ` Paul Moore
@ 2022-10-27 0:02 ` Tetsuo Handa
-1 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-10-27 0:02 UTC (permalink / raw)
To: Paul Moore
Cc: John Johansen, Casey Schaufler, LSM List, James Morris,
linux-audit, Mimi Zohar, keescook, SElinux list
On 2022/10/27 5:11, Paul Moore wrote:
> On Tue, Oct 25, 2022 at 7:20 AM Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
>> On 2022/10/25 19:26, John Johansen wrote:
>>> no, Casey is not. He is trying to find a path forward to get LSM
>>> stacking upstream sooner than later. He has made proposals that
>>> admittedly you have not liked, but he has at least tried to propose
>>> ideas that could work within the insane set of constraints.
>>
>> I'm OK with getting LSM stacking upstream. But changes made based on
>> only built-in modules are bad. If LSM id cannot be assigned to loadable
>> LSM modules at runtime because not all loadable LSM modules will be
>> in-tree in order to get an LSM id assigned, loadable LSM modules won't
>> be able to utilize e.g. lsm_module_list system call (or whatever
>> changes made while trying to unshare resources/interfaces currently
>> shared among SELinux/Smack/AppArmor).
>
> As a reminder, the LSM layer, just like the rest of the kernel, has no
> plans to provide any level of consideration or support for out-of-tree
> kernel code. LSMs which are not part of the upstream Linux kernel are
> not our concern here; if they fail to work with the syscall and/or LSM
> stacking changes merged, that should not be considered a blocker to
> upstream development.
>
No. You are misunderstanding. This problem is not limited to out-of-tree and/or
loadable LSM modules. This change prevents new LSM modules from getting upstream
due to a chicken-and-egg problem.
Currently anyone can start writing new LSM modules using name as identifier. But
you are trying to forbid using name as identifier, and trying to force using integer
as identifier, but that integer will not be provided unless new LSM modules get
upstream.
Then, how those who want to write new LSM modules can start writing LSM modules and
propose userspace changes for new LSM modules? They can't use the identifier unless
their LSM module get upstream, which in turn forces them not to propose interface for
userspace programs, which in turn makes it difficult to get new LSM modules tested
by users, which in turn makes it difficult to get upstream due to "who is using your
LSM module" question, which in turn makes it difficult to get the identifier...
You are trying to force CONFIG_MODULES=n by just "we don't care about out-of-tree code".
Trying to change identifier from name to integer is a serious bug.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-10-27 0:02 ` Tetsuo Handa
0 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-10-27 0:02 UTC (permalink / raw)
To: Paul Moore
Cc: John Johansen, keescook, SElinux list, James Morris, Mimi Zohar,
LSM List, linux-audit
On 2022/10/27 5:11, Paul Moore wrote:
> On Tue, Oct 25, 2022 at 7:20 AM Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
>> On 2022/10/25 19:26, John Johansen wrote:
>>> no, Casey is not. He is trying to find a path forward to get LSM
>>> stacking upstream sooner than later. He has made proposals that
>>> admittedly you have not liked, but he has at least tried to propose
>>> ideas that could work within the insane set of constraints.
>>
>> I'm OK with getting LSM stacking upstream. But changes made based on
>> only built-in modules are bad. If LSM id cannot be assigned to loadable
>> LSM modules at runtime because not all loadable LSM modules will be
>> in-tree in order to get an LSM id assigned, loadable LSM modules won't
>> be able to utilize e.g. lsm_module_list system call (or whatever
>> changes made while trying to unshare resources/interfaces currently
>> shared among SELinux/Smack/AppArmor).
>
> As a reminder, the LSM layer, just like the rest of the kernel, has no
> plans to provide any level of consideration or support for out-of-tree
> kernel code. LSMs which are not part of the upstream Linux kernel are
> not our concern here; if they fail to work with the syscall and/or LSM
> stacking changes merged, that should not be considered a blocker to
> upstream development.
>
No. You are misunderstanding. This problem is not limited to out-of-tree and/or
loadable LSM modules. This change prevents new LSM modules from getting upstream
due to a chicken-and-egg problem.
Currently anyone can start writing new LSM modules using name as identifier. But
you are trying to forbid using name as identifier, and trying to force using integer
as identifier, but that integer will not be provided unless new LSM modules get
upstream.
Then, how those who want to write new LSM modules can start writing LSM modules and
propose userspace changes for new LSM modules? They can't use the identifier unless
their LSM module get upstream, which in turn forces them not to propose interface for
userspace programs, which in turn makes it difficult to get new LSM modules tested
by users, which in turn makes it difficult to get upstream due to "who is using your
LSM module" question, which in turn makes it difficult to get the identifier...
You are trying to force CONFIG_MODULES=n by just "we don't care about out-of-tree code".
Trying to change identifier from name to integer is a serious bug.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-10-27 0:02 ` Tetsuo Handa
@ 2022-10-28 9:50 ` Paul Moore
-1 siblings, 0 replies; 148+ messages in thread
From: Paul Moore @ 2022-10-28 9:50 UTC (permalink / raw)
To: Tetsuo Handa
Cc: John Johansen, keescook, SElinux list, James Morris, Mimi Zohar,
LSM List, linux-audit
On Wed, Oct 26, 2022 at 8:02 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> On 2022/10/27 5:11, Paul Moore wrote:
> > On Tue, Oct 25, 2022 at 7:20 AM Tetsuo Handa
> > <penguin-kernel@i-love.sakura.ne.jp> wrote:
> >> On 2022/10/25 19:26, John Johansen wrote:
> >>> no, Casey is not. He is trying to find a path forward to get LSM
> >>> stacking upstream sooner than later. He has made proposals that
> >>> admittedly you have not liked, but he has at least tried to propose
> >>> ideas that could work within the insane set of constraints.
> >>
> >> I'm OK with getting LSM stacking upstream. But changes made based on
> >> only built-in modules are bad. If LSM id cannot be assigned to loadable
> >> LSM modules at runtime because not all loadable LSM modules will be
> >> in-tree in order to get an LSM id assigned, loadable LSM modules won't
> >> be able to utilize e.g. lsm_module_list system call (or whatever
> >> changes made while trying to unshare resources/interfaces currently
> >> shared among SELinux/Smack/AppArmor).
> >
> > As a reminder, the LSM layer, just like the rest of the kernel, has no
> > plans to provide any level of consideration or support for out-of-tree
> > kernel code. LSMs which are not part of the upstream Linux kernel are
> > not our concern here; if they fail to work with the syscall and/or LSM
> > stacking changes merged, that should not be considered a blocker to
> > upstream development.
> >
>
> No. You are misunderstanding.
With all due respect, I understand your point very well, I'm simply
trying to explain to you the position that the Linux Kernel has
historically taken with respect to out-of-tree and in-development
code.
> This problem is not limited to out-of-tree and/or
> loadable LSM modules. This change prevents new LSM modules from getting upstream
> due to a chicken-and-egg problem.
It does *not* prevent new LSM modules from being merged upstream.
It may make it more difficult for out-of-tree modules to remain
out-of-tree, but that is both not a concern of the upstream community
nor is it the concern you are currently describing.
> Currently anyone can start writing new LSM modules using name as identifier. But
> you are trying to forbid using name as identifier, and trying to force using integer
> as identifier, but that integer will not be provided unless new LSM modules get
> upstream.
That is correct. In order to have a LSM identifier token the LSM must
be upstream.
> Then, how those who want to write new LSM modules can start writing LSM modules and
> propose userspace changes for new LSM modules? They can't use the identifier unless
> their LSM module get upstream, which in turn forces them not to propose interface for
> userspace programs, which in turn makes it difficult to get new LSM modules tested
> by users, which in turn makes it difficult to get upstream due to "who is using your
> LSM module" question, which in turn makes it difficult to get the identifier...
First, new LSMs generally do not need extensive userspace
modifications; of course there may be some, but when one considers the
entirety of a modern Linux distribution the actual percentage should
be quite small. In addition, it is not uncommon for in-development
LSMs to have a set of privately, i.e. not upstreamed, patched
userspace tools while the new LSM works to get upstream. These
private userspace patches are generally merged after the LSM has been
merged into the kernel.
> You are trying to force CONFIG_MODULES=n by just "we don't care about out-of-tree code".
That is not the goal at all and I would appreciate it if you could
stop slandering the motivations of the LSM syscall effort.
> Trying to change identifier from name to integer is a serious bug.
I disagree. One would have a similar problem - userspace
awareness/enablement - regardless of if a name or a token is used.
Ultimately the challenge is getting userspace developers to accept a
change that is not part of the upstream Linux Kernel and thus not
guaranteed under the usual "don't break userspace" kernel API promise.
--
paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-10-28 9:50 ` Paul Moore
0 siblings, 0 replies; 148+ messages in thread
From: Paul Moore @ 2022-10-28 9:50 UTC (permalink / raw)
To: Tetsuo Handa
Cc: John Johansen, Casey Schaufler, LSM List, James Morris,
linux-audit, Mimi Zohar, keescook, SElinux list
On Wed, Oct 26, 2022 at 8:02 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> On 2022/10/27 5:11, Paul Moore wrote:
> > On Tue, Oct 25, 2022 at 7:20 AM Tetsuo Handa
> > <penguin-kernel@i-love.sakura.ne.jp> wrote:
> >> On 2022/10/25 19:26, John Johansen wrote:
> >>> no, Casey is not. He is trying to find a path forward to get LSM
> >>> stacking upstream sooner than later. He has made proposals that
> >>> admittedly you have not liked, but he has at least tried to propose
> >>> ideas that could work within the insane set of constraints.
> >>
> >> I'm OK with getting LSM stacking upstream. But changes made based on
> >> only built-in modules are bad. If LSM id cannot be assigned to loadable
> >> LSM modules at runtime because not all loadable LSM modules will be
> >> in-tree in order to get an LSM id assigned, loadable LSM modules won't
> >> be able to utilize e.g. lsm_module_list system call (or whatever
> >> changes made while trying to unshare resources/interfaces currently
> >> shared among SELinux/Smack/AppArmor).
> >
> > As a reminder, the LSM layer, just like the rest of the kernel, has no
> > plans to provide any level of consideration or support for out-of-tree
> > kernel code. LSMs which are not part of the upstream Linux kernel are
> > not our concern here; if they fail to work with the syscall and/or LSM
> > stacking changes merged, that should not be considered a blocker to
> > upstream development.
> >
>
> No. You are misunderstanding.
With all due respect, I understand your point very well, I'm simply
trying to explain to you the position that the Linux Kernel has
historically taken with respect to out-of-tree and in-development
code.
> This problem is not limited to out-of-tree and/or
> loadable LSM modules. This change prevents new LSM modules from getting upstream
> due to a chicken-and-egg problem.
It does *not* prevent new LSM modules from being merged upstream.
It may make it more difficult for out-of-tree modules to remain
out-of-tree, but that is both not a concern of the upstream community
nor is it the concern you are currently describing.
> Currently anyone can start writing new LSM modules using name as identifier. But
> you are trying to forbid using name as identifier, and trying to force using integer
> as identifier, but that integer will not be provided unless new LSM modules get
> upstream.
That is correct. In order to have a LSM identifier token the LSM must
be upstream.
> Then, how those who want to write new LSM modules can start writing LSM modules and
> propose userspace changes for new LSM modules? They can't use the identifier unless
> their LSM module get upstream, which in turn forces them not to propose interface for
> userspace programs, which in turn makes it difficult to get new LSM modules tested
> by users, which in turn makes it difficult to get upstream due to "who is using your
> LSM module" question, which in turn makes it difficult to get the identifier...
First, new LSMs generally do not need extensive userspace
modifications; of course there may be some, but when one considers the
entirety of a modern Linux distribution the actual percentage should
be quite small. In addition, it is not uncommon for in-development
LSMs to have a set of privately, i.e. not upstreamed, patched
userspace tools while the new LSM works to get upstream. These
private userspace patches are generally merged after the LSM has been
merged into the kernel.
> You are trying to force CONFIG_MODULES=n by just "we don't care about out-of-tree code".
That is not the goal at all and I would appreciate it if you could
stop slandering the motivations of the LSM syscall effort.
> Trying to change identifier from name to integer is a serious bug.
I disagree. One would have a similar problem - userspace
awareness/enablement - regardless of if a name or a token is used.
Ultimately the challenge is getting userspace developers to accept a
change that is not part of the upstream Linux Kernel and thus not
guaranteed under the usual "don't break userspace" kernel API promise.
--
paul-moore.com
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-10-28 9:50 ` Paul Moore
@ 2022-10-28 13:58 ` Tetsuo Handa
-1 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-10-28 13:58 UTC (permalink / raw)
To: Paul Moore
Cc: John Johansen, Casey Schaufler, LSM List, James Morris,
linux-audit, Mimi Zohar, keescook, SElinux list
On 2022/10/28 18:50, Paul Moore wrote:
>> This problem is not limited to out-of-tree and/or
>> loadable LSM modules. This change prevents new LSM modules from getting upstream
>> due to a chicken-and-egg problem.
>
> It does *not* prevent new LSM modules from being merged upstream.
>
> It may make it more difficult for out-of-tree modules to remain
> out-of-tree, but that is both not a concern of the upstream community
> nor is it the concern you are currently describing.
New LSM modules are out-of-tree modules until being merged upstream.
LSM modules is an area which is difficult to get merged upstream for
unknown reasons. You remember the label versus pathname war, don't you?
Do you remember that 10 modules were proposed
SimpleFlow ( 2016/04/21 https://lwn.net/Articles/684825/ )
HardChroot ( 2016/07/29 https://lwn.net/Articles/695984/ )
Checmate ( 2016/08/04 https://lwn.net/Articles/696344/ )
LandLock ( 2016/08/25 https://lwn.net/Articles/698226/ )
PTAGS ( 2016/09/29 https://lwn.net/Articles/702639/ )
CaitSith ( 2016/10/21 https://lwn.net/Articles/704262/ )
SafeName ( 2016/05/03 https://lwn.net/Articles/686021/ )
WhiteEgret ( 2017/05/30 https://lwn.net/Articles/724192/ )
shebang ( 2017/06/09 https://lwn.net/Articles/725285/ )
S.A.R.A. ( 2017/06/13 https://lwn.net/Articles/725230/ )
and how many of them got merged upstream? It is inevitable that some
(or rather, many or most) of LSM modules cannot be merged upstream or
be enabled by distributors.
Even if perfect LSM stacking is implemented, I can imagine a future that
none of LSM modules available in upstream kernel can satisfy user's needs.
LSM stacking makes sense only if LSM modules which can satisfy user's needs
are available. And we know that upstream kernel won't accept whatever LSMs.
I consider /sbin/insmod-able LSM modules as a compromise/remedy for LSM modules
which could not get merged upstream or supported by distributors, for patching and
rebuilding the whole kernel in order to use not-yet-upstreamed and/or not-builtin
LSMs is already a lot of barrier for users. But requiring a permanent integer in
order to use a LSM module is a denial of even patching and rebuilding the whole
kernel. That's why I hate this change.
>
>> Currently anyone can start writing new LSM modules using name as identifier. But
>> you are trying to forbid using name as identifier, and trying to force using integer
>> as identifier, but that integer will not be provided unless new LSM modules get
>> upstream.
>
> That is correct. In order to have a LSM identifier token the LSM must
> be upstream.
Then, new LSM modules which are intended to be merged upstream can't write
userspace interface.
>
>> Then, how those who want to write new LSM modules can start writing LSM modules and
>> propose userspace changes for new LSM modules? They can't use the identifier unless
>> their LSM module get upstream, which in turn forces them not to propose interface for
>> userspace programs, which in turn makes it difficult to get new LSM modules tested
>> by users, which in turn makes it difficult to get upstream due to "who is using your
>> LSM module" question, which in turn makes it difficult to get the identifier...
>
> First, new LSMs generally do not need extensive userspace
> modifications; of course there may be some, but when one considers the
> entirety of a modern Linux distribution the actual percentage should
> be quite small.
I agree that new LSMs generally do not need extensive userspace modifications.
But
> In addition, it is not uncommon for in-development
> LSMs to have a set of privately, i.e. not upstreamed, patched
> userspace tools while the new LSM works to get upstream. These
> private userspace patches are generally merged after the LSM has been
> merged into the kernel.
I still think an identifier is needed when developing management programs for each
new LSM.
Do you mean that management programs which are specific to each LSM module are not
forced to use the identifier Casey is trying to introduce? If yes, why does "you are
trying to forbid using name as identifier, and trying to force using integer as
identifier" need to be correct? Only programs that do not belong to specific LSM
module but needs to be able to recognize various LSM modules' per task attributes
need to use the identifier Casey is trying to introduce.
I can't understand why assigning a permanent integer identifier is mandatory.
TOMOYO (and trivial LSMs) will not need such identifier. This change merely makes
it more difficult to stack minor/trivial LSMs implemented as /sbin/insmod-able LSMs,
by introducing fixed sized array.
>
>> You are trying to force CONFIG_MODULES=n by just "we don't care about out-of-tree code".
>
> That is not the goal at all and I would appreciate it if you could
> stop slandering the motivations of the LSM syscall effort.
>
>> Trying to change identifier from name to integer is a serious bug.
>
> I disagree. One would have a similar problem - userspace
> awareness/enablement - regardless of if a name or a token is used.
TOMOYO (and trivial LSMs) will not need userspace awareness/enablement.
> Ultimately the challenge is getting userspace developers to accept a
> change that is not part of the upstream Linux Kernel and thus not
> guaranteed under the usual "don't break userspace" kernel API promise.
I'm not against the challenge. But none of "introducing fixed sized array",
"assigning permanent integer for the fixed sized array", "not assigning permanent
integer unless merged upstream" is required for achieving the challenge. We can
achieve the challenge via "using linked list" and "using name or assigning dynamic
integer upon loading of a LSM module". (Of course, if upstream kernel allows assigning
permanent integer before getting merged, we can use integer for the userspace...)
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
@ 2022-10-28 13:58 ` Tetsuo Handa
0 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-10-28 13:58 UTC (permalink / raw)
To: Paul Moore
Cc: John Johansen, keescook, SElinux list, James Morris, Mimi Zohar,
LSM List, linux-audit
On 2022/10/28 18:50, Paul Moore wrote:
>> This problem is not limited to out-of-tree and/or
>> loadable LSM modules. This change prevents new LSM modules from getting upstream
>> due to a chicken-and-egg problem.
>
> It does *not* prevent new LSM modules from being merged upstream.
>
> It may make it more difficult for out-of-tree modules to remain
> out-of-tree, but that is both not a concern of the upstream community
> nor is it the concern you are currently describing.
New LSM modules are out-of-tree modules until being merged upstream.
LSM modules is an area which is difficult to get merged upstream for
unknown reasons. You remember the label versus pathname war, don't you?
Do you remember that 10 modules were proposed
SimpleFlow ( 2016/04/21 https://lwn.net/Articles/684825/ )
HardChroot ( 2016/07/29 https://lwn.net/Articles/695984/ )
Checmate ( 2016/08/04 https://lwn.net/Articles/696344/ )
LandLock ( 2016/08/25 https://lwn.net/Articles/698226/ )
PTAGS ( 2016/09/29 https://lwn.net/Articles/702639/ )
CaitSith ( 2016/10/21 https://lwn.net/Articles/704262/ )
SafeName ( 2016/05/03 https://lwn.net/Articles/686021/ )
WhiteEgret ( 2017/05/30 https://lwn.net/Articles/724192/ )
shebang ( 2017/06/09 https://lwn.net/Articles/725285/ )
S.A.R.A. ( 2017/06/13 https://lwn.net/Articles/725230/ )
and how many of them got merged upstream? It is inevitable that some
(or rather, many or most) of LSM modules cannot be merged upstream or
be enabled by distributors.
Even if perfect LSM stacking is implemented, I can imagine a future that
none of LSM modules available in upstream kernel can satisfy user's needs.
LSM stacking makes sense only if LSM modules which can satisfy user's needs
are available. And we know that upstream kernel won't accept whatever LSMs.
I consider /sbin/insmod-able LSM modules as a compromise/remedy for LSM modules
which could not get merged upstream or supported by distributors, for patching and
rebuilding the whole kernel in order to use not-yet-upstreamed and/or not-builtin
LSMs is already a lot of barrier for users. But requiring a permanent integer in
order to use a LSM module is a denial of even patching and rebuilding the whole
kernel. That's why I hate this change.
>
>> Currently anyone can start writing new LSM modules using name as identifier. But
>> you are trying to forbid using name as identifier, and trying to force using integer
>> as identifier, but that integer will not be provided unless new LSM modules get
>> upstream.
>
> That is correct. In order to have a LSM identifier token the LSM must
> be upstream.
Then, new LSM modules which are intended to be merged upstream can't write
userspace interface.
>
>> Then, how those who want to write new LSM modules can start writing LSM modules and
>> propose userspace changes for new LSM modules? They can't use the identifier unless
>> their LSM module get upstream, which in turn forces them not to propose interface for
>> userspace programs, which in turn makes it difficult to get new LSM modules tested
>> by users, which in turn makes it difficult to get upstream due to "who is using your
>> LSM module" question, which in turn makes it difficult to get the identifier...
>
> First, new LSMs generally do not need extensive userspace
> modifications; of course there may be some, but when one considers the
> entirety of a modern Linux distribution the actual percentage should
> be quite small.
I agree that new LSMs generally do not need extensive userspace modifications.
But
> In addition, it is not uncommon for in-development
> LSMs to have a set of privately, i.e. not upstreamed, patched
> userspace tools while the new LSM works to get upstream. These
> private userspace patches are generally merged after the LSM has been
> merged into the kernel.
I still think an identifier is needed when developing management programs for each
new LSM.
Do you mean that management programs which are specific to each LSM module are not
forced to use the identifier Casey is trying to introduce? If yes, why does "you are
trying to forbid using name as identifier, and trying to force using integer as
identifier" need to be correct? Only programs that do not belong to specific LSM
module but needs to be able to recognize various LSM modules' per task attributes
need to use the identifier Casey is trying to introduce.
I can't understand why assigning a permanent integer identifier is mandatory.
TOMOYO (and trivial LSMs) will not need such identifier. This change merely makes
it more difficult to stack minor/trivial LSMs implemented as /sbin/insmod-able LSMs,
by introducing fixed sized array.
>
>> You are trying to force CONFIG_MODULES=n by just "we don't care about out-of-tree code".
>
> That is not the goal at all and I would appreciate it if you could
> stop slandering the motivations of the LSM syscall effort.
>
>> Trying to change identifier from name to integer is a serious bug.
>
> I disagree. One would have a similar problem - userspace
> awareness/enablement - regardless of if a name or a token is used.
TOMOYO (and trivial LSMs) will not need userspace awareness/enablement.
> Ultimately the challenge is getting userspace developers to accept a
> change that is not part of the upstream Linux Kernel and thus not
> guaranteed under the usual "don't break userspace" kernel API promise.
I'm not against the challenge. But none of "introducing fixed sized array",
"assigning permanent integer for the fixed sized array", "not assigning permanent
integer unless merged upstream" is required for achieving the challenge. We can
achieve the challenge via "using linked list" and "using name or assigning dynamic
integer upon loading of a LSM module". (Of course, if upstream kernel allows assigning
permanent integer before getting merged, we can use integer for the userspace...)
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
2022-10-28 13:58 ` Tetsuo Handa
@ 2022-10-28 17:40 ` Kees Cook
-1 siblings, 0 replies; 148+ messages in thread
From: Kees Cook @ 2022-10-28 17:40 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Paul Moore, John Johansen, Casey Schaufler, LSM List,
James Morris, linux-audit, Mimi Zohar, SElinux list
On Fri, Oct 28, 2022 at 10:58:30PM +0900, Tetsuo Handa wrote:
> Do you remember that 10 modules were proposed
>
> SimpleFlow ( 2016/04/21 https://lwn.net/Articles/684825/ )
> HardChroot ( 2016/07/29 https://lwn.net/Articles/695984/ )
> Checmate ( 2016/08/04 https://lwn.net/Articles/696344/ )
> LandLock ( 2016/08/25 https://lwn.net/Articles/698226/ )
> PTAGS ( 2016/09/29 https://lwn.net/Articles/702639/ )
> CaitSith ( 2016/10/21 https://lwn.net/Articles/704262/ )
> SafeName ( 2016/05/03 https://lwn.net/Articles/686021/ )
> WhiteEgret ( 2017/05/30 https://lwn.net/Articles/724192/ )
> shebang ( 2017/06/09 https://lwn.net/Articles/725285/ )
> S.A.R.A. ( 2017/06/13 https://lwn.net/Articles/725230/ )
There was also:
LoadPin ( 2016/04/20 https://lore.kernel.org/lkml/1461192388-13900-1-git-send-email-keescook@chromium.org/ )
SafeSetID ( 2018/10/31 https://lore.kernel.org/linux-security-module/20181031152846.234791-1-mortonm@chromium.org/ )
BPF ( 2019/09/10 https://lore.kernel.org/linux-security-module/20190910115527.5235-1-kpsingh@chromium.org/ )
So, 13 LSM proposed, 4 landed: roughly 30%, which is on par[1] with regular
kernel development.
> I consider /sbin/insmod-able LSM modules as a compromise/remedy for LSM modules
> which could not get merged upstream or supported by distributors, for patching and
> rebuilding the whole kernel in order to use not-yet-upstreamed and/or not-builtin
> LSMs is already a lot of barrier for users. But requiring a permanent integer in
> order to use a LSM module is a denial of even patching and rebuilding the whole
> kernel. That's why I hate this change.
But the upstream kernel _does not support APIs for out-of-tree code_. To
that point, security_add_hooks() is _not exported_, so it is already not
possible to create a modular LSM without patching the kernel source.
> I can't understand why assigning a permanent integer identifier is mandatory.
Plenty of other APIs use numeric identifiers: syscalls, prctl, etc. This
doesn't block them from being upstreamed.
-Kees
[1] https://ieeexplore.ieee.org/abstract/document/6624016
--
Kees Cook
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
@ 2022-10-28 17:40 ` Kees Cook
0 siblings, 0 replies; 148+ messages in thread
From: Kees Cook @ 2022-10-28 17:40 UTC (permalink / raw)
To: Tetsuo Handa
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On Fri, Oct 28, 2022 at 10:58:30PM +0900, Tetsuo Handa wrote:
> Do you remember that 10 modules were proposed
>
> SimpleFlow ( 2016/04/21 https://lwn.net/Articles/684825/ )
> HardChroot ( 2016/07/29 https://lwn.net/Articles/695984/ )
> Checmate ( 2016/08/04 https://lwn.net/Articles/696344/ )
> LandLock ( 2016/08/25 https://lwn.net/Articles/698226/ )
> PTAGS ( 2016/09/29 https://lwn.net/Articles/702639/ )
> CaitSith ( 2016/10/21 https://lwn.net/Articles/704262/ )
> SafeName ( 2016/05/03 https://lwn.net/Articles/686021/ )
> WhiteEgret ( 2017/05/30 https://lwn.net/Articles/724192/ )
> shebang ( 2017/06/09 https://lwn.net/Articles/725285/ )
> S.A.R.A. ( 2017/06/13 https://lwn.net/Articles/725230/ )
There was also:
LoadPin ( 2016/04/20 https://lore.kernel.org/lkml/1461192388-13900-1-git-send-email-keescook@chromium.org/ )
SafeSetID ( 2018/10/31 https://lore.kernel.org/linux-security-module/20181031152846.234791-1-mortonm@chromium.org/ )
BPF ( 2019/09/10 https://lore.kernel.org/linux-security-module/20190910115527.5235-1-kpsingh@chromium.org/ )
So, 13 LSM proposed, 4 landed: roughly 30%, which is on par[1] with regular
kernel development.
> I consider /sbin/insmod-able LSM modules as a compromise/remedy for LSM modules
> which could not get merged upstream or supported by distributors, for patching and
> rebuilding the whole kernel in order to use not-yet-upstreamed and/or not-builtin
> LSMs is already a lot of barrier for users. But requiring a permanent integer in
> order to use a LSM module is a denial of even patching and rebuilding the whole
> kernel. That's why I hate this change.
But the upstream kernel _does not support APIs for out-of-tree code_. To
that point, security_add_hooks() is _not exported_, so it is already not
possible to create a modular LSM without patching the kernel source.
> I can't understand why assigning a permanent integer identifier is mandatory.
Plenty of other APIs use numeric identifiers: syscalls, prctl, etc. This
doesn't block them from being upstreamed.
-Kees
[1] https://ieeexplore.ieee.org/abstract/document/6624016
--
Kees Cook
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread* Re: LSM stacking in next for 6.1?
2022-10-28 17:40 ` Kees Cook
@ 2022-10-29 9:33 ` Tetsuo Handa
-1 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-10-29 9:33 UTC (permalink / raw)
To: Kees Cook
Cc: Paul Moore, John Johansen, Casey Schaufler, LSM List,
James Morris, linux-audit, Mimi Zohar, SElinux list
On 2022/10/29 2:40, Kees Cook wrote:
> On Fri, Oct 28, 2022 at 10:58:30PM +0900, Tetsuo Handa wrote:
>> I consider /sbin/insmod-able LSM modules as a compromise/remedy for LSM modules
>> which could not get merged upstream or supported by distributors, for patching and
>> rebuilding the whole kernel in order to use not-yet-upstreamed and/or not-builtin
>> LSMs is already a lot of barrier for users. But requiring a permanent integer in
>> order to use a LSM module is a denial of even patching and rebuilding the whole
>> kernel. That's why I hate this change.
>
> But the upstream kernel _does not support APIs for out-of-tree code_. To
> that point, security_add_hooks() is _not exported_, so it is already not
> possible to create a modular LSM without patching the kernel source.
AKARI/CaitSith and several other LSM modules are running without patching
the kernel source. But this patchset makes it impossible to use 9 out of 13
LSM modules as (not upstreamed but) built-in LSM modules by patching the kernel,
due to lack of identifier. That's a needless requirement that harms development
of LSM modules.
Linux kernel has started using a new and more inclusive terminology for the
Linux kernel code and documentation. But this patchset is making the code
more and more exclusive. That's a way to exclude LSM modules that satisfies
user's need, even if perfect LSM stacking implementation is provided.
What do you think if an authority commands you that companies like Intel, Google,
RedHat, Canonical etc. must wind up because these companies are not member of
that authority? That's behavior of autocracy.
This patchset _does not allow out-of-tree code to exist_ rather than simply
_does not support APIs for out-of-tree code_. The behavior of this patchset is
to exclude 9 out of 13 LSM modules, unless upstream kernel allows these modules
to exist (by assigning an LSM id value). What a closed community LSM is!
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-10-29 9:33 ` Tetsuo Handa
0 siblings, 0 replies; 148+ messages in thread
From: Tetsuo Handa @ 2022-10-29 9:33 UTC (permalink / raw)
To: Kees Cook
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On 2022/10/29 2:40, Kees Cook wrote:
> On Fri, Oct 28, 2022 at 10:58:30PM +0900, Tetsuo Handa wrote:
>> I consider /sbin/insmod-able LSM modules as a compromise/remedy for LSM modules
>> which could not get merged upstream or supported by distributors, for patching and
>> rebuilding the whole kernel in order to use not-yet-upstreamed and/or not-builtin
>> LSMs is already a lot of barrier for users. But requiring a permanent integer in
>> order to use a LSM module is a denial of even patching and rebuilding the whole
>> kernel. That's why I hate this change.
>
> But the upstream kernel _does not support APIs for out-of-tree code_. To
> that point, security_add_hooks() is _not exported_, so it is already not
> possible to create a modular LSM without patching the kernel source.
AKARI/CaitSith and several other LSM modules are running without patching
the kernel source. But this patchset makes it impossible to use 9 out of 13
LSM modules as (not upstreamed but) built-in LSM modules by patching the kernel,
due to lack of identifier. That's a needless requirement that harms development
of LSM modules.
Linux kernel has started using a new and more inclusive terminology for the
Linux kernel code and documentation. But this patchset is making the code
more and more exclusive. That's a way to exclude LSM modules that satisfies
user's need, even if perfect LSM stacking implementation is provided.
What do you think if an authority commands you that companies like Intel, Google,
RedHat, Canonical etc. must wind up because these companies are not member of
that authority? That's behavior of autocracy.
This patchset _does not allow out-of-tree code to exist_ rather than simply
_does not support APIs for out-of-tree code_. The behavior of this patchset is
to exclude 9 out of 13 LSM modules, unless upstream kernel allows these modules
to exist (by assigning an LSM id value). What a closed community LSM is!
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-08 22:56 ` Casey Schaufler
@ 2022-09-14 13:42 ` Paul Moore
-1 siblings, 0 replies; 148+ messages in thread
From: Paul Moore @ 2022-09-14 13:42 UTC (permalink / raw)
To: Casey Schaufler
Cc: John Johansen, LSM List, James Morris, linux-audit, Mimi Zohar,
keescook, SElinux list
On Thu, Sep 8, 2022 at 6:56 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> I am going to start playing with these syscalls. Please help me understand
> where I have suggested something stoopid.
Thanks for posting an initial patch that we can use for further
discussion. Time is a bit tight this week due to LPC/LSS-EU so I'm
not sure I'll have the time to provide any meaningful comments, but if
nothing else it's on my todo list for next week.
--
paul-moore.com
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-09-14 13:42 ` Paul Moore
0 siblings, 0 replies; 148+ messages in thread
From: Paul Moore @ 2022-09-14 13:42 UTC (permalink / raw)
To: Casey Schaufler
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On Thu, Sep 8, 2022 at 6:56 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> I am going to start playing with these syscalls. Please help me understand
> where I have suggested something stoopid.
Thanks for posting an initial patch that we can use for further
discussion. Time is a bit tight this week due to LPC/LSS-EU so I'm
not sure I'll have the time to provide any meaningful comments, but if
nothing else it's on my todo list for next week.
--
paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-14 13:42 ` Paul Moore
@ 2022-09-27 20:54 ` Casey Schaufler
-1 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-27 20:54 UTC (permalink / raw)
To: Paul Moore
Cc: John Johansen, LSM List, James Morris, linux-audit, Mimi Zohar,
keescook, SElinux list, casey
On 9/14/2022 6:42 AM, Paul Moore wrote:
> On Thu, Sep 8, 2022 at 6:56 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> I am going to start playing with these syscalls. Please help me understand
>> where I have suggested something stoopid.
> Thanks for posting an initial patch that we can use for further
> discussion. Time is a bit tight this week due to LPC/LSS-EU so I'm
> not sure I'll have the time to provide any meaningful comments, but if
> nothing else it's on my todo list for next week.
With a full understanding that the 6.1 boat has not only sailed but has
subsequently been sunk by pirates I've posted my v38 stacking patches.
I would have liked to wait for some amount of "discussion" on the proposed
syscalls and prctl() options before posting, but it seems that isn't
going to happen on its own. In spite of the radical change to the user
interface I am pushing for -next for 6.2. If there has to be discussion
about the interface we should have it. I'm going to be (mostly) off line
the first half of October, and was seriously hoping to have any issues
identified before then. If that can't happen I need some idea what can
make it happen on some sort of timeline.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-09-27 20:54 ` Casey Schaufler
0 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-27 20:54 UTC (permalink / raw)
To: Paul Moore
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On 9/14/2022 6:42 AM, Paul Moore wrote:
> On Thu, Sep 8, 2022 at 6:56 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> I am going to start playing with these syscalls. Please help me understand
>> where I have suggested something stoopid.
> Thanks for posting an initial patch that we can use for further
> discussion. Time is a bit tight this week due to LPC/LSS-EU so I'm
> not sure I'll have the time to provide any meaningful comments, but if
> nothing else it's on my todo list for next week.
With a full understanding that the 6.1 boat has not only sailed but has
subsequently been sunk by pirates I've posted my v38 stacking patches.
I would have liked to wait for some amount of "discussion" on the proposed
syscalls and prctl() options before posting, but it seems that isn't
going to happen on its own. In spite of the radical change to the user
interface I am pushing for -next for 6.2. If there has to be discussion
about the interface we should have it. I'm going to be (mostly) off line
the first half of October, and was seriously hoping to have any issues
identified before then. If that can't happen I need some idea what can
make it happen on some sort of timeline.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-27 20:54 ` Casey Schaufler
@ 2022-09-27 22:37 ` Paul Moore
-1 siblings, 0 replies; 148+ messages in thread
From: Paul Moore @ 2022-09-27 22:37 UTC (permalink / raw)
To: Casey Schaufler
Cc: John Johansen, LSM List, James Morris, linux-audit, Mimi Zohar,
keescook, SElinux list
On Tue, Sep 27, 2022 at 4:54 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> On 9/14/2022 6:42 AM, Paul Moore wrote:
> > On Thu, Sep 8, 2022 at 6:56 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >> I am going to start playing with these syscalls. Please help me understand
> >> where I have suggested something stoopid.
> > Thanks for posting an initial patch that we can use for further
> > discussion. Time is a bit tight this week due to LPC/LSS-EU so I'm
> > not sure I'll have the time to provide any meaningful comments, but if
> > nothing else it's on my todo list for next week.
>
> With a full understanding that the 6.1 boat has not only sailed but has
> subsequently been sunk by pirates I've posted my v38 stacking patches.
> I would have liked to wait for some amount of "discussion" on the proposed
> syscalls and prctl() options before posting, but it seems that isn't
> going to happen on its own ...
I was happy to see the patches posted, and they are in my queue, but
being away the week of LPC/LSS-EU as well as some other more near-term
patchsets that need review have delayed my ability to review your
syscall patches.
--
paul-moore.com
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-09-27 22:37 ` Paul Moore
0 siblings, 0 replies; 148+ messages in thread
From: Paul Moore @ 2022-09-27 22:37 UTC (permalink / raw)
To: Casey Schaufler
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On Tue, Sep 27, 2022 at 4:54 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> On 9/14/2022 6:42 AM, Paul Moore wrote:
> > On Thu, Sep 8, 2022 at 6:56 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >> I am going to start playing with these syscalls. Please help me understand
> >> where I have suggested something stoopid.
> > Thanks for posting an initial patch that we can use for further
> > discussion. Time is a bit tight this week due to LPC/LSS-EU so I'm
> > not sure I'll have the time to provide any meaningful comments, but if
> > nothing else it's on my todo list for next week.
>
> With a full understanding that the 6.1 boat has not only sailed but has
> subsequently been sunk by pirates I've posted my v38 stacking patches.
> I would have liked to wait for some amount of "discussion" on the proposed
> syscalls and prctl() options before posting, but it seems that isn't
> going to happen on its own ...
I was happy to see the patches posted, and they are in my queue, but
being away the week of LPC/LSS-EU as well as some other more near-term
patchsets that need review have delayed my ability to review your
syscall patches.
--
paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-06 23:24 ` Paul Moore
@ 2022-09-07 0:31 ` Casey Schaufler
-1 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-07 0:31 UTC (permalink / raw)
To: Paul Moore
Cc: LSM List, James Morris, linux-audit, John Johansen, Mimi Zohar,
keescook, SElinux list, casey
On 9/6/2022 4:24 PM, Paul Moore wrote:
> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>> I would like very much to get v38 or v39 of the LSM stacking for Apparmor
>>>>> patch set in the LSM next branch for 6.1. The audit changes have polished
>>>>> up nicely and I believe that all comments on the integrity code have been
>>>>> addressed. The interface_lsm mechanism has been beaten to a frothy peak.
>>>>> There are serious binder changes, but I think they address issues beyond
>>>>> the needs of stacking. Changes outside these areas are pretty well limited
>>>>> to LSM interface improvements.
>>>> The LSM stacking patches are near the very top of my list to review
>>>> once the merge window clears, the io_uring fixes are in (bug fix), and
>>>> SCTP is somewhat sane again (bug fix). I'm hopeful that the io_uring
>>>> and SCTP stuff can be finished up in the next week or two.
>>>>
>>>> Since I'm the designated first stuckee now for the stacking stuff I
>>>> want to go back through everything with fresh eyes, which probably
>>>> isn't a bad idea since it has been a while since I looked at the full
>>>> patchset from bottom to top. I can tell you that I've never been
>>>> really excited about the /proc changes, and believe it or not I've
>>>> been thinking about those a fair amount since James asked me to start
>>>> maintaining the LSM. I don't want to get into any detail until I've
>>>> had a chance to look over everything again, but just a heads-up that
>>>> I'm not too excited about those bits.
>>> As I mentioned above, I don't really like the stuff that one has to do
>>> to support LSM stacking on the existing /proc interfaces, the
>>> "label1\0label2\labelN\0" hack is probably the best (only?) option we
>>> have for retrofitting multiple LSMs into those interfaces and I think
>>> we can all agree it's not a great API. Considering that applications
>>> that wish to become simultaneous multi-LSM aware are going to need
>>> modification anyway, let's take a step back and see if we can do this
>>> with a more sensible API.
>> This is a compound problem. Some applications, including systemd and dbus,
>> will require modification to completely support multiple concurrent LSMs
>> in the long term. This will certainly be the case should someone be wild
>> and crazy enough to use Smack and SELinux together. Even with the (Smack or
>> SELinux) and AppArmor case the ps(1) command should be educated about the
>> possibility of multiple "current" values. However, in a container world,
>> where an Android container can run on an Ubuntu system, the presence of
>> AppArmor on the base system is completely uninteresting to the SELinux
>> aware applications in the container. This is a real use case.
> If you are running AppArmor on the host system and SELinux in a
> container you are likely going to have some *very* bizarre behavior as
> the SELinux policy you load in the container will apply to the entire
> system, including processes which started *before* the SELinux policy
> was loaded. While I understand the point you are trying to make, I
> don't believe the example you chose is going to work without a lot of
> other changes.
I don't use it myself, but I know it's frighteningly popular.
> Regardless of the above example, I want to be clear that I'm not
> suggesting changes to the /proc interfaces. Existing LSM aware
> applications that use procfs for information would continue to work as
> expected, it would just be the simul-multi-LSM aware applications that
> would need to transition to the new syscall API to get all of the LSM
> labels.
They're going to have to do something, true enough.
>>> I think it's time to think about a proper set of LSM syscalls.
>> At the very least we need a liblsm that preforms a number of useful
>> functions, like identifying what security modules are available,
>> validating "contexts", fetching "contexts" from files and processes
>> and that sort of thing. Whether it is built on syscalls or /proc and
>> getxattr() is a matter of debate and taste.
> Why is it a forgone conclusion that a library would be necessary for
> basic operations? If the kernel/userspace API is sane to begin with
> we could probably either significantly reduce or eliminate the need
> for additional libraries.
I'm using my experience with the "hideous" context format
( "apparmor\0unconfined\0smack\0User\0" ) as a guide. Creating
a "sane" API for returning multiple lsm/context pairs is going
to be tricky. No one wants to require iterative calls to get a
collection of values for example. I've spent the past few years
trying to pound out APIs that are somewhat sane. I don't want to
spend another few years repeating the process for kernel APIs.
> I really want us to attempt to come up with
> a decent kernel/userspace API to begin with
That's fine, except that the process here is nowhere near the
beginning. v1 was in June of 2019, and I had posted several unnumbered
versions before then. No one has ever - not once - proposed syscall
interfaces until now. I would be delighted to investigate and include
syscall interfaces for the Complete stacking (SELinux + Smack) work,
as I can see considerably greater need for them there.
> as opposed to using the
> excuse of a userspace library to hide API sins that never should have
> been committed.
I confess to having committed many hideous API sins.
> The LSM stacking work presents us with a unique opportunity to
> modify/update/whatever the LSM kernel/userspace API, I don't want to
> see us squander this chance on a hack.
I'm listening ...
>
>>> While I realize syscalls are not the only kernel/userspace API option,
>>> but given the popularity of namespaces I believe a syscall based
>>> kernel/userspace LSM API has a number of advantages over the other
>>> options, e.g. procfs/sysfs, netlink, etc.
>> You can't script syscalls.
> True. However I don't see that as a blocker, trivial helper
> applications can be written for those who wish to incorporate the new
> syscall-based API into their scripts. We would not be the first (or
> the last) in this regard.
Trivial wrappers to set attributes aren't any cleaner than /proc interfaces.
And in any case, if you've hidden the syscall in a wrapper you can hide the
/proc interfaces in a wrapper as well.
>> A syscall interface is fine if you can also
>> update the entire system service application base for your distribution.
>> I don't see that as an option.
> Once again, I'm not talking about removing the existing procfs
> interface; existing applications would continue to work. Only
> applications which wanted to be simul-multi-LSM aware would need to be
> modified, and those applications would need to be modified regardless
> of if the procfs or syscall-based API was used.
O..K.. then syscalls could be a completely separate project.
The current work need not be dependent on whatever syscall work is done.
>>> Further, I think we can add the new syscall API separately from the
>>> LSM stacking changes as they do have standalone value.
>> I agree, but unless the new system calls take stacking into account
>> from their inception they're just going to be another interface that
>> makes stacking harder to accomplish.
> They obviously would Casey, not only is that the context of the
> discussion but my dummy example clearly had support for multiple LSMs.
>
>>> This would
>>> help reduce the size and complexity of the stacking patchset, which I
>>> believe would be a very good thing.
>> The /proc interfaces interface_lsm and context are really pretty simple.
> They are now, they are also a bit of a mess with legacy constraints
> and they only get more complicated and messy with the LSM stacking
> patches. It is my opinion that a syscall-based API is cleaner and
> easier for applications to use.
Yes. A syscall is easier for an application to use. A /proc interface
is much easier for a scripted system. The scripts are much more frequently
updated than the C coded services. Some of the services are so rarely and
cautiously updated that expecting them to be modernized is unreasonable.
How many system services use capabilities the way they were designed to
be used?
>
>> The addition of multiple subject labels to audit would be the same regardless
>> of /proc or syscall interfaces.
> Yes, that's why I didn't bring up audit as it doesn't weigh on this
> decision. If you really want to include audit for some reason, I'll
> simply remind you that I pushed back hard on overloading the existing
> subj/obj fields with a multiplexed label format, asking for individual
> subj/obj fields for each LSM.
Just pointing out that the stacking patches aren't that complicated.
>
>> We'd still need multiple LSM data in most
>> security blobs. The conversion of LSM hook interfaces from secids to lsmblobs
>> would still be required. As would the conversion from string+len pairs to
>> lsmcontext structures.
> I'm not talking about kernel internal data structures Casey, I'm
> talking about the kernel/userspace API.
Again, just saying the the patches, while extensive, don't do very much
that's complicated.
>
>>> Introducing the syscall API
>>> sooner would also allow any applications wanting to make use of the
>>> crazy new stacked-LSM world a head start as they could be modified
>>> while the kernel patches were making their way through the
>>> review/update/merge/release process.
>> A liblsm based on the /proc interfaces would address that as well.
> Perhaps a liblsm library would be useful for other reasons beyond this
> discussion, but I don't want to use a userspace library as an excuse
> to support an awful kernel/userspace API.
What API are you saying is awful, and how would you improve it?
The sample APIs you proposed wouldn't work as syscalls.
>
>>> Thoughts?
>> I wish you'd suggested this three years ago, when I could have done
>> something with it. If stacking has to go on a two year redesign because
>> of this it is dead.
> I've never liked the combined label interfaces, see the mention of
> audit in this email above. I'm sure if you wanted to dig through all
> of the mail archives I'm sure I've probably mentioned my dislike of
> the combined label interface in procfs too; if not on the mailing list
> then surely in-person at some point. However, regardless of all that,
> the key difference is that prior to a few months ago I didn't have to
> worry about it quite as much as I do now. Now I'm responsible for
> standing up for the code that goes into the LSM tree and that means
> both defending it as "good" and maintaining it long term; prior to a
> few months ago that was, politely, "not my problem" :)
Message received.
>
> I can't currently in good conscience defend the kernel/userspace
> combined label interfaces as "good", especially when we have a very
> rare opportunity to do better.
OK, so what interfaces need to be redone? I have been polishing what's
just become a turd for a %^&*(ing long time. I need to know whether it
is something I can address, or whether I just toss the entire thing in
the proverbial bit bucket.
Grumble grumble grumble.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-09-07 0:31 ` Casey Schaufler
0 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-07 0:31 UTC (permalink / raw)
To: Paul Moore
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On 9/6/2022 4:24 PM, Paul Moore wrote:
> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>> I would like very much to get v38 or v39 of the LSM stacking for Apparmor
>>>>> patch set in the LSM next branch for 6.1. The audit changes have polished
>>>>> up nicely and I believe that all comments on the integrity code have been
>>>>> addressed. The interface_lsm mechanism has been beaten to a frothy peak.
>>>>> There are serious binder changes, but I think they address issues beyond
>>>>> the needs of stacking. Changes outside these areas are pretty well limited
>>>>> to LSM interface improvements.
>>>> The LSM stacking patches are near the very top of my list to review
>>>> once the merge window clears, the io_uring fixes are in (bug fix), and
>>>> SCTP is somewhat sane again (bug fix). I'm hopeful that the io_uring
>>>> and SCTP stuff can be finished up in the next week or two.
>>>>
>>>> Since I'm the designated first stuckee now for the stacking stuff I
>>>> want to go back through everything with fresh eyes, which probably
>>>> isn't a bad idea since it has been a while since I looked at the full
>>>> patchset from bottom to top. I can tell you that I've never been
>>>> really excited about the /proc changes, and believe it or not I've
>>>> been thinking about those a fair amount since James asked me to start
>>>> maintaining the LSM. I don't want to get into any detail until I've
>>>> had a chance to look over everything again, but just a heads-up that
>>>> I'm not too excited about those bits.
>>> As I mentioned above, I don't really like the stuff that one has to do
>>> to support LSM stacking on the existing /proc interfaces, the
>>> "label1\0label2\labelN\0" hack is probably the best (only?) option we
>>> have for retrofitting multiple LSMs into those interfaces and I think
>>> we can all agree it's not a great API. Considering that applications
>>> that wish to become simultaneous multi-LSM aware are going to need
>>> modification anyway, let's take a step back and see if we can do this
>>> with a more sensible API.
>> This is a compound problem. Some applications, including systemd and dbus,
>> will require modification to completely support multiple concurrent LSMs
>> in the long term. This will certainly be the case should someone be wild
>> and crazy enough to use Smack and SELinux together. Even with the (Smack or
>> SELinux) and AppArmor case the ps(1) command should be educated about the
>> possibility of multiple "current" values. However, in a container world,
>> where an Android container can run on an Ubuntu system, the presence of
>> AppArmor on the base system is completely uninteresting to the SELinux
>> aware applications in the container. This is a real use case.
> If you are running AppArmor on the host system and SELinux in a
> container you are likely going to have some *very* bizarre behavior as
> the SELinux policy you load in the container will apply to the entire
> system, including processes which started *before* the SELinux policy
> was loaded. While I understand the point you are trying to make, I
> don't believe the example you chose is going to work without a lot of
> other changes.
I don't use it myself, but I know it's frighteningly popular.
> Regardless of the above example, I want to be clear that I'm not
> suggesting changes to the /proc interfaces. Existing LSM aware
> applications that use procfs for information would continue to work as
> expected, it would just be the simul-multi-LSM aware applications that
> would need to transition to the new syscall API to get all of the LSM
> labels.
They're going to have to do something, true enough.
>>> I think it's time to think about a proper set of LSM syscalls.
>> At the very least we need a liblsm that preforms a number of useful
>> functions, like identifying what security modules are available,
>> validating "contexts", fetching "contexts" from files and processes
>> and that sort of thing. Whether it is built on syscalls or /proc and
>> getxattr() is a matter of debate and taste.
> Why is it a forgone conclusion that a library would be necessary for
> basic operations? If the kernel/userspace API is sane to begin with
> we could probably either significantly reduce or eliminate the need
> for additional libraries.
I'm using my experience with the "hideous" context format
( "apparmor\0unconfined\0smack\0User\0" ) as a guide. Creating
a "sane" API for returning multiple lsm/context pairs is going
to be tricky. No one wants to require iterative calls to get a
collection of values for example. I've spent the past few years
trying to pound out APIs that are somewhat sane. I don't want to
spend another few years repeating the process for kernel APIs.
> I really want us to attempt to come up with
> a decent kernel/userspace API to begin with
That's fine, except that the process here is nowhere near the
beginning. v1 was in June of 2019, and I had posted several unnumbered
versions before then. No one has ever - not once - proposed syscall
interfaces until now. I would be delighted to investigate and include
syscall interfaces for the Complete stacking (SELinux + Smack) work,
as I can see considerably greater need for them there.
> as opposed to using the
> excuse of a userspace library to hide API sins that never should have
> been committed.
I confess to having committed many hideous API sins.
> The LSM stacking work presents us with a unique opportunity to
> modify/update/whatever the LSM kernel/userspace API, I don't want to
> see us squander this chance on a hack.
I'm listening ...
>
>>> While I realize syscalls are not the only kernel/userspace API option,
>>> but given the popularity of namespaces I believe a syscall based
>>> kernel/userspace LSM API has a number of advantages over the other
>>> options, e.g. procfs/sysfs, netlink, etc.
>> You can't script syscalls.
> True. However I don't see that as a blocker, trivial helper
> applications can be written for those who wish to incorporate the new
> syscall-based API into their scripts. We would not be the first (or
> the last) in this regard.
Trivial wrappers to set attributes aren't any cleaner than /proc interfaces.
And in any case, if you've hidden the syscall in a wrapper you can hide the
/proc interfaces in a wrapper as well.
>> A syscall interface is fine if you can also
>> update the entire system service application base for your distribution.
>> I don't see that as an option.
> Once again, I'm not talking about removing the existing procfs
> interface; existing applications would continue to work. Only
> applications which wanted to be simul-multi-LSM aware would need to be
> modified, and those applications would need to be modified regardless
> of if the procfs or syscall-based API was used.
O..K.. then syscalls could be a completely separate project.
The current work need not be dependent on whatever syscall work is done.
>>> Further, I think we can add the new syscall API separately from the
>>> LSM stacking changes as they do have standalone value.
>> I agree, but unless the new system calls take stacking into account
>> from their inception they're just going to be another interface that
>> makes stacking harder to accomplish.
> They obviously would Casey, not only is that the context of the
> discussion but my dummy example clearly had support for multiple LSMs.
>
>>> This would
>>> help reduce the size and complexity of the stacking patchset, which I
>>> believe would be a very good thing.
>> The /proc interfaces interface_lsm and context are really pretty simple.
> They are now, they are also a bit of a mess with legacy constraints
> and they only get more complicated and messy with the LSM stacking
> patches. It is my opinion that a syscall-based API is cleaner and
> easier for applications to use.
Yes. A syscall is easier for an application to use. A /proc interface
is much easier for a scripted system. The scripts are much more frequently
updated than the C coded services. Some of the services are so rarely and
cautiously updated that expecting them to be modernized is unreasonable.
How many system services use capabilities the way they were designed to
be used?
>
>> The addition of multiple subject labels to audit would be the same regardless
>> of /proc or syscall interfaces.
> Yes, that's why I didn't bring up audit as it doesn't weigh on this
> decision. If you really want to include audit for some reason, I'll
> simply remind you that I pushed back hard on overloading the existing
> subj/obj fields with a multiplexed label format, asking for individual
> subj/obj fields for each LSM.
Just pointing out that the stacking patches aren't that complicated.
>
>> We'd still need multiple LSM data in most
>> security blobs. The conversion of LSM hook interfaces from secids to lsmblobs
>> would still be required. As would the conversion from string+len pairs to
>> lsmcontext structures.
> I'm not talking about kernel internal data structures Casey, I'm
> talking about the kernel/userspace API.
Again, just saying the the patches, while extensive, don't do very much
that's complicated.
>
>>> Introducing the syscall API
>>> sooner would also allow any applications wanting to make use of the
>>> crazy new stacked-LSM world a head start as they could be modified
>>> while the kernel patches were making their way through the
>>> review/update/merge/release process.
>> A liblsm based on the /proc interfaces would address that as well.
> Perhaps a liblsm library would be useful for other reasons beyond this
> discussion, but I don't want to use a userspace library as an excuse
> to support an awful kernel/userspace API.
What API are you saying is awful, and how would you improve it?
The sample APIs you proposed wouldn't work as syscalls.
>
>>> Thoughts?
>> I wish you'd suggested this three years ago, when I could have done
>> something with it. If stacking has to go on a two year redesign because
>> of this it is dead.
> I've never liked the combined label interfaces, see the mention of
> audit in this email above. I'm sure if you wanted to dig through all
> of the mail archives I'm sure I've probably mentioned my dislike of
> the combined label interface in procfs too; if not on the mailing list
> then surely in-person at some point. However, regardless of all that,
> the key difference is that prior to a few months ago I didn't have to
> worry about it quite as much as I do now. Now I'm responsible for
> standing up for the code that goes into the LSM tree and that means
> both defending it as "good" and maintaining it long term; prior to a
> few months ago that was, politely, "not my problem" :)
Message received.
>
> I can't currently in good conscience defend the kernel/userspace
> combined label interfaces as "good", especially when we have a very
> rare opportunity to do better.
OK, so what interfaces need to be redone? I have been polishing what's
just become a turd for a %^&*(ing long time. I need to know whether it
is something I can address, or whether I just toss the entire thing in
the proverbial bit bucket.
Grumble grumble grumble.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-07 0:31 ` Casey Schaufler
@ 2022-09-07 15:13 ` Paul Moore
-1 siblings, 0 replies; 148+ messages in thread
From: Paul Moore @ 2022-09-07 15:13 UTC (permalink / raw)
To: Casey Schaufler
Cc: LSM List, James Morris, linux-audit, John Johansen, Mimi Zohar,
keescook, SElinux list
On Tue, Sep 6, 2022 at 8:31 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 9/6/2022 4:24 PM, Paul Moore wrote:
> > On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >> On 9/2/2022 2:30 PM, Paul Moore wrote:
> >>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
> >>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >>>>> I would like very much to get v38 or v39 of the LSM stacking for Apparmor
> >>>>> patch set in the LSM next branch for 6.1. The audit changes have polished
> >>>>> up nicely and I believe that all comments on the integrity code have been
> >>>>> addressed. The interface_lsm mechanism has been beaten to a frothy peak.
> >>>>> There are serious binder changes, but I think they address issues beyond
> >>>>> the needs of stacking. Changes outside these areas are pretty well limited
> >>>>> to LSM interface improvements.
> >>>> The LSM stacking patches are near the very top of my list to review
> >>>> once the merge window clears, the io_uring fixes are in (bug fix), and
> >>>> SCTP is somewhat sane again (bug fix). I'm hopeful that the io_uring
> >>>> and SCTP stuff can be finished up in the next week or two.
> >>>>
> >>>> Since I'm the designated first stuckee now for the stacking stuff I
> >>>> want to go back through everything with fresh eyes, which probably
> >>>> isn't a bad idea since it has been a while since I looked at the full
> >>>> patchset from bottom to top. I can tell you that I've never been
> >>>> really excited about the /proc changes, and believe it or not I've
> >>>> been thinking about those a fair amount since James asked me to start
> >>>> maintaining the LSM. I don't want to get into any detail until I've
> >>>> had a chance to look over everything again, but just a heads-up that
> >>>> I'm not too excited about those bits.
> >>> As I mentioned above, I don't really like the stuff that one has to do
> >>> to support LSM stacking on the existing /proc interfaces, the
> >>> "label1\0label2\labelN\0" hack is probably the best (only?) option we
> >>> have for retrofitting multiple LSMs into those interfaces and I think
> >>> we can all agree it's not a great API. Considering that applications
> >>> that wish to become simultaneous multi-LSM aware are going to need
> >>> modification anyway, let's take a step back and see if we can do this
> >>> with a more sensible API.
> >> This is a compound problem. Some applications, including systemd and dbus,
> >> will require modification to completely support multiple concurrent LSMs
> >> in the long term. This will certainly be the case should someone be wild
> >> and crazy enough to use Smack and SELinux together. Even with the (Smack or
> >> SELinux) and AppArmor case the ps(1) command should be educated about the
> >> possibility of multiple "current" values. However, in a container world,
> >> where an Android container can run on an Ubuntu system, the presence of
> >> AppArmor on the base system is completely uninteresting to the SELinux
> >> aware applications in the container. This is a real use case.
> > If you are running AppArmor on the host system and SELinux in a
> > container you are likely going to have some *very* bizarre behavior as
> > the SELinux policy you load in the container will apply to the entire
> > system, including processes which started *before* the SELinux policy
> > was loaded. While I understand the point you are trying to make, I
> > don't believe the example you chose is going to work without a lot of
> > other changes.
>
> I don't use it myself, but I know it's frighteningly popular.
All right, I'm going to call your bluff here - who are these people
running AppArmor on the host and SELinux in a container? What policy
are they using, it's surely not an unmodified Fedora/RHEL or upstream
refpol policy? Do they run in enforcing mode without massive
permissions granted to kernel_t (I'm guessing all of the host
applications would appear as kernel_t)? How do you handle multiple
SELinux containers?
I'm aware of *one* use case where SELinux is run in a container and
that required a number of careful constraints on the use case and a
good deal of hacking to enable. I'm sure there are definitely people
that *want* this, especially in the context of Ubuntu, but I really
doubt this is in widespread use today.
> >>> I think it's time to think about a proper set of LSM syscalls.
> >> At the very least we need a liblsm that preforms a number of useful
> >> functions, like identifying what security modules are available,
> >> validating "contexts", fetching "contexts" from files and processes
> >> and that sort of thing. Whether it is built on syscalls or /proc and
> >> getxattr() is a matter of debate and taste.
> > Why is it a forgone conclusion that a library would be necessary for
> > basic operations? If the kernel/userspace API is sane to begin with
> > we could probably either significantly reduce or eliminate the need
> > for additional libraries.
>
> I'm using my experience with the "hideous" context format
> ( "apparmor\0unconfined\0smack\0User\0" ) as a guide. Creating
> a "sane" API for returning multiple lsm/context pairs is going
> to be tricky. No one wants to require iterative calls to get a
> collection of values for example. I've spent the past few years
> trying to pound out APIs that are somewhat sane. I don't want to
> spend another few years repeating the process for kernel APIs.
See my earlier comment to John. I care a lot about getting things
right, and very little about how long it takes. I'm sympathetic about
the time and difficulty involved, but I see that as no reason to merge
a not-good design.
> >> The addition of multiple subject labels to audit would be the same regardless
> >> of /proc or syscall interfaces.
> >
> > Yes, that's why I didn't bring up audit as it doesn't weigh on this
> > decision. If you really want to include audit for some reason, I'll
> > simply remind you that I pushed back hard on overloading the existing
> > subj/obj fields with a multiplexed label format, asking for individual
> > subj/obj fields for each LSM.
>
> Just pointing out that the stacking patches aren't that complicated.
Ha! Let's just agree to disagree on that point :)
--
paul-moore.com
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-09-07 15:13 ` Paul Moore
0 siblings, 0 replies; 148+ messages in thread
From: Paul Moore @ 2022-09-07 15:13 UTC (permalink / raw)
To: Casey Schaufler
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On Tue, Sep 6, 2022 at 8:31 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 9/6/2022 4:24 PM, Paul Moore wrote:
> > On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >> On 9/2/2022 2:30 PM, Paul Moore wrote:
> >>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
> >>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >>>>> I would like very much to get v38 or v39 of the LSM stacking for Apparmor
> >>>>> patch set in the LSM next branch for 6.1. The audit changes have polished
> >>>>> up nicely and I believe that all comments on the integrity code have been
> >>>>> addressed. The interface_lsm mechanism has been beaten to a frothy peak.
> >>>>> There are serious binder changes, but I think they address issues beyond
> >>>>> the needs of stacking. Changes outside these areas are pretty well limited
> >>>>> to LSM interface improvements.
> >>>> The LSM stacking patches are near the very top of my list to review
> >>>> once the merge window clears, the io_uring fixes are in (bug fix), and
> >>>> SCTP is somewhat sane again (bug fix). I'm hopeful that the io_uring
> >>>> and SCTP stuff can be finished up in the next week or two.
> >>>>
> >>>> Since I'm the designated first stuckee now for the stacking stuff I
> >>>> want to go back through everything with fresh eyes, which probably
> >>>> isn't a bad idea since it has been a while since I looked at the full
> >>>> patchset from bottom to top. I can tell you that I've never been
> >>>> really excited about the /proc changes, and believe it or not I've
> >>>> been thinking about those a fair amount since James asked me to start
> >>>> maintaining the LSM. I don't want to get into any detail until I've
> >>>> had a chance to look over everything again, but just a heads-up that
> >>>> I'm not too excited about those bits.
> >>> As I mentioned above, I don't really like the stuff that one has to do
> >>> to support LSM stacking on the existing /proc interfaces, the
> >>> "label1\0label2\labelN\0" hack is probably the best (only?) option we
> >>> have for retrofitting multiple LSMs into those interfaces and I think
> >>> we can all agree it's not a great API. Considering that applications
> >>> that wish to become simultaneous multi-LSM aware are going to need
> >>> modification anyway, let's take a step back and see if we can do this
> >>> with a more sensible API.
> >> This is a compound problem. Some applications, including systemd and dbus,
> >> will require modification to completely support multiple concurrent LSMs
> >> in the long term. This will certainly be the case should someone be wild
> >> and crazy enough to use Smack and SELinux together. Even with the (Smack or
> >> SELinux) and AppArmor case the ps(1) command should be educated about the
> >> possibility of multiple "current" values. However, in a container world,
> >> where an Android container can run on an Ubuntu system, the presence of
> >> AppArmor on the base system is completely uninteresting to the SELinux
> >> aware applications in the container. This is a real use case.
> > If you are running AppArmor on the host system and SELinux in a
> > container you are likely going to have some *very* bizarre behavior as
> > the SELinux policy you load in the container will apply to the entire
> > system, including processes which started *before* the SELinux policy
> > was loaded. While I understand the point you are trying to make, I
> > don't believe the example you chose is going to work without a lot of
> > other changes.
>
> I don't use it myself, but I know it's frighteningly popular.
All right, I'm going to call your bluff here - who are these people
running AppArmor on the host and SELinux in a container? What policy
are they using, it's surely not an unmodified Fedora/RHEL or upstream
refpol policy? Do they run in enforcing mode without massive
permissions granted to kernel_t (I'm guessing all of the host
applications would appear as kernel_t)? How do you handle multiple
SELinux containers?
I'm aware of *one* use case where SELinux is run in a container and
that required a number of careful constraints on the use case and a
good deal of hacking to enable. I'm sure there are definitely people
that *want* this, especially in the context of Ubuntu, but I really
doubt this is in widespread use today.
> >>> I think it's time to think about a proper set of LSM syscalls.
> >> At the very least we need a liblsm that preforms a number of useful
> >> functions, like identifying what security modules are available,
> >> validating "contexts", fetching "contexts" from files and processes
> >> and that sort of thing. Whether it is built on syscalls or /proc and
> >> getxattr() is a matter of debate and taste.
> > Why is it a forgone conclusion that a library would be necessary for
> > basic operations? If the kernel/userspace API is sane to begin with
> > we could probably either significantly reduce or eliminate the need
> > for additional libraries.
>
> I'm using my experience with the "hideous" context format
> ( "apparmor\0unconfined\0smack\0User\0" ) as a guide. Creating
> a "sane" API for returning multiple lsm/context pairs is going
> to be tricky. No one wants to require iterative calls to get a
> collection of values for example. I've spent the past few years
> trying to pound out APIs that are somewhat sane. I don't want to
> spend another few years repeating the process for kernel APIs.
See my earlier comment to John. I care a lot about getting things
right, and very little about how long it takes. I'm sympathetic about
the time and difficulty involved, but I see that as no reason to merge
a not-good design.
> >> The addition of multiple subject labels to audit would be the same regardless
> >> of /proc or syscall interfaces.
> >
> > Yes, that's why I didn't bring up audit as it doesn't weigh on this
> > decision. If you really want to include audit for some reason, I'll
> > simply remind you that I pushed back hard on overloading the existing
> > subj/obj fields with a multiplexed label format, asking for individual
> > subj/obj fields for each LSM.
>
> Just pointing out that the stacking patches aren't that complicated.
Ha! Let's just agree to disagree on that point :)
--
paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-07 15:13 ` Paul Moore
@ 2022-09-07 17:08 ` Casey Schaufler
-1 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-07 17:08 UTC (permalink / raw)
To: Paul Moore
Cc: LSM List, James Morris, linux-audit, John Johansen, Mimi Zohar,
keescook, SElinux list, casey
On 9/7/2022 8:13 AM, Paul Moore wrote:
> On Tue, Sep 6, 2022 at 8:31 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/6/2022 4:24 PM, Paul Moore wrote:
>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>>>> I would like very much to get v38 or v39 of the LSM stacking for Apparmor
>>>>>>> patch set in the LSM next branch for 6.1. The audit changes have polished
>>>>>>> up nicely and I believe that all comments on the integrity code have been
>>>>>>> addressed. The interface_lsm mechanism has been beaten to a frothy peak.
>>>>>>> There are serious binder changes, but I think they address issues beyond
>>>>>>> the needs of stacking. Changes outside these areas are pretty well limited
>>>>>>> to LSM interface improvements.
>>>>>> The LSM stacking patches are near the very top of my list to review
>>>>>> once the merge window clears, the io_uring fixes are in (bug fix), and
>>>>>> SCTP is somewhat sane again (bug fix). I'm hopeful that the io_uring
>>>>>> and SCTP stuff can be finished up in the next week or two.
>>>>>>
>>>>>> Since I'm the designated first stuckee now for the stacking stuff I
>>>>>> want to go back through everything with fresh eyes, which probably
>>>>>> isn't a bad idea since it has been a while since I looked at the full
>>>>>> patchset from bottom to top. I can tell you that I've never been
>>>>>> really excited about the /proc changes, and believe it or not I've
>>>>>> been thinking about those a fair amount since James asked me to start
>>>>>> maintaining the LSM. I don't want to get into any detail until I've
>>>>>> had a chance to look over everything again, but just a heads-up that
>>>>>> I'm not too excited about those bits.
>>>>> As I mentioned above, I don't really like the stuff that one has to do
>>>>> to support LSM stacking on the existing /proc interfaces, the
>>>>> "label1\0label2\labelN\0" hack is probably the best (only?) option we
>>>>> have for retrofitting multiple LSMs into those interfaces and I think
>>>>> we can all agree it's not a great API. Considering that applications
>>>>> that wish to become simultaneous multi-LSM aware are going to need
>>>>> modification anyway, let's take a step back and see if we can do this
>>>>> with a more sensible API.
>>>> This is a compound problem. Some applications, including systemd and dbus,
>>>> will require modification to completely support multiple concurrent LSMs
>>>> in the long term. This will certainly be the case should someone be wild
>>>> and crazy enough to use Smack and SELinux together. Even with the (Smack or
>>>> SELinux) and AppArmor case the ps(1) command should be educated about the
>>>> possibility of multiple "current" values. However, in a container world,
>>>> where an Android container can run on an Ubuntu system, the presence of
>>>> AppArmor on the base system is completely uninteresting to the SELinux
>>>> aware applications in the container. This is a real use case.
>>> If you are running AppArmor on the host system and SELinux in a
>>> container you are likely going to have some *very* bizarre behavior as
>>> the SELinux policy you load in the container will apply to the entire
>>> system, including processes which started *before* the SELinux policy
>>> was loaded. While I understand the point you are trying to make, I
>>> don't believe the example you chose is going to work without a lot of
>>> other changes.
>> I don't use it myself, but I know it's frighteningly popular.
> All right, I'm going to call your bluff here - who are these people
> running AppArmor on the host and SELinux in a container? What policy
> are they using, it's surely not an unmodified Fedora/RHEL or upstream
> refpol policy? Do they run in enforcing mode without massive
> permissions granted to kernel_t (I'm guessing all of the host
> applications would appear as kernel_t)? How do you handle multiple
> SELinux containers?
Beats me. All that SELinux policy stuff is over my head. ;)
Seriously, once they got the stacking patches applied they thanked
me for the help and disappeared until they decided to update the
kernel version and asked for help with the next round of patches.
They told me what they wanted to do, which was to run Android in
a container, but how they accomplished it was a set of details they
didn't share. I assume that you are right that they had to do
horrible things to either AppArmor or SELinux policy, or maybe both.
I also assume they wanted this as an environment to develop Android
applications, and may not have cared much about actual enforcement.
But they are happy users.
> I'm aware of *one* use case where SELinux is run in a container and
> that required a number of careful constraints on the use case and a
> good deal of hacking to enable. I'm sure there are definitely people
> that *want* this, especially in the context of Ubuntu, but I really
> doubt this is in widespread use today.
What I know is that there is a community out there using it. I think
you're right that the way they're using it would be displeasing to
most of us.
>>>>> I think it's time to think about a proper set of LSM syscalls.
>>>> At the very least we need a liblsm that preforms a number of useful
>>>> functions, like identifying what security modules are available,
>>>> validating "contexts", fetching "contexts" from files and processes
>>>> and that sort of thing. Whether it is built on syscalls or /proc and
>>>> getxattr() is a matter of debate and taste.
>>> Why is it a forgone conclusion that a library would be necessary for
>>> basic operations? If the kernel/userspace API is sane to begin with
>>> we could probably either significantly reduce or eliminate the need
>>> for additional libraries.
>> I'm using my experience with the "hideous" context format
>> ( "apparmor\0unconfined\0smack\0User\0" ) as a guide. Creating
>> a "sane" API for returning multiple lsm/context pairs is going
>> to be tricky. No one wants to require iterative calls to get a
>> collection of values for example. I've spent the past few years
>> trying to pound out APIs that are somewhat sane. I don't want to
>> spend another few years repeating the process for kernel APIs.
> See my earlier comment to John. I care a lot about getting things
> right, and very little about how long it takes. I'm sympathetic about
> the time and difficulty involved, but I see that as no reason to merge
> a not-good design.
>
>>>> The addition of multiple subject labels to audit would be the same regardless
>>>> of /proc or syscall interfaces.
>>> Yes, that's why I didn't bring up audit as it doesn't weigh on this
>>> decision. If you really want to include audit for some reason, I'll
>>> simply remind you that I pushed back hard on overloading the existing
>>> subj/obj fields with a multiplexed label format, asking for individual
>>> subj/obj fields for each LSM.
>> Just pointing out that the stacking patches aren't that complicated.
> Ha! Let's just agree to disagree on that point :)
OK, they're a teeny bit extensive.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-09-07 17:08 ` Casey Schaufler
0 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-07 17:08 UTC (permalink / raw)
To: Paul Moore
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On 9/7/2022 8:13 AM, Paul Moore wrote:
> On Tue, Sep 6, 2022 at 8:31 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/6/2022 4:24 PM, Paul Moore wrote:
>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>>>> I would like very much to get v38 or v39 of the LSM stacking for Apparmor
>>>>>>> patch set in the LSM next branch for 6.1. The audit changes have polished
>>>>>>> up nicely and I believe that all comments on the integrity code have been
>>>>>>> addressed. The interface_lsm mechanism has been beaten to a frothy peak.
>>>>>>> There are serious binder changes, but I think they address issues beyond
>>>>>>> the needs of stacking. Changes outside these areas are pretty well limited
>>>>>>> to LSM interface improvements.
>>>>>> The LSM stacking patches are near the very top of my list to review
>>>>>> once the merge window clears, the io_uring fixes are in (bug fix), and
>>>>>> SCTP is somewhat sane again (bug fix). I'm hopeful that the io_uring
>>>>>> and SCTP stuff can be finished up in the next week or two.
>>>>>>
>>>>>> Since I'm the designated first stuckee now for the stacking stuff I
>>>>>> want to go back through everything with fresh eyes, which probably
>>>>>> isn't a bad idea since it has been a while since I looked at the full
>>>>>> patchset from bottom to top. I can tell you that I've never been
>>>>>> really excited about the /proc changes, and believe it or not I've
>>>>>> been thinking about those a fair amount since James asked me to start
>>>>>> maintaining the LSM. I don't want to get into any detail until I've
>>>>>> had a chance to look over everything again, but just a heads-up that
>>>>>> I'm not too excited about those bits.
>>>>> As I mentioned above, I don't really like the stuff that one has to do
>>>>> to support LSM stacking on the existing /proc interfaces, the
>>>>> "label1\0label2\labelN\0" hack is probably the best (only?) option we
>>>>> have for retrofitting multiple LSMs into those interfaces and I think
>>>>> we can all agree it's not a great API. Considering that applications
>>>>> that wish to become simultaneous multi-LSM aware are going to need
>>>>> modification anyway, let's take a step back and see if we can do this
>>>>> with a more sensible API.
>>>> This is a compound problem. Some applications, including systemd and dbus,
>>>> will require modification to completely support multiple concurrent LSMs
>>>> in the long term. This will certainly be the case should someone be wild
>>>> and crazy enough to use Smack and SELinux together. Even with the (Smack or
>>>> SELinux) and AppArmor case the ps(1) command should be educated about the
>>>> possibility of multiple "current" values. However, in a container world,
>>>> where an Android container can run on an Ubuntu system, the presence of
>>>> AppArmor on the base system is completely uninteresting to the SELinux
>>>> aware applications in the container. This is a real use case.
>>> If you are running AppArmor on the host system and SELinux in a
>>> container you are likely going to have some *very* bizarre behavior as
>>> the SELinux policy you load in the container will apply to the entire
>>> system, including processes which started *before* the SELinux policy
>>> was loaded. While I understand the point you are trying to make, I
>>> don't believe the example you chose is going to work without a lot of
>>> other changes.
>> I don't use it myself, but I know it's frighteningly popular.
> All right, I'm going to call your bluff here - who are these people
> running AppArmor on the host and SELinux in a container? What policy
> are they using, it's surely not an unmodified Fedora/RHEL or upstream
> refpol policy? Do they run in enforcing mode without massive
> permissions granted to kernel_t (I'm guessing all of the host
> applications would appear as kernel_t)? How do you handle multiple
> SELinux containers?
Beats me. All that SELinux policy stuff is over my head. ;)
Seriously, once they got the stacking patches applied they thanked
me for the help and disappeared until they decided to update the
kernel version and asked for help with the next round of patches.
They told me what they wanted to do, which was to run Android in
a container, but how they accomplished it was a set of details they
didn't share. I assume that you are right that they had to do
horrible things to either AppArmor or SELinux policy, or maybe both.
I also assume they wanted this as an environment to develop Android
applications, and may not have cared much about actual enforcement.
But they are happy users.
> I'm aware of *one* use case where SELinux is run in a container and
> that required a number of careful constraints on the use case and a
> good deal of hacking to enable. I'm sure there are definitely people
> that *want* this, especially in the context of Ubuntu, but I really
> doubt this is in widespread use today.
What I know is that there is a community out there using it. I think
you're right that the way they're using it would be displeasing to
most of us.
>>>>> I think it's time to think about a proper set of LSM syscalls.
>>>> At the very least we need a liblsm that preforms a number of useful
>>>> functions, like identifying what security modules are available,
>>>> validating "contexts", fetching "contexts" from files and processes
>>>> and that sort of thing. Whether it is built on syscalls or /proc and
>>>> getxattr() is a matter of debate and taste.
>>> Why is it a forgone conclusion that a library would be necessary for
>>> basic operations? If the kernel/userspace API is sane to begin with
>>> we could probably either significantly reduce or eliminate the need
>>> for additional libraries.
>> I'm using my experience with the "hideous" context format
>> ( "apparmor\0unconfined\0smack\0User\0" ) as a guide. Creating
>> a "sane" API for returning multiple lsm/context pairs is going
>> to be tricky. No one wants to require iterative calls to get a
>> collection of values for example. I've spent the past few years
>> trying to pound out APIs that are somewhat sane. I don't want to
>> spend another few years repeating the process for kernel APIs.
> See my earlier comment to John. I care a lot about getting things
> right, and very little about how long it takes. I'm sympathetic about
> the time and difficulty involved, but I see that as no reason to merge
> a not-good design.
>
>>>> The addition of multiple subject labels to audit would be the same regardless
>>>> of /proc or syscall interfaces.
>>> Yes, that's why I didn't bring up audit as it doesn't weigh on this
>>> decision. If you really want to include audit for some reason, I'll
>>> simply remind you that I pushed back hard on overloading the existing
>>> subj/obj fields with a multiplexed label format, asking for individual
>>> subj/obj fields for each LSM.
>> Just pointing out that the stacking patches aren't that complicated.
> Ha! Let's just agree to disagree on that point :)
OK, they're a teeny bit extensive.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-07 17:08 ` Casey Schaufler
@ 2022-09-07 23:04 ` Paul Moore
-1 siblings, 0 replies; 148+ messages in thread
From: Paul Moore @ 2022-09-07 23:04 UTC (permalink / raw)
To: Casey Schaufler
Cc: LSM List, James Morris, linux-audit, John Johansen, Mimi Zohar,
keescook, SElinux list
On Wed, Sep 7, 2022 at 1:08 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 9/7/2022 8:13 AM, Paul Moore wrote:
> > On Tue, Sep 6, 2022 at 8:31 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >> On 9/6/2022 4:24 PM, Paul Moore wrote:
> >>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
> >>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
> >>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >>>>>>> I would like very much to get v38 or v39 of the LSM stacking for Apparmor
> >>>>>>> patch set in the LSM next branch for 6.1. The audit changes have polished
> >>>>>>> up nicely and I believe that all comments on the integrity code have been
> >>>>>>> addressed. The interface_lsm mechanism has been beaten to a frothy peak.
> >>>>>>> There are serious binder changes, but I think they address issues beyond
> >>>>>>> the needs of stacking. Changes outside these areas are pretty well limited
> >>>>>>> to LSM interface improvements.
> >>>>>> The LSM stacking patches are near the very top of my list to review
> >>>>>> once the merge window clears, the io_uring fixes are in (bug fix), and
> >>>>>> SCTP is somewhat sane again (bug fix). I'm hopeful that the io_uring
> >>>>>> and SCTP stuff can be finished up in the next week or two.
> >>>>>>
> >>>>>> Since I'm the designated first stuckee now for the stacking stuff I
> >>>>>> want to go back through everything with fresh eyes, which probably
> >>>>>> isn't a bad idea since it has been a while since I looked at the full
> >>>>>> patchset from bottom to top. I can tell you that I've never been
> >>>>>> really excited about the /proc changes, and believe it or not I've
> >>>>>> been thinking about those a fair amount since James asked me to start
> >>>>>> maintaining the LSM. I don't want to get into any detail until I've
> >>>>>> had a chance to look over everything again, but just a heads-up that
> >>>>>> I'm not too excited about those bits.
> >>>>> As I mentioned above, I don't really like the stuff that one has to do
> >>>>> to support LSM stacking on the existing /proc interfaces, the
> >>>>> "label1\0label2\labelN\0" hack is probably the best (only?) option we
> >>>>> have for retrofitting multiple LSMs into those interfaces and I think
> >>>>> we can all agree it's not a great API. Considering that applications
> >>>>> that wish to become simultaneous multi-LSM aware are going to need
> >>>>> modification anyway, let's take a step back and see if we can do this
> >>>>> with a more sensible API.
> >>>> This is a compound problem. Some applications, including systemd and dbus,
> >>>> will require modification to completely support multiple concurrent LSMs
> >>>> in the long term. This will certainly be the case should someone be wild
> >>>> and crazy enough to use Smack and SELinux together. Even with the (Smack or
> >>>> SELinux) and AppArmor case the ps(1) command should be educated about the
> >>>> possibility of multiple "current" values. However, in a container world,
> >>>> where an Android container can run on an Ubuntu system, the presence of
> >>>> AppArmor on the base system is completely uninteresting to the SELinux
> >>>> aware applications in the container. This is a real use case.
> >>> If you are running AppArmor on the host system and SELinux in a
> >>> container you are likely going to have some *very* bizarre behavior as
> >>> the SELinux policy you load in the container will apply to the entire
> >>> system, including processes which started *before* the SELinux policy
> >>> was loaded. While I understand the point you are trying to make, I
> >>> don't believe the example you chose is going to work without a lot of
> >>> other changes.
> >> I don't use it myself, but I know it's frighteningly popular.
> > All right, I'm going to call your bluff here - who are these people
> > running AppArmor on the host and SELinux in a container? What policy
> > are they using, it's surely not an unmodified Fedora/RHEL or upstream
> > refpol policy? Do they run in enforcing mode without massive
> > permissions granted to kernel_t (I'm guessing all of the host
> > applications would appear as kernel_t)? How do you handle multiple
> > SELinux containers?
>
> Beats me. All that SELinux policy stuff is over my head. ;)
>
> Seriously, once they got the stacking patches applied they thanked
> me for the help and disappeared until they decided to update the
> kernel version and asked for help with the next round of patches.
> They told me what they wanted to do, which was to run Android in
> a container, but how they accomplished it was a set of details they
> didn't share. I assume that you are right that they had to do
> horrible things to either AppArmor or SELinux policy, or maybe both.
> I also assume they wanted this as an environment to develop Android
> applications, and may not have cared much about actual enforcement.
> But they are happy users.
>
> > I'm aware of *one* use case where SELinux is run in a container and
> > that required a number of careful constraints on the use case and a
> > good deal of hacking to enable. I'm sure there are definitely people
> > that *want* this, especially in the context of Ubuntu, but I really
> > doubt this is in widespread use today.
>
> What I know is that there is a community out there using it. I think
> you're right that the way they're using it would be displeasing to
> most of us.
Based on other comments in this thread it doesn't appear that there is
anyone using it, or at least not a significant percentage of users. I
get that sometimes we need to interpolate/extrapolate a bit to
understand what users are actually doing, especially with certain
security-focused users, but I think you extrapolated (or assumed) a
bit too much in this case. Please be more clear when you are
speculating in the future, there may be folks reading these mailing
lists that don't have the background or understanding to tell
assumptions from actual truth.
--
paul-moore.com
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-09-07 23:04 ` Paul Moore
0 siblings, 0 replies; 148+ messages in thread
From: Paul Moore @ 2022-09-07 23:04 UTC (permalink / raw)
To: Casey Schaufler
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On Wed, Sep 7, 2022 at 1:08 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 9/7/2022 8:13 AM, Paul Moore wrote:
> > On Tue, Sep 6, 2022 at 8:31 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >> On 9/6/2022 4:24 PM, Paul Moore wrote:
> >>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
> >>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
> >>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >>>>>>> I would like very much to get v38 or v39 of the LSM stacking for Apparmor
> >>>>>>> patch set in the LSM next branch for 6.1. The audit changes have polished
> >>>>>>> up nicely and I believe that all comments on the integrity code have been
> >>>>>>> addressed. The interface_lsm mechanism has been beaten to a frothy peak.
> >>>>>>> There are serious binder changes, but I think they address issues beyond
> >>>>>>> the needs of stacking. Changes outside these areas are pretty well limited
> >>>>>>> to LSM interface improvements.
> >>>>>> The LSM stacking patches are near the very top of my list to review
> >>>>>> once the merge window clears, the io_uring fixes are in (bug fix), and
> >>>>>> SCTP is somewhat sane again (bug fix). I'm hopeful that the io_uring
> >>>>>> and SCTP stuff can be finished up in the next week or two.
> >>>>>>
> >>>>>> Since I'm the designated first stuckee now for the stacking stuff I
> >>>>>> want to go back through everything with fresh eyes, which probably
> >>>>>> isn't a bad idea since it has been a while since I looked at the full
> >>>>>> patchset from bottom to top. I can tell you that I've never been
> >>>>>> really excited about the /proc changes, and believe it or not I've
> >>>>>> been thinking about those a fair amount since James asked me to start
> >>>>>> maintaining the LSM. I don't want to get into any detail until I've
> >>>>>> had a chance to look over everything again, but just a heads-up that
> >>>>>> I'm not too excited about those bits.
> >>>>> As I mentioned above, I don't really like the stuff that one has to do
> >>>>> to support LSM stacking on the existing /proc interfaces, the
> >>>>> "label1\0label2\labelN\0" hack is probably the best (only?) option we
> >>>>> have for retrofitting multiple LSMs into those interfaces and I think
> >>>>> we can all agree it's not a great API. Considering that applications
> >>>>> that wish to become simultaneous multi-LSM aware are going to need
> >>>>> modification anyway, let's take a step back and see if we can do this
> >>>>> with a more sensible API.
> >>>> This is a compound problem. Some applications, including systemd and dbus,
> >>>> will require modification to completely support multiple concurrent LSMs
> >>>> in the long term. This will certainly be the case should someone be wild
> >>>> and crazy enough to use Smack and SELinux together. Even with the (Smack or
> >>>> SELinux) and AppArmor case the ps(1) command should be educated about the
> >>>> possibility of multiple "current" values. However, in a container world,
> >>>> where an Android container can run on an Ubuntu system, the presence of
> >>>> AppArmor on the base system is completely uninteresting to the SELinux
> >>>> aware applications in the container. This is a real use case.
> >>> If you are running AppArmor on the host system and SELinux in a
> >>> container you are likely going to have some *very* bizarre behavior as
> >>> the SELinux policy you load in the container will apply to the entire
> >>> system, including processes which started *before* the SELinux policy
> >>> was loaded. While I understand the point you are trying to make, I
> >>> don't believe the example you chose is going to work without a lot of
> >>> other changes.
> >> I don't use it myself, but I know it's frighteningly popular.
> > All right, I'm going to call your bluff here - who are these people
> > running AppArmor on the host and SELinux in a container? What policy
> > are they using, it's surely not an unmodified Fedora/RHEL or upstream
> > refpol policy? Do they run in enforcing mode without massive
> > permissions granted to kernel_t (I'm guessing all of the host
> > applications would appear as kernel_t)? How do you handle multiple
> > SELinux containers?
>
> Beats me. All that SELinux policy stuff is over my head. ;)
>
> Seriously, once they got the stacking patches applied they thanked
> me for the help and disappeared until they decided to update the
> kernel version and asked for help with the next round of patches.
> They told me what they wanted to do, which was to run Android in
> a container, but how they accomplished it was a set of details they
> didn't share. I assume that you are right that they had to do
> horrible things to either AppArmor or SELinux policy, or maybe both.
> I also assume they wanted this as an environment to develop Android
> applications, and may not have cared much about actual enforcement.
> But they are happy users.
>
> > I'm aware of *one* use case where SELinux is run in a container and
> > that required a number of careful constraints on the use case and a
> > good deal of hacking to enable. I'm sure there are definitely people
> > that *want* this, especially in the context of Ubuntu, but I really
> > doubt this is in widespread use today.
>
> What I know is that there is a community out there using it. I think
> you're right that the way they're using it would be displeasing to
> most of us.
Based on other comments in this thread it doesn't appear that there is
anyone using it, or at least not a significant percentage of users. I
get that sometimes we need to interpolate/extrapolate a bit to
understand what users are actually doing, especially with certain
security-focused users, but I think you extrapolated (or assumed) a
bit too much in this case. Please be more clear when you are
speculating in the future, there may be folks reading these mailing
lists that don't have the background or understanding to tell
assumptions from actual truth.
--
paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
2022-09-07 23:04 ` Paul Moore
@ 2022-09-07 23:26 ` Casey Schaufler
-1 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-07 23:26 UTC (permalink / raw)
To: Paul Moore
Cc: LSM List, James Morris, linux-audit, John Johansen, Mimi Zohar,
keescook, SElinux list, casey
On 9/7/2022 4:04 PM, Paul Moore wrote:
> On Wed, Sep 7, 2022 at 1:08 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/7/2022 8:13 AM, Paul Moore wrote:
>>> On Tue, Sep 6, 2022 at 8:31 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>> On 9/6/2022 4:24 PM, Paul Moore wrote:
>>>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>>>>>> I would like very much to get v38 or v39 of the LSM stacking for Apparmor
>>>>>>>>> patch set in the LSM next branch for 6.1. The audit changes have polished
>>>>>>>>> up nicely and I believe that all comments on the integrity code have been
>>>>>>>>> addressed. The interface_lsm mechanism has been beaten to a frothy peak.
>>>>>>>>> There are serious binder changes, but I think they address issues beyond
>>>>>>>>> the needs of stacking. Changes outside these areas are pretty well limited
>>>>>>>>> to LSM interface improvements.
>>>>>>>> The LSM stacking patches are near the very top of my list to review
>>>>>>>> once the merge window clears, the io_uring fixes are in (bug fix), and
>>>>>>>> SCTP is somewhat sane again (bug fix). I'm hopeful that the io_uring
>>>>>>>> and SCTP stuff can be finished up in the next week or two.
>>>>>>>>
>>>>>>>> Since I'm the designated first stuckee now for the stacking stuff I
>>>>>>>> want to go back through everything with fresh eyes, which probably
>>>>>>>> isn't a bad idea since it has been a while since I looked at the full
>>>>>>>> patchset from bottom to top. I can tell you that I've never been
>>>>>>>> really excited about the /proc changes, and believe it or not I've
>>>>>>>> been thinking about those a fair amount since James asked me to start
>>>>>>>> maintaining the LSM. I don't want to get into any detail until I've
>>>>>>>> had a chance to look over everything again, but just a heads-up that
>>>>>>>> I'm not too excited about those bits.
>>>>>>> As I mentioned above, I don't really like the stuff that one has to do
>>>>>>> to support LSM stacking on the existing /proc interfaces, the
>>>>>>> "label1\0label2\labelN\0" hack is probably the best (only?) option we
>>>>>>> have for retrofitting multiple LSMs into those interfaces and I think
>>>>>>> we can all agree it's not a great API. Considering that applications
>>>>>>> that wish to become simultaneous multi-LSM aware are going to need
>>>>>>> modification anyway, let's take a step back and see if we can do this
>>>>>>> with a more sensible API.
>>>>>> This is a compound problem. Some applications, including systemd and dbus,
>>>>>> will require modification to completely support multiple concurrent LSMs
>>>>>> in the long term. This will certainly be the case should someone be wild
>>>>>> and crazy enough to use Smack and SELinux together. Even with the (Smack or
>>>>>> SELinux) and AppArmor case the ps(1) command should be educated about the
>>>>>> possibility of multiple "current" values. However, in a container world,
>>>>>> where an Android container can run on an Ubuntu system, the presence of
>>>>>> AppArmor on the base system is completely uninteresting to the SELinux
>>>>>> aware applications in the container. This is a real use case.
>>>>> If you are running AppArmor on the host system and SELinux in a
>>>>> container you are likely going to have some *very* bizarre behavior as
>>>>> the SELinux policy you load in the container will apply to the entire
>>>>> system, including processes which started *before* the SELinux policy
>>>>> was loaded. While I understand the point you are trying to make, I
>>>>> don't believe the example you chose is going to work without a lot of
>>>>> other changes.
>>>> I don't use it myself, but I know it's frighteningly popular.
>>> All right, I'm going to call your bluff here - who are these people
>>> running AppArmor on the host and SELinux in a container? What policy
>>> are they using, it's surely not an unmodified Fedora/RHEL or upstream
>>> refpol policy? Do they run in enforcing mode without massive
>>> permissions granted to kernel_t (I'm guessing all of the host
>>> applications would appear as kernel_t)? How do you handle multiple
>>> SELinux containers?
>> Beats me. All that SELinux policy stuff is over my head. ;)
>>
>> Seriously, once they got the stacking patches applied they thanked
>> me for the help and disappeared until they decided to update the
>> kernel version and asked for help with the next round of patches.
>> They told me what they wanted to do, which was to run Android in
>> a container, but how they accomplished it was a set of details they
>> didn't share. I assume that you are right that they had to do
>> horrible things to either AppArmor or SELinux policy, or maybe both.
>> I also assume they wanted this as an environment to develop Android
>> applications, and may not have cared much about actual enforcement.
>> But they are happy users.
>>
>>> I'm aware of *one* use case where SELinux is run in a container and
>>> that required a number of careful constraints on the use case and a
>>> good deal of hacking to enable. I'm sure there are definitely people
>>> that *want* this, especially in the context of Ubuntu, but I really
>>> doubt this is in widespread use today.
>> What I know is that there is a community out there using it. I think
>> you're right that the way they're using it would be displeasing to
>> most of us.
> Based on other comments in this thread it doesn't appear that there is
> anyone using it,
Let's just discard that use case then.
> or at least not a significant percentage of users.
Sure.
> I
> get that sometimes we need to interpolate/extrapolate a bit to
> understand what users are actually doing, especially with certain
> security-focused users, but I think you extrapolated (or assumed) a
> bit too much in this case.
Let's just assume that.
> Please be more clear when you are
> speculating in the future, there may be folks reading these mailing
> lists that don't have the background or understanding to tell
> assumptions from actual truth.
I erred in siting an example for which I am not positioned to provide
backup detail. My bad.
^ permalink raw reply [flat|nested] 148+ messages in thread
* Re: LSM stacking in next for 6.1?
@ 2022-09-07 23:26 ` Casey Schaufler
0 siblings, 0 replies; 148+ messages in thread
From: Casey Schaufler @ 2022-09-07 23:26 UTC (permalink / raw)
To: Paul Moore
Cc: John Johansen, SElinux list, James Morris, Mimi Zohar, LSM List,
linux-audit
On 9/7/2022 4:04 PM, Paul Moore wrote:
> On Wed, Sep 7, 2022 at 1:08 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/7/2022 8:13 AM, Paul Moore wrote:
>>> On Tue, Sep 6, 2022 at 8:31 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>> On 9/6/2022 4:24 PM, Paul Moore wrote:
>>>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>>> On 9/2/2022 2:30 PM, Paul Moore wrote:
>>>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul@paul-moore.com> wrote:
>>>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>>>>>> I would like very much to get v38 or v39 of the LSM stacking for Apparmor
>>>>>>>>> patch set in the LSM next branch for 6.1. The audit changes have polished
>>>>>>>>> up nicely and I believe that all comments on the integrity code have been
>>>>>>>>> addressed. The interface_lsm mechanism has been beaten to a frothy peak.
>>>>>>>>> There are serious binder changes, but I think they address issues beyond
>>>>>>>>> the needs of stacking. Changes outside these areas are pretty well limited
>>>>>>>>> to LSM interface improvements.
>>>>>>>> The LSM stacking patches are near the very top of my list to review
>>>>>>>> once the merge window clears, the io_uring fixes are in (bug fix), and
>>>>>>>> SCTP is somewhat sane again (bug fix). I'm hopeful that the io_uring
>>>>>>>> and SCTP stuff can be finished up in the next week or two.
>>>>>>>>
>>>>>>>> Since I'm the designated first stuckee now for the stacking stuff I
>>>>>>>> want to go back through everything with fresh eyes, which probably
>>>>>>>> isn't a bad idea since it has been a while since I looked at the full
>>>>>>>> patchset from bottom to top. I can tell you that I've never been
>>>>>>>> really excited about the /proc changes, and believe it or not I've
>>>>>>>> been thinking about those a fair amount since James asked me to start
>>>>>>>> maintaining the LSM. I don't want to get into any detail until I've
>>>>>>>> had a chance to look over everything again, but just a heads-up that
>>>>>>>> I'm not too excited about those bits.
>>>>>>> As I mentioned above, I don't really like the stuff that one has to do
>>>>>>> to support LSM stacking on the existing /proc interfaces, the
>>>>>>> "label1\0label2\labelN\0" hack is probably the best (only?) option we
>>>>>>> have for retrofitting multiple LSMs into those interfaces and I think
>>>>>>> we can all agree it's not a great API. Considering that applications
>>>>>>> that wish to become simultaneous multi-LSM aware are going to need
>>>>>>> modification anyway, let's take a step back and see if we can do this
>>>>>>> with a more sensible API.
>>>>>> This is a compound problem. Some applications, including systemd and dbus,
>>>>>> will require modification to completely support multiple concurrent LSMs
>>>>>> in the long term. This will certainly be the case should someone be wild
>>>>>> and crazy enough to use Smack and SELinux together. Even with the (Smack or
>>>>>> SELinux) and AppArmor case the ps(1) command should be educated about the
>>>>>> possibility of multiple "current" values. However, in a container world,
>>>>>> where an Android container can run on an Ubuntu system, the presence of
>>>>>> AppArmor on the base system is completely uninteresting to the SELinux
>>>>>> aware applications in the container. This is a real use case.
>>>>> If you are running AppArmor on the host system and SELinux in a
>>>>> container you are likely going to have some *very* bizarre behavior as
>>>>> the SELinux policy you load in the container will apply to the entire
>>>>> system, including processes which started *before* the SELinux policy
>>>>> was loaded. While I understand the point you are trying to make, I
>>>>> don't believe the example you chose is going to work without a lot of
>>>>> other changes.
>>>> I don't use it myself, but I know it's frighteningly popular.
>>> All right, I'm going to call your bluff here - who are these people
>>> running AppArmor on the host and SELinux in a container? What policy
>>> are they using, it's surely not an unmodified Fedora/RHEL or upstream
>>> refpol policy? Do they run in enforcing mode without massive
>>> permissions granted to kernel_t (I'm guessing all of the host
>>> applications would appear as kernel_t)? How do you handle multiple
>>> SELinux containers?
>> Beats me. All that SELinux policy stuff is over my head. ;)
>>
>> Seriously, once they got the stacking patches applied they thanked
>> me for the help and disappeared until they decided to update the
>> kernel version and asked for help with the next round of patches.
>> They told me what they wanted to do, which was to run Android in
>> a container, but how they accomplished it was a set of details they
>> didn't share. I assume that you are right that they had to do
>> horrible things to either AppArmor or SELinux policy, or maybe both.
>> I also assume they wanted this as an environment to develop Android
>> applications, and may not have cared much about actual enforcement.
>> But they are happy users.
>>
>>> I'm aware of *one* use case where SELinux is run in a container and
>>> that required a number of careful constraints on the use case and a
>>> good deal of hacking to enable. I'm sure there are definitely people
>>> that *want* this, especially in the context of Ubuntu, but I really
>>> doubt this is in widespread use today.
>> What I know is that there is a community out there using it. I think
>> you're right that the way they're using it would be displeasing to
>> most of us.
> Based on other comments in this thread it doesn't appear that there is
> anyone using it,
Let's just discard that use case then.
> or at least not a significant percentage of users.
Sure.
> I
> get that sometimes we need to interpolate/extrapolate a bit to
> understand what users are actually doing, especially with certain
> security-focused users, but I think you extrapolated (or assumed) a
> bit too much in this case.
Let's just assume that.
> Please be more clear when you are
> speculating in the future, there may be folks reading these mailing
> lists that don't have the background or understanding to tell
> assumptions from actual truth.
I erred in siting an example for which I am not positioned to provide
backup detail. My bad.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply [flat|nested] 148+ messages in thread