| Message ID | d15ee1ccfb91bda67d248b3ec70f0475@paul-moore.com (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Paul Moore |
| Headers | show |
| Series | [GIT,PULL] lsm/lsm-pr-20240911 | expand |
On 2024/09/13 10:29, Paul Moore wrote: > Linus, > > We've got a reasonably large pull request for the LSM framework this > time (at least it's large for us), here are the highlights: > > * Move the LSM framework to static calls > > Based on some of our exchanges over the summer, it sounds like you > are already familiar with the effort to convert the LSM callbacks > from function pointers to static calls. This pull request includes > that work and transitions the vast majority of the LSM callbacks into > static calls. Those callbacks which haven't been converted were > left as-is due to the general ugliness of the changes required to > support the static call conversion; we can revisit those callbacks > at a future date. > > It is worth mentioning that Tetsuo Handa is opposed to the static call > patches, some even carry his NACK, as they make it more difficult to > dynamically load out-of-tree LSMs, or unsupported LSMs on distro kernels. > Many of us have tried to explain that out-of-tree LSMs are not a > concern for the upstream LSM framework, or the Linux kernel in general, > and that decisions around what LSMs are enabled in distro kernels is > a distro issue, not an upstream issue, but unfortunately Tetsuo > continues to disregard these arguments. No, this is not only a distro issue but also an upstream issue! Because the upstream cannot afford accepting whatever proposed LSMs ( https://lkml.kernel.org/r/8ac2731c-a1db-df7b-3690-dac2b371e431@I-love.SAKURA.ne.jp ). That is, out-of-tree LSMs cannot become in-tree and obtain stable LSM ID is partially due to upstream (e.g. out of resources for review, or failure to pass patent examination because upstream does not think it adds a new value). Making out-of-tree (or in-tree but not built-in) LSMs harder to use is a penalty imposed by "Permanent members are exercising veto". At least, assigning stable LSM ID to whatever proposed LSM has absolutely zero cost. Current policy is a clear intention to lock out out-of-tree LSMs. If you say "I don't have intention to lock out out-of-tree LSMs", please don't go with just NACK added.
On Fri, Sep 13, 2024 at 8:28 AM Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote: > On 2024/09/13 10:29, Paul Moore wrote: > > Linus, > > > > We've got a reasonably large pull request for the LSM framework this > > time (at least it's large for us), here are the highlights: > > > > * Move the LSM framework to static calls > > > > Based on some of our exchanges over the summer, it sounds like you > > are already familiar with the effort to convert the LSM callbacks > > from function pointers to static calls. This pull request includes > > that work and transitions the vast majority of the LSM callbacks into > > static calls. Those callbacks which haven't been converted were > > left as-is due to the general ugliness of the changes required to > > support the static call conversion; we can revisit those callbacks > > at a future date. > > > > It is worth mentioning that Tetsuo Handa is opposed to the static call > > patches, some even carry his NACK, as they make it more difficult to > > dynamically load out-of-tree LSMs, or unsupported LSMs on distro kernels. > > Many of us have tried to explain that out-of-tree LSMs are not a > > concern for the upstream LSM framework, or the Linux kernel in general, > > and that decisions around what LSMs are enabled in distro kernels is > > a distro issue, not an upstream issue, but unfortunately Tetsuo > > continues to disregard these arguments. > > No, this is not only a distro issue but also an upstream issue! > Because the upstream cannot afford accepting whatever proposed LSMs > ( https://lkml.kernel.org/r/8ac2731c-a1db-df7b-3690-dac2b371e431@I-love.SAKURA.ne.jp ). I find it somewhat amusing that you are complaining about the LSM framework not accepting new LSMs in the same pull request where we are adding a new LSM (IPE). As a reminder, we have documented guidelines regarding the addition of new LSMs: https://github.com/LinuxSecurityModule/kernel/blob/main/README.md ... these guidelines were discussed quite a bit on-list some time ago, and are essentially the same undocumented guidelines the LSM framework has been following for quite some time now (I will admit the doc and testing bullet points are likely new). [SIDE NOTE: Eventually this doc will move over into the kernel tree, but I still consider it too much of a work-in-progress/draft to merge into mainline. We probably also need to do a bit of tidying up in the kernel doc area relating to LSMs.] > That is, out-of-tree LSMs cannot become in-tree and obtain stable LSM ID ... We've discussed this many times before, obtaining stable magic numbers (e.g. syscall numbers, LSM IDs, etc.) isn't possible until the associated code appears in a tagged released from Linus' tree. Of course there are workarounds which we've discussed, and Kees even put together a toy LSM demonstrating these workarounds. You've heard my stance on this several times in the past, but I'll repeat myself one more time for the sake of the wider audience. My focus is on the upstream Linux kernel and ensuring that the upstream, in-tree LSMs have the best framework possible to ensure their proper operation and ease of development/maintenance. While I have no intention to negatively impact out-of-tree LSMs, I will not harm the upstream code base solely to support out-of-tree LSMs. Further, if improvements to the upstream LSM framework are determined to harm out-of-tree LSMs, that shall be no reason to reject the upstream improvements. I believe this policy is not only consistent with that of previous LSM maintainers, but of the general Linux kernel as well.
On 2024/09/14 0:28, Paul Moore wrote: > I find it somewhat amusing that you are complaining about the LSM > framework not accepting new LSMs in the same pull request where we are > adding a new LSM (IPE). As a reminder, we have documented guidelines > regarding the addition of new LSMs: > > https://github.com/LinuxSecurityModule/kernel/blob/main/README.md (...snipped...) > While I have no intention to negatively impact out-of-tree LSMs, What I call "patent examination" is "New LSM Guidelines" section within that link. That section includes "here are a list of requirements for new LSM submissions:" and "The new LSM must be sufficiently unique", and out-of-tree LSMs which cannot satisfy it won't be able to become in-tree. If we apply this requirement to userspace program, this requirement means you are declaring that "postfix" (or anything except "sendmail") cannot become in-tree because "sendmail" is already in-tree. This is a clear intention of negatively impact out-of-tree LSMs. People have the right to use whatever subsets/alternatives. Even if a new LSM has were completely a subset of existing in-tree LSMs, people have the right to use such LSM. While I consider that some of out-of-tree LSMs being unable to become in-tree is inevitable, the requirement that any LSM has to be built-in is a barrier for LSMs which cannot be built-in. The "static call" changes in this pull request is saying something like "any kernel code has to be built into vmlinux, for CONFIG_MODULES=y is harmful", similar to "any software which is not included in this distribution must not be run, for software which is not included in this distribution is harmful". People have the right to install whatever userspace software / kernel modules they need. Making it difficult to use userspace software / kernel modules which the in-tree and built-in kernel code cannot provide is an abuse of dominant position, as well as removing CONFIG_MODULES=y support from the kernel. > My focus is on the upstream Linux kernel and ensuring that the upstream, > in-tree LSMs have the best framework possible to ensure their proper > operation and ease of development/maintenance. While I have no > intention to negatively impact out-of-tree LSMs, I will not harm the > upstream code base solely to support out-of-tree LSMs. Further, if > improvements to the upstream LSM framework are determined to harm > out-of-tree LSMs, that shall be no reason to reject the upstream > improvements. I have been asking you for a solution for "in-tree but not built-in" LSM (namely TOMOYO). You are refusing to provide a solution for the sake of "in-tree and built-in" LSMs. The "static call" changes fails to ensure that the upstream, in-tree TOMOYO to have the best framework. The "static call" changes makes the upstream, in-tree TOMOYO to have a worse framework than now. I'm not against "static call" changes itself as long as "in-tree but not built-in" LSMs can remain as easily usable as now. https://lkml.kernel.org/r/caafb609-8bef-4840-a080-81537356fc60@I-love.SAKURA.ne.jp is a recovery for avoid having worse framework than now. > We've discussed this many times before, obtaining stable magic numbers > (e.g. syscall numbers, LSM IDs, etc.) isn't possible until the > associated code appears in a tagged released from Linus' tree. Think about a hardware device. A stable device ID (e.g. PCI device ID) is assigned as soon as a new hardware device is developed; whether a device driver for Windows, Linux, MacOS are provided by upstream OS manufactures is irrelevant. Stable LSM ID has to be a property of any LSM. Not allowing out-of-tree LSMs to have stable LSM ID makes it difficult to use userspace software which depends on LSM ID. Again, this is an abuse of dominant position. > I believe this policy is not only consistent with that > of previous LSM maintainers, but of the general Linux kernel as well. The Linux kernel is a servant for users and userspace programs. Your policy is based on "benefits for in-tree and built-in Linux kernel code". Your policy lacks "benefits for users and userspace programs".
On Sun, Sep 15, 2024 at 8:38 PM Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote: > On 2024/09/14 0:28, Paul Moore wrote: > > I find it somewhat amusing that you are complaining about the LSM > > framework not accepting new LSMs in the same pull request where we are > > adding a new LSM (IPE). As a reminder, we have documented guidelines > > regarding the addition of new LSMs: > > > > https://github.com/LinuxSecurityModule/kernel/blob/main/README.md > (...snipped...) > > While I have no intention to negatively impact out-of-tree LSMs, > > What I call "patent examination" is "New LSM Guidelines" section within > that link. That section includes "here are a list of requirements for > new LSM submissions:" and "The new LSM must be sufficiently unique", and > out-of-tree LSMs which cannot satisfy it won't be able to become in-tree. > If we apply this requirement to userspace program, this requirement means > you are declaring that "postfix" (or anything except "sendmail") cannot > become in-tree because "sendmail" is already in-tree. This is a clear > intention of negatively impact out-of-tree LSMs. People have the right to > use whatever subsets/alternatives. Even if a new LSM has were completely a > subset of existing in-tree LSMs, people have the right to use such LSM. Comparing userspace applications to kernel code isn't a fair comparison as a userspace application can generally be added without impacting the other applications on the system. > While I consider that some of out-of-tree LSMs being unable to become in-tree > is inevitable, the requirement that any LSM has to be built-in is a barrier > for LSMs which cannot be built-in. Anyone is always free to build their own kernel with whatever code changes they like, this is the beauty of the kernel source being available and licensed as Open Source. You are free to build a kernel with whatever LSM you like included and enabled. You have been shown examples on how to do this in previous threads. > People have the right to install whatever userspace software / kernel modules > they need. Anyone is free to build their own kernel with whatever LSMs they want, either in-tree or out-of-tree; the static call changes do not prevent that. > > My focus is on the upstream Linux kernel and ensuring that the upstream, > > in-tree LSMs have the best framework possible to ensure their proper > > operation and ease of development/maintenance. While I have no > > intention to negatively impact out-of-tree LSMs, I will not harm the > > upstream code base solely to support out-of-tree LSMs. Further, if > > improvements to the upstream LSM framework are determined to harm > > out-of-tree LSMs, that shall be no reason to reject the upstream > > improvements. > > I have been asking you for a solution for "in-tree but not built-in" LSM > (namely TOMOYO). You are refusing to provide a solution for the sake of > "in-tree and built-in" LSMs. The "static call" changes fails to ensure that > the upstream, in-tree TOMOYO to have the best framework. The "static call" > changes makes the upstream, in-tree TOMOYO to have a worse framework than > now. As mentioned so many times before, the "in-tree but not built-in" LSM problem is entirely a distribution/binary-kernel problem. The upstream kernel community is not responsible for the choices and individual build configurations of the different Linux distros. Support for mechanisms which allow for dynamic LSMs in pre-built distro kernels is something we could consider, but so far everything that has been proposed has had a negative impact on the upstream kernel sources and has been rejected as a result.
The pull request you sent on Thu, 12 Sep 2024 21:29:54 -0400:
> https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git tags/lsm-pr-20240911
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a430d95c5efa2b545d26a094eb5f624e36732af0
Thank you!
On Mon, Sep 16, 2024 at 04:08:11AM -0400, Paul Moore wrote: Good morning, I hope the end of the week is going well for everyone. > On Sun, Sep 15, 2024 at 8:38???PM Tetsuo Handa > <penguin-kernel@i-love.sakura.ne.jp> wrote: > > On 2024/09/14 0:28, Paul Moore wrote: > > > I find it somewhat amusing that you are complaining about the LSM > > > framework not accepting new LSMs in the same pull request where we are > > > adding a new LSM (IPE). As a reminder, we have documented guidelines > > > regarding the addition of new LSMs: > > > > > > https://github.com/LinuxSecurityModule/kernel/blob/main/README.md > > (...snipped...) > > > While I have no intention to negatively impact out-of-tree LSMs, > > > > What I call "patent examination" is "New LSM Guidelines" section within > > that link. That section includes "here are a list of requirements for > > new LSM submissions:" and "The new LSM must be sufficiently unique", and > > out-of-tree LSMs which cannot satisfy it won't be able to become in-tree. > > If we apply this requirement to userspace program, this requirement means > > you are declaring that "postfix" (or anything except "sendmail") cannot > > become in-tree because "sendmail" is already in-tree. This is a clear > > intention of negatively impact out-of-tree LSMs. People have the right to > > use whatever subsets/alternatives. Even if a new LSM has were completely a > > subset of existing in-tree LSMs, people have the right to use such LSM. > Comparing userspace applications to kernel code isn't a fair > comparison as a userspace application can generally be added without > impacting the other applications on the system. Tetsuo's comparison may be a bit strained, but it remains relevant. Linux was founded on a concept of choice, the current LSM architecture struggles with the ability to facilitate generalized choice and flexibility. > > While I consider that some of out-of-tree LSMs being unable to > > become in-tree is inevitable, the requirement that any LSM has to > > be built-in is a barrier for LSMs which cannot be built-in. > Anyone is always free to build their own kernel with whatever code > changes they like, this is the beauty of the kernel source being > available and licensed as Open Source. You are free to build a > kernel with whatever LSM you like included and enabled. You have > been shown examples on how to do this in previous threads. > > People have the right to install whatever userspace software / > > kernel modules they need. > Anyone is free to build their own kernel with whatever LSMs they want, > either in-tree or out-of-tree; the static call changes do not prevent > that. This line of reasoning represents a bit of an indulgence in a false binary logic fallacy. Anyone reading this forum is certainly capable of building a kernel in any configuration they want to. That being said, the general Linux technical community now represents a cohort far larger than individuals who have the ability to build and platform a kernel of their choosing. From a security perspective, Linux will benefit from providing a better means to serve a middle ground where alternate security models and architectures can be implemented without building a kernel from scratch. > > > My focus is on the upstream Linux kernel and ensuring that the upstream, > > > in-tree LSMs have the best framework possible to ensure their proper > > > operation and ease of development/maintenance. While I have no > > > intention to negatively impact out-of-tree LSMs, I will not harm the > > > upstream code base solely to support out-of-tree LSMs. Further, if > > > improvements to the upstream LSM framework are determined to harm > > > out-of-tree LSMs, that shall be no reason to reject the upstream > > > improvements. > > > > I have been asking you for a solution for "in-tree but not built-in" LSM > > (namely TOMOYO). You are refusing to provide a solution for the sake of > > "in-tree and built-in" LSMs. The "static call" changes fails to ensure that > > the upstream, in-tree TOMOYO to have the best framework. The "static call" > > changes makes the upstream, in-tree TOMOYO to have a worse framework than > > now. > As mentioned so many times before, the "in-tree but not built-in" > LSM problem is entirely a distribution/binary-kernel problem. The > upstream kernel community is not responsible for the choices and > individual build configurations of the different Linux distros. > Support for mechanisms which allow for dynamic LSMs in pre-built > distro kernels is something we could consider, but so far everything > that has been proposed has had a negative impact on the upstream > kernel sources and has been rejected as a result. Not everything. As of the TSEM V4 release, which is now a month old, we have proposed a middle ground that provides multiple mechanisms for the mainsteam kernel to support alternate security models in an orthogonal manner, but it has struggled to receive any significant review. The V4 release now includes the ability to use loadable modules to implement customized security models. The premise for this support is to replace the need for a dynamic LSM with an LSM that has dynamic configurability. Bandwidth is always in short supply, but some internal investigation by our team has demonstrated that the TSEM architecture can implement Tomoyo as a loadable security model. TSEM also provides a framework for servicing the needs of Endpoint Detection and Response systems without having to write any kernel code at all. This same mechanism also facilitates the ability to apply machine learning detection and intervention models, a capability that is notably absent from any of the existing LSM's. For the record and everyone reading along at home, here are the links to the four releases: V1: https://lore.kernel.org/linux-security-module/20230204050954.11583-1-greg@enjellic.com/T/#t V2: https://lore.kernel.org/linux-security-module/20230710102319.19716-1-greg@enjellic.com/T/#t V3: https://lore.kernel.org/linux-security-module/20240401105015.27614-1-greg@enjellic.com/T/#t V4: https://lore.kernel.org/linux-security-module/20240826103728.3378-1-greg@enjellic.com/T/#t We believe that making some forward progress with review and inclusion of TSEM would positively impact the issues under discussion. > paul-moore.com Have a good weekend. As always, Dr. Greg The Quixote Project - Flailing at the Travails of Cybersecurity https://github.com/Quixote-Project
On 9/27/2024 1:58 AM, Dr. Greg wrote: > On Mon, Sep 16, 2024 at 04:08:11AM -0400, Paul Moore wrote: > > Good morning, I hope the end of the week is going well for everyone. > >> On Sun, Sep 15, 2024 at 8:38???PM Tetsuo Handa >> <penguin-kernel@i-love.sakura.ne.jp> wrote: >>> On 2024/09/14 0:28, Paul Moore wrote: >>>> I find it somewhat amusing that you are complaining about the LSM >>>> framework not accepting new LSMs in the same pull request where we are >>>> adding a new LSM (IPE). As a reminder, we have documented guidelines >>>> regarding the addition of new LSMs: >>>> >>>> https://github.com/LinuxSecurityModule/kernel/blob/main/README.md >>> (...snipped...) >>>> While I have no intention to negatively impact out-of-tree LSMs, >>> What I call "patent examination" is "New LSM Guidelines" section within >>> that link. That section includes "here are a list of requirements for >>> new LSM submissions:" and "The new LSM must be sufficiently unique", and >>> out-of-tree LSMs which cannot satisfy it won't be able to become in-tree. >>> If we apply this requirement to userspace program, this requirement means >>> you are declaring that "postfix" (or anything except "sendmail") cannot >>> become in-tree because "sendmail" is already in-tree. This is a clear >>> intention of negatively impact out-of-tree LSMs. People have the right to >>> use whatever subsets/alternatives. Even if a new LSM has were completely a >>> subset of existing in-tree LSMs, people have the right to use such LSM. >> Comparing userspace applications to kernel code isn't a fair >> comparison as a userspace application can generally be added without >> impacting the other applications on the system. > Tetsuo's comparison may be a bit strained, but it remains relevant. > > Linux was founded on a concept of choice, the current LSM architecture > struggles with the ability to facilitate generalized choice and > flexibility. > >>> While I consider that some of out-of-tree LSMs being unable to >>> become in-tree is inevitable, the requirement that any LSM has to >>> be built-in is a barrier for LSMs which cannot be built-in. >> Anyone is always free to build their own kernel with whatever code >> changes they like, this is the beauty of the kernel source being >> available and licensed as Open Source. You are free to build a >> kernel with whatever LSM you like included and enabled. You have >> been shown examples on how to do this in previous threads. >>> People have the right to install whatever userspace software / >>> kernel modules they need. >> Anyone is free to build their own kernel with whatever LSMs they want, >> either in-tree or out-of-tree; the static call changes do not prevent >> that. > This line of reasoning represents a bit of an indulgence in a false > binary logic fallacy. > > Anyone reading this forum is certainly capable of building a kernel in > any configuration they want to. That being said, the general Linux > technical community now represents a cohort far larger than > individuals who have the ability to build and platform a kernel of > their choosing. > > From a security perspective, Linux will benefit from providing a > better means to serve a middle ground where alternate security models > and architectures can be implemented without building a kernel from > scratch. Ye Gads. One can create SELinux policy to support just about any security model you can think of, although I was the first to decry its complexity. Smack access rules can be configured to support a wide variety of models, including Bell & LaPadula, Biba and rings of trust. AppArmor is very useful for targeted application security model enforcement. And then there's BPF. It seems to me that the problem isn't with the facilities provided to support the implementation of new security models, it is with the definition of those security modules. Or rather, the lack thereof. The ancient Bell & LaPadula sensitivity model can be implemented using Smack rules because it is sufficiently well defined. If the end user can define their policy as clearly as B&P does, its a slam dunk for any of the aforementioned LSMs.
On Fri, Sep 27, 2024 at 09:33:19AM -0700, Casey Schaufler wrote: Good morning Casey, always good to get your reflections, we hope your week is starting well. > On 9/27/2024 1:58 AM, Dr. Greg wrote: > > On Mon, Sep 16, 2024 at 04:08:11AM -0400, Paul Moore wrote: > > > > Good morning, I hope the end of the week is going well for everyone. > > > >> On Sun, Sep 15, 2024 at 8:38???PM Tetsuo Handa > >> <penguin-kernel@i-love.sakura.ne.jp> wrote: > >>> On 2024/09/14 0:28, Paul Moore wrote: > >>>> I find it somewhat amusing that you are complaining about the LSM > >>>> framework not accepting new LSMs in the same pull request where we are > >>>> adding a new LSM (IPE). As a reminder, we have documented guidelines > >>>> regarding the addition of new LSMs: > >>>> > >>>> https://github.com/LinuxSecurityModule/kernel/blob/main/README.md > >>> (...snipped...) > >>>> While I have no intention to negatively impact out-of-tree LSMs, > >>> What I call "patent examination" is "New LSM Guidelines" section > >>> within that link. That section includes "here are a list of > >>> requirements for new LSM submissions:" and "The new LSM must be > >>> sufficiently unique", and out-of-tree LSMs which cannot satisfy > >>> it won't be able to become in-tree. If we apply this > >>> requirement to userspace program, this requirement means you are > >>> declaring that "postfix" (or anything except "sendmail") cannot > >>> become in-tree because "sendmail" is already in-tree. This is a > >>> clear intention of negatively impact out-of-tree LSMs. People > >>> have the right to use whatever subsets/alternatives. Even if a > >>> new LSM has were completely a subset of existing in-tree LSMs, > >>> people have the right to use such LSM. > >> Comparing userspace applications to kernel code isn't a fair > >> comparison as a userspace application can generally be added without > >> impacting the other applications on the system. > > Tetsuo's comparison may be a bit strained, but it remains relevant. > > > > Linux was founded on a concept of choice, the current LSM architecture > > struggles with the ability to facilitate generalized choice and > > flexibility. > >>> While I consider that some of out-of-tree LSMs being unable to > >>> become in-tree is inevitable, the requirement that any LSM has to > >>> be built-in is a barrier for LSMs which cannot be built-in. > >> Anyone is always free to build their own kernel with whatever code > >> changes they like, this is the beauty of the kernel source being > >> available and licensed as Open Source. You are free to build a > >> kernel with whatever LSM you like included and enabled. You have > >> been shown examples on how to do this in previous threads. > >>> People have the right to install whatever userspace software / > >>> kernel modules they need. > >> Anyone is free to build their own kernel with whatever LSMs they want, > >> either in-tree or out-of-tree; the static call changes do not prevent > >> that. > > This line of reasoning represents a bit of an indulgence in a false > > binary logic fallacy. > > > > Anyone reading this forum is certainly capable of building a kernel in > > any configuration they want to. That being said, the general Linux > > technical community now represents a cohort far larger than > > individuals who have the ability to build and platform a kernel of > > their choosing. > > > > From a security perspective, Linux will benefit from providing a > > better means to serve a middle ground where alternate security models > > and architectures can be implemented without building a kernel from > > scratch. > Ye Gads. That certainly dates both of us, the last time I heard that phrase it was from Thurston Howell the III.... > One can create SELinux policy to support just about any security > model you can think of, although I was the first to decry its > complexity. Smack access rules can be configured to support a wide > variety of models, including Bell & LaPadula, Biba and rings of > trust. AppArmor is very useful for targeted application security > model enforcement. And then there's BPF. > > It seems to me that the problem isn't with the facilities provided > to support the implementation of new security models, it is with the > definition of those security modules. Or rather, the lack > thereof. The ancient Bell & LaPadula sensitivity model can be > implemented using Smack rules because it is sufficiently well > defined. If the end user can define their policy as clearly as B&P > does, its a slam dunk for any of the aforementioned LSMs. We certainly wouldn't choose to argue with any of this, given your repertoire in the field of mandatory access controls and security models. But therein lies the rub with respect to the implementation of system security. There are what, maybe 5-6 people in the world like yourself, that have the technical chops to translate the theoretical expressiveness you describe above into functional, let alone maintainable, security implementations? If there was the ability to practically implement just about any security model with SeLinux there would be no need for the LSM, yet its existence has arisen, given the desire to support multiple security schemes. That alone would seem to suggest the lack of technical prowess that is required to translate theoretical expressiveness into practical implementations. A primary challenge to security is scale of skill. In the face of limited advanced security skills, we have hundreds of thousands of people around the world creating and modifying millions of workloads, on a daily basis. I mentioned just recently, in a meeting with technical influencers here in the Great State of North Dakota, that we are never going to train our way out of this security problem. Cisco recognized this with network security and this fact was central to the concept of it's Application Centric Infrastructure (ACI). With respect to scale, ACI is based on the premise that the manageability of network security has to be an artifact of the development process. One of the motivations behind TSEM is to deliver that same concept to system security. The notion of allowing development teams to create a customized, bounded and mandatorily enforced security behavior, specific to a workload, as an extension of the development process. Another tool in the 'Secure By Design' toolbox. A concept that entities like NIST, DHS/CISA and particularly the insurance companies are going to force the industry to translate into practice, particularly in critical infrastructure systems. Have a good week. As always, Dr. Greg The Quixote Project - Flailing at the Travails of Cybersecurity https://github.com/Quixote-Project
On 9/30/2024 3:53 AM, Dr. Greg wrote: > On Fri, Sep 27, 2024 at 09:33:19AM -0700, Casey Schaufler wrote: > > Good morning Casey, always good to get your reflections, we hope your > week is starting well. > >> On 9/27/2024 1:58 AM, Dr. Greg wrote: >>> From a security perspective, Linux will benefit from providing a >>> better means to serve a middle ground where alternate security models >>> and architectures can be implemented without building a kernel from >>> scratch. >> Ye Gads. > That certainly dates both of us, the last time I heard that phrase it > was from Thurston Howell the III.... > >> One can create SELinux policy to support just about any security >> model you can think of, although I was the first to decry its >> complexity. Smack access rules can be configured to support a wide >> variety of models, including Bell & LaPadula, Biba and rings of >> trust. AppArmor is very useful for targeted application security >> model enforcement. And then there's BPF. >> >> It seems to me that the problem isn't with the facilities provided >> to support the implementation of new security models, it is with the >> definition of those security modules. Or rather, the lack >> thereof. The ancient Bell & LaPadula sensitivity model can be >> implemented using Smack rules because it is sufficiently well >> defined. If the end user can define their policy as clearly as B&P >> does, its a slam dunk for any of the aforementioned LSMs. > We certainly wouldn't choose to argue with any of this, given your > repertoire in the field of mandatory access controls and security > models. > > But therein lies the rub with respect to the implementation of system > security. > > There are what, maybe 5-6 people in the world like yourself, that have > the technical chops to translate the theoretical expressiveness you > describe above into functional, let alone maintainable, security > implementations? Flattering, but a touch off the mark. In the 1980's there were at least a dozen UNIX systems that implemented "B1", "B2" and/or "Compartmented Mode Workstation" systems. Five of those even got NSA evaluation certificates. There's plenty of expertise floating around today. The tools for doing security analysis have moved from "grep" to "AI". The original TCB definition for one system was done on paper, with a yellow highlighter, in a bar in Cambridge. Really, it's not that hard. It's messy and unpleasant and you learn things you don't want to know. You find a lot of bugs and discover all kinds of software behaviors that should never have been introduced. You become quite unpopular with your peers with other interests. We were "lucky" in the 1980's to have a US government executive order that drove security into operating systems, giving us the rationale for making changes. What's difficult today is justifying the effort. > If there was the ability to practically implement just about any > security model with SeLinux there would be no need for the LSM, The SELinux team did in fact propose removing the LSM infrastructure and making their code the official extended security mechanism. > yet > its existence has arisen, given the desire to support multiple > security schemes. That alone would seem to suggest the lack of > technical prowess that is required to translate theoretical > expressiveness into practical implementations. Nah, the technical prowess is there. The financial backing isn't. Besides, it's a *lot* more fun to write a filesystem than an SELinux policy (or set of Smack rules) for a distribution. > A primary challenge to security is scale of skill. > > In the face of limited advanced security skills, we have hundreds of > thousands of people around the world creating and modifying millions > of workloads, on a daily basis. Sure. Everyone uses their front door. Very few are locksmiths. > I mentioned just recently, in a meeting with technical influencers > here in the Great State of North Dakota, that we are never going to > train our way out of this security problem. > > Cisco recognized this with network security and this fact was central > to the concept of it's Application Centric Infrastructure (ACI). With > respect to scale, ACI is based on the premise that the manageability > of network security has to be an artifact of the development process. > > One of the motivations behind TSEM is to deliver that same concept to > system security. The notion of allowing development teams to create a > customized, bounded and mandatorily enforced security behavior, > specific to a workload, as an extension of the development process. SELinux + audit2allow. CONFIG_SECURITY_SMACK_BRINGUP. These are helpful, but you're not going to get away without applying some real brain power to your security model. And that's my point. Generated security models are crap. The best they can accomplish is to notice when a system changes behavior. Sometimes that's a security problem, and sometimes it is the system responding to anticipated changes, such as the phase of the moon. The NSA once told me that "A system is secure if it does what it is supposed to do, and nothing else". If you can't say in advance what the system is supposed to do, you can't determine if it is secure. > Another tool in the 'Secure By Design' toolbox. A concept that > entities like NIST, DHS/CISA and particularly the insurance companies > are going to force the industry to translate into practice, > particularly in critical infrastructure systems. > > Have a good week. > > As always, > Dr. Greg > > The Quixote Project - Flailing at the Travails of Cybersecurity > https://github.com/Quixote-Project >
Linus, We've got a reasonably large pull request for the LSM framework this time (at least it's large for us), here are the highlights: * Move the LSM framework to static calls Based on some of our exchanges over the summer, it sounds like you are already familiar with the effort to convert the LSM callbacks from function pointers to static calls. This pull request includes that work and transitions the vast majority of the LSM callbacks into static calls. Those callbacks which haven't been converted were left as-is due to the general ugliness of the changes required to support the static call conversion; we can revisit those callbacks at a future date. It is worth mentioning that Tetsuo Handa is opposed to the static call patches, some even carry his NACK, as they make it more difficult to dynamically load out-of-tree LSMs, or unsupported LSMs on distro kernels. Many of us have tried to explain that out-of-tree LSMs are not a concern for the upstream LSM framework, or the Linux kernel in general, and that decisions around what LSMs are enabled in distro kernels is a distro issue, not an upstream issue, but unfortunately Tetsuo continues to disregard these arguments. * Add the Integrity Policy Enforcement (IPE) LSM This pull request adds a new LSM, Integrity Policy Enforcement (IPE). There is plenty of documentation about IPE in this patches, so I'll refrain from going into too much detail here, but the basic motivation behind IPE is to provide a mechanism such that administrators can restrict execution to only those binaries which come from integrity protected storage, e.g. a dm-verity protected filesystem. You will notice that IPE requires additional LSM hooks in the initramfs, dm-verity, and fs-verity code, with the associated patches carrying ACK/review tags from the associated maintainers. We couldn't find an obvious maintainer for the initramfs code, but the IPE patchset has been widely posted over several years. Both Deven Bowers and Fan Wu have contributed to IPE's development over the past several years, with Fan Wu agreeing to serve as the IPE maintainer moving forward. Once IPE is accepted into your tree, I'll start working with Fan to ensure he has the necessary accounts, keys, etc. so that he can start submitting IPE pull requests to you directly during the next merge window. * Move the lifecycle management of the LSM blobs to the LSM framework Management of the LSM blobs (the LSM state buffers attached to various kernel structs, typically via a void pointer named "security" or similar) has been mixed, some blobs were allocated/managed by individual LSMs, others were managed by the LSM framework itself. Starting with this pull request we move management of all the LSM blobs, minus the XFRM blob, into the framework itself, improving consistency across LSMs, and reducing the amount of duplicated code across LSMs. Due to some additional work required to migrate the XFRM blob, it has been left as a todo item for a later date; from a practical standpoint this omission should have little impact as only SELinux provides a XFRM LSM implementation. * Fix problems with the LSM's handling of F_SETOWN The LSM hook for the fcntl(F_SETOWN) operation had a couple of problems: it was racy with itself, and it was disconnected from the associated DAC related logic in such a way that the LSM state could be updated in cases where the DAC state would not. We fix both of these problems by moving the security_file_set_fowner() hook into the same section of code where the DAC attributes are updated. Not only does this resolve the DAC/LSM synchronization issue, but as that code block is protected by a lock, it also resolve the race condition. * Fix potential problems with the security_inode_free() LSM hook Due to use of RCU to protect inodes and the placement of the LSM hook associated with freeing the inode, there is a bit of a challenge when it comes to managing any LSM state associated with an inode. The VFS folks are not open to relocating the LSM hook so we have to get creative when it comes to releasing an inode's LSM state. Traditionally we have used a single LSM callback within the hook that is triggered when the inode is "marked for death", but not actually released due to RCU. Unfortunately, this causes problems for LSMs which want to take an action when the inode's associated LSM state is actually released; this pull request adds an additional LSM callback, inode_free_security_rcu(), that is called when the inode's LSM state is released in the RCU free callback. * Refactor two LSM hooks to better fit the LSM return value patterns The vast majority of the LSM hooks follow the "return 0 on success, negative values on failure" pattern, however, there are a small handful that have unique return value behaviors which has caused confusion in the past and makes it difficult for the BPF verifier to properly vet BPF LSM programs. This pull request includes patches to convert two of these "special" LSM hooks to the common 0/-ERRNO pattern. * Various cleanups and improvements A handful of patches to remove redundant code, better leverage the IS_ERR_OR_NULL() helper, add missing "static" markings, and do some minor style fixups. -Paul -- The following changes since commit 8400291e289ee6b2bf9779ff1c83a291501f017b: Linux 6.11-rc1 (2024-07-28 14:19:55 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git tags/lsm-pr-20240911 for you to fetch changes up to 19c9d55d72a9040cf9dc8de62633e6217381106b: security: Update file_set_fowner documentation (2024-09-09 12:30:51 -0400) ---------------------------------------------------------------- lsm/stable-6.12 PR 20240911 ---------------------------------------------------------------- Casey Schaufler (6): lsm: infrastructure management of the sock security lsm: infrastructure management of the key security blob lsm: add helper for blob allocations lsm: infrastructure management of the dev_tun blob lsm: infrastructure management of the infiniband blob lsm: infrastructure management of the perf_event security blob Deven Bowers (13): lsm: add IPE lsm ipe: add policy parser ipe: add evaluation loop ipe: add LSM hooks on execution and kernel read ipe: add userspace interface audit,ipe: add IPE auditing support ipe: add permissive toggle block,lsm: add LSM blob and new LSM hooks for block devices dm-verity: expose root hash digest and signature data to LSMs ipe: add support for dm-verity as a trust provider scripts: add boot policy generation program ipe: kunit test for parser documentation: add IPE documentation Fan Wu (7): initramfs,lsm: add a security hook to do_populate_rootfs() ipe: introduce 'boot_verified' as a trust provider lsm: add new securityfs delete function lsm: add security_inode_setintegrity() hook fsverity: expose verified fsverity built-in signatures to LSMs ipe: enable support for fs-verity as a trust provider MAINTAINERS: add IPE entry with Fan Wu as maintainer Hongbo Li (1): lsm: Use IS_ERR_OR_NULL() helper function KP Singh (4): init/main.c: Initialize early LSMs after arch code, static keys and calls. kernel: Add helper macros for loop unrolling lsm: count the LSMs enabled at compile time lsm: replace indirect LSM hook calls with static calls Mickaël Salaün (2): fs: Fix file_set_fowner LSM hook inconsistencies security: Update file_set_fowner documentation Paul Moore (2): lsm: cleanup lsm_hooks.h lsm: add the inode_free_security_rcu() LSM implementation hook Tetsuo Handa (1): lsm: remove LSM_COUNT and LSM_CONFIG_COUNT Xu Kuohai (2): lsm: Refactor return value of LSM hook vm_enough_memory lsm: Refactor return value of LSM hook inode_copy_up_xattr Yang Li (1): ipe: Remove duplicated include in ipe.c Yue Haibing (1): lockdown: Make lockdown_lsmid static Documentation/admin-guide/LSM/index.rst | 1 Documentation/admin-guide/LSM/ipe.rst | 790 ++++++++++++ Documentation/admin-guide/kernel-parameters.txt | 12 Documentation/filesystems/fsverity.rst | 27 Documentation/security/index.rst | 1 Documentation/security/ipe.rst | 446 ++++++ MAINTAINERS | 10 block/bdev.c | 7 drivers/md/dm-verity-target.c | 118 + drivers/md/dm-verity.h | 4 fs/fcntl.c | 14 fs/overlayfs/copy_up.c | 6 fs/verity/signature.c | 18 include/linux/args.h | 6 include/linux/blk_types.h | 3 include/linux/lsm_count.h | 135 ++ include/linux/lsm_hook_defs.h | 20 include/linux/lsm_hooks.h | 129 + include/linux/security.h | 55 include/linux/unroll.h | 36 include/uapi/linux/audit.h | 3 include/uapi/linux/lsm.h | 1 init/initramfs.c | 3 init/main.c | 6 scripts/Makefile | 1 scripts/ipe/Makefile | 2 scripts/ipe/polgen/.gitignore | 2 scripts/ipe/polgen/Makefile | 5 scripts/ipe/polgen/polgen.c | 145 ++ security/Kconfig | 11 security/Makefile | 1 security/apparmor/include/net.h | 3 security/apparmor/lsm.c | 17 security/apparmor/net.c | 2 security/commoncap.c | 11 security/inode.c | 27 security/integrity/evm/evm_main.c | 2 security/integrity/ima/ima.h | 2 security/integrity/ima/ima_iint.c | 20 security/integrity/ima/ima_main.c | 2 security/ipe/.gitignore | 2 security/ipe/Kconfig | 97 + security/ipe/Makefile | 31 security/ipe/audit.c | 292 ++++ security/ipe/audit.h | 19 security/ipe/digest.c | 118 + security/ipe/digest.h | 26 security/ipe/eval.c | 393 +++++ security/ipe/eval.h | 70 + security/ipe/fs.c | 247 +++ security/ipe/fs.h | 16 security/ipe/hooks.c | 314 ++++ security/ipe/hooks.h | 52 security/ipe/ipe.c | 98 + security/ipe/ipe.h | 26 security/ipe/policy.c | 227 +++ security/ipe/policy.h | 98 + security/ipe/policy_fs.c | 472 +++++++ security/ipe/policy_parser.c | 559 ++++++++ security/ipe/policy_parser.h | 11 security/ipe/policy_tests.c | 296 ++++ security/landlock/fs.c | 9 security/lockdown/lockdown.c | 2 security/security.c | 615 ++++++--- security/selinux/hooks.c | 176 -- security/selinux/include/objsec.h | 28 security/selinux/netlabel.c | 23 security/smack/smack.h | 12 security/smack/smack_lsm.c | 107 - security/smack/smack_netfilter.c | 4 tools/testing/selftests/lsm/lsm_list_modules_test.c | 3 71 files changed, 6063 insertions(+), 484 deletions(-) -- paul-moore.com