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.

On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; 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.

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.

On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; 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.

On 9/2/2022 2:30 PM, Paul Moore wrote: ... > 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

On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: > On 9/2/2022 2:30 PM, Paul Moore wrote: >> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul(a)paul-moore.com&gt; wrote: >>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; 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.

>> Further, I think we can add the new syscall API separately from the >> LSM stacking changes as they do have standalone value. >

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.

On Tue, Sep 6, 2022 at 8:10 PM John Johansen <john.johansen(a)canonical.com&gt; wrote: > On 9/6/22 16:24, Paul Moore wrote: >> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: >>> On 9/2/2022 2:30 PM, Paul Moore wrote: >>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul(a)paul-moore.com&gt; wrote: >>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; 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.

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(a)canonical.com&gt; wrote: >>> On 9/6/22 16:24, Paul Moore wrote: >>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: >>>>> On 9/2/2022 2:30 PM, Paul Moore wrote: >>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul(a)paul-moore.com&gt; wrote: >>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; 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/71907fc5e7833866be6a... 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.

On Wed, Sep 7, 2022 at 12:42 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: > On 9/7/2022 7:41 AM, Paul Moore wrote: >> On Tue, Sep 6, 2022 at 8:10 PM John Johansen >> <john.johansen(a)canonical.com&gt; wrote: >>> On 9/6/22 16:24, Paul Moore wrote: >>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: >>>>> On 9/2/2022 2:30 PM, Paul Moore wrote: >>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul(a)paul-moore.com&gt; wrote: >>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; 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.

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 ....

> 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?

> 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.

On 9/7/2022 8:57 PM, Paul Moore wrote: > On Wed, Sep 7, 2022 at 7:53 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; 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.

On Thu, Sep 8, 2022 at 2:05 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: > On 9/7/2022 8:57 PM, Paul Moore wrote: >> On Wed, Sep 7, 2022 at 7:53 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; 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.

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/*").

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.)

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.

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.

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.

> 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.

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.SAK... > 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(a)I-love.SAKURA.ne.jp&gt;

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).

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.

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).

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.

> 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.

On October 30, 2022 7:02:52 AM PDT, Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp&gt; 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?

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-... 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_nvUyEUFsCJ... . 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.SAK... , 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.

On Tue, Oct 25, 2022 at 7:20 AM Tetsuo Handa <penguin-kernel(a)i-love.sakura.ne.jp&gt; 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.

> 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.

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.

On Thu, Sep 8, 2022 at 6:56 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; 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.

On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: > On 9/2/2022 2:30 PM, Paul Moore wrote: >> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul(a)paul-moore.com&gt; wrote: >>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; 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.

On Tue, Sep 6, 2022 at 8:31 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: > On 9/6/2022 4:24 PM, Paul Moore wrote: >> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: >>> On 9/2/2022 2:30 PM, Paul Moore wrote: >>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul(a)paul-moore.com&gt; wrote: >>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; 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 :)

On Wed, Sep 7, 2022 at 1:08 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: > On 9/7/2022 8:13 AM, Paul Moore wrote: >> On Tue, Sep 6, 2022 at 8:31 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: >>> On 9/6/2022 4:24 PM, Paul Moore wrote: >>>> On Fri, Sep 2, 2022 at 7:14 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; wrote: >>>>> On 9/2/2022 2:30 PM, Paul Moore wrote: >>>>>> On Tue, Aug 2, 2022 at 8:56 PM Paul Moore <paul(a)paul-moore.com&gt; wrote: >>>>>>> On Tue, Aug 2, 2022 at 8:01 PM Casey Schaufler <casey(a)schaufler-ca.com&gt; 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.

On 2022/08/03 9:01, Casey Schaufler 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. > After ((SELinux xor Smack) and AppArmor) is made possible in next for 6.1, what comes next? Are you planning to make (SELinux and Smack and AppArmor) possible?

My concern is, when loadable LSM modules becomes legal, for I'm refraining from again proposing CaitSith until LSM stacking completes.

Linus Torvalds said You security people are insane. I'm tired of this "only my version is correct" crap.

at https://lkml.kernel.org/r/alpine.LFD.0.999.0710010803280.3579@woody.linux... . Many modules 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/ ） are proposed 5 or 6 years ago, but mostly became silent...

I still need byte-code analysis for finding the hook and code for making the hook writable in AKARI/CaitSith due to lack of EXPORT_SYMBOL_GPL(security_add_hooks). I wonder when I can stop questions like https://osdn.net/projects/tomoyo/lists/archive/users-en/2022-September/00... caused by https://patchwork.kernel.org/project/linux-security-module/patch/alpine.L... .

Last 10 years, my involvement with Linux kernel is "fixing bugs" rather than "developing security mechanisms". Changes what I found in the past 10 years are: As far as I'm aware, more than 99% of systems still disable SELinux. People use RHEL, but the reason to choose RHEL is not because RHEL supports SELinux. The only thing changed is that the way to disable SELinux changed from SELINUX=disabled in /etc/selinux/config to selinux=0 on kernel command line options.

At least one of those, Landlock, has been merged upstream and is now available in modern released Linux Kernels. As far as the other LSMs are concerned, I don't recall there ever being significant interest among other developers or users to warrant their inclusion upstream. If the authors believe that has changed, or is simply not true, they are always welcome to post their patches again for discussion, review, and potential upstreaming. 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.

As has been discussed before, this isn't so much an issue with the __ro_after_init change, it's really more of an issue of running out-of-tree kernel code on pre-built distribution kernels, with "pre-built" being the most important part. It is my understanding that if the user/developer built their own patched kernel this would not likely be an issue as the out-of-tree LSM could be patched into the kernel source.

The problem comes when the user/developer wants to dynamically load their out-of-tree LSM into a pre-built distribution kernel, presumably to preserve a level of distribution support.

Unfortunately, to the best of my knowledge, none of the major enterprise Linux distributions will provide support for arbitrary third-party kernel modules (it may work, but if something fails the user is on their own to triage and resolve).

Beyond the support issue, there are likely to be other problems as well since the kernel interfaces, including the LSM hooks themselves, are not guaranteed to be stable across kernel releases.

> Last 10 years, my involvement with Linux kernel is "fixing bugs" rather than > "developing security mechanisms". Changes what I found in the past 10 years are: > > As far as I'm aware, more than 99% of systems still disable SELinux. I would challenge you to support that claim with data.

Granted, we are coming from very different LSM backgrounds, but I find that number very suspect. It has been several years since I last looked, but I believe the latest published Android numbers would give some support to the idea that more than 1% of SELinux based systems are running in enforcing (or permissive) mode. Significantly more.

> People use RHEL, > but the reason to choose RHEL is not because RHEL supports SELinux. Once again, if you are going to make strong claims such as this, please provide data. I know of several RHEL users that are only able to run SELinux based systems as it is the only LSM which meets their security requirements.

I would caution against confusing the security policy driven access controls provided by many in-tree LSMs with out-of-tree antivirus software. They have different goals, different use cases, and different user groups (markets).

On Fri, Sep 9, 2022 at 7:33 AM Tetsuo Handa <penguin-kernel(a)i-love.sakura.ne.jp&gt; wrote: > Inclusion into upstream is far from the goal. For better or worse, there is a long history of the upstream Linux Kernel focusing only on in-tree kernel code, I see no reason why we should change that now for LSMs.

> Although the upstream Linux Kernel focuses only on in-tree kernel code, > CONFIG_MODULES=y is not limited for in-tree kernel code. It is used by e.g. > device vendors to deliver their out-of-tree driver code. I see this argument all the time. The response is "get your driver upstream". Vendors/developers who whine "It's too hard" get no sympathy from me.