Re: [PATCH v4 0/1] Safe LSM (un)loading, and immutable hooks
On Sat, Apr 7, 2018 at 2:31 AM, Casey Schaufler wrote: > On 4/5/2018 9:12 PM, Peter Dolding wrote: >> On Fri, Apr 6, 2018 at 11:31 AM, Sargun Dhillon wrote: >>> >>> On Thu, Apr 5, 2018 at 9:29 AM, Casey Schaufler >>> wrote: On 4/5/2018 3:31 AM, Peter Dolding wrote: > On Thu, Apr 5, 2018 at 7:55 PM, Igor Stoppa > wrote: >> On 01/04/18 08:41, Sargun Dhillon wrote: >>> The biggest security benefit of this patchset is the introduction of >>> read-only hooks, even if some security modules have mutable hooks. >>> Currently, if you have any LSMs with mutable hooks it will render all >>> heads, and >>> list nodes mutable. These are a prime place to attack, because being >>> able to >>> manipulate those hooks is a way to bypass all LSMs easily, and to >>> create a >>> persistent, covert channel to intercept nearly all calls. >>> >>> >>> If LSMs have a model to be unloaded, or are compled as modules, they >>> should mark >>> themselves mutable at compile time, and use the LSM_HOOK_INIT_MUTABLE >>> macro >>> instead of the LSM_HOOK_INIT macro, so their hooks are on the mutable >>> chain. >> I'd rather consider these types of hooks: >> >> A) hooks that are either const or marked as RO after init >> >> B) hooks that are writable for a short time, long enough to load >> additional, non built-in modules, but then get locked down >> I provided an example some time ago [1] >> >> C) hooks that are unloadable (and therefore always attackable?) >> >> Maybe type-A could be dropped and used only as type-B, if it's >> acceptable that type-A hooks are vulnerable before lock-down of type-B >> hooks. >> >> I have some doubts about the usefulness of type-C, though. >> The benefit I see htat it brings is that it avoids having to reboot >> when >> a mutable LSM is changed, at the price of leaving it attackable. >> >> Do you have any specific case in mind where this trade-off would be >> acceptable? >> > A useful case for loadable/unloadable LSM is development automate QA. > > So you have built a new program and you you want to test it against a > list of different LSM configurations without having to reboot the > system. So a run testsuite with LSM off then enabled LSM1 run > testsuite again disable LSM1 enable LSM2. run testsuite disable > LSM2... Basically repeating process. > > I would say normal production machines being able to swap LSM like > this does not have much use. > > Sometimes for productivity it makes sense to be able to breach > security. The fact you need to test with LSM disabled to know if any > of the defects you are seeing is LSM configuration related that > instance is already in the camp of non secure anyhow.. > > There is a shade of grey between something being a security hazard and > something being a useful feature. If the only value of a feature is development I strongly advocate against it. The number of times I've seen things completely messed up because it makes development easier is astonishing. If you have to enable something dangerous just for testing you have to wonder about the testing. >> Casey Schaufler we have had different points of view before. > > That's OK. I'm not always right. > >> I will >> point out some serous issues here. If you look a PPA > > Sorry, my acronym processor was seriously damaged in 1992. > What's "PPA" in this context? > Personal Package Archives the ubuntu term sorry. >> and many other >> locations you will find no LSM configuration files. >> >> Majority of QA servers around the place run with LSM off. There is a >> practical annoying reason. No point running application with new >> code with LSM on at first you run with LSM off to make sure program >> works. > > You're right. We have different points of view. > > Can someone tell me why it makes sense to develop a program > that they know is going to run in a secured environment in > an unsecured environment? The fact that it may be easier to > make the program "work" in the unsecured environment is the > reason you should never ever ever EVER do that. All you're > doing is setting up the security to be the bad guy when your > release is late. it makes sense when you have programs adding features that result in breaking the security policy. If that patch happens without any LSM fail conformance suite no point changing the LSM settings. So lets say you do develop in secured first. New patch fails to breaking security policy you update policy so that you can run test suite then you find out in the test suite that the patch does not work then human error creeps in and you fail to reverse the security policy change. There is a very good reason at least on a QA server for the first past to be without LSM. Failure without LSM active
Re: [PATCH v4 0/1] Safe LSM (un)loading, and immutable hooks
On 4/5/2018 9:12 PM, Peter Dolding wrote: > On Fri, Apr 6, 2018 at 11:31 AM, Sargun Dhillon wrote: >> >> On Thu, Apr 5, 2018 at 9:29 AM, Casey Schaufler >> wrote: >>> On 4/5/2018 3:31 AM, Peter Dolding wrote: On Thu, Apr 5, 2018 at 7:55 PM, Igor Stoppa wrote: > On 01/04/18 08:41, Sargun Dhillon wrote: >> The biggest security benefit of this patchset is the introduction of >> read-only hooks, even if some security modules have mutable hooks. >> Currently, if you have any LSMs with mutable hooks it will render all >> heads, and >> list nodes mutable. These are a prime place to attack, because being >> able to >> manipulate those hooks is a way to bypass all LSMs easily, and to >> create a >> persistent, covert channel to intercept nearly all calls. >> >> >> If LSMs have a model to be unloaded, or are compled as modules, they >> should mark >> themselves mutable at compile time, and use the LSM_HOOK_INIT_MUTABLE >> macro >> instead of the LSM_HOOK_INIT macro, so their hooks are on the mutable >> chain. > I'd rather consider these types of hooks: > > A) hooks that are either const or marked as RO after init > > B) hooks that are writable for a short time, long enough to load > additional, non built-in modules, but then get locked down > I provided an example some time ago [1] > > C) hooks that are unloadable (and therefore always attackable?) > > Maybe type-A could be dropped and used only as type-B, if it's > acceptable that type-A hooks are vulnerable before lock-down of type-B > hooks. > > I have some doubts about the usefulness of type-C, though. > The benefit I see htat it brings is that it avoids having to reboot > when > a mutable LSM is changed, at the price of leaving it attackable. > > Do you have any specific case in mind where this trade-off would be > acceptable? > A useful case for loadable/unloadable LSM is development automate QA. So you have built a new program and you you want to test it against a list of different LSM configurations without having to reboot the system. So a run testsuite with LSM off then enabled LSM1 run testsuite again disable LSM1 enable LSM2. run testsuite disable LSM2... Basically repeating process. I would say normal production machines being able to swap LSM like this does not have much use. Sometimes for productivity it makes sense to be able to breach security. The fact you need to test with LSM disabled to know if any of the defects you are seeing is LSM configuration related that instance is already in the camp of non secure anyhow.. There is a shade of grey between something being a security hazard and something being a useful feature. >>> If the only value of a feature is development I strongly >>> advocate against it. The number of times I've seen things >>> completely messed up because it makes development easier >>> is astonishing. If you have to enable something dangerous >>> just for testing you have to wonder about the testing. >>> > Casey Schaufler we have had different points of view before. That's OK. I'm not always right. > I will > point out some serous issues here. If you look a PPA Sorry, my acronym processor was seriously damaged in 1992. What's "PPA" in this context? > and many other > locations you will find no LSM configuration files. > > Majority of QA servers around the place run with LSM off. There is a > practical annoying reason. No point running application with new > code with LSM on at first you run with LSM off to make sure program > works. You're right. We have different points of view. Can someone tell me why it makes sense to develop a program that they know is going to run in a secured environment in an unsecured environment? The fact that it may be easier to make the program "work" in the unsecured environment is the reason you should never ever ever EVER do that. All you're doing is setting up the security to be the bad guy when your release is late. > If program works and you have the resources then transfer to > another machine/reboot to test with LSM this creates a broken > workflow. That's right. It's a broken workflow. If you want a program to work in secured environment it should be developed in that secured environment. It saves everyone time and effort. Except for the guy who's all set to blame security for making the release late. > When customer gets untested LSM configuration files and > they don't work what do support straight up recommend turning the LSM > off. YES! Your entire workflow is fundamentally flawed. The fact that the program works as desired running as root with SELinux in permissive mode is no indication that it will do so without privilege and/or with SELinux in enforcing mode. Why would anyone think it would? And yet
Re: [PATCH v4 0/1] Safe LSM (un)loading, and immutable hooks
On Fri, Apr 6, 2018 at 11:31 AM, Sargun Dhillon wrote: > > > On Thu, Apr 5, 2018 at 9:29 AM, Casey Schaufler > wrote: >> >> On 4/5/2018 3:31 AM, Peter Dolding wrote: >> > On Thu, Apr 5, 2018 at 7:55 PM, Igor Stoppa >> > wrote: >> >> On 01/04/18 08:41, Sargun Dhillon wrote: >> >>> The biggest security benefit of this patchset is the introduction of >> >>> read-only hooks, even if some security modules have mutable hooks. >> >>> Currently, if you have any LSMs with mutable hooks it will render all >> >>> heads, and >> >>> list nodes mutable. These are a prime place to attack, because being >> >>> able to >> >>> manipulate those hooks is a way to bypass all LSMs easily, and to >> >>> create a >> >>> persistent, covert channel to intercept nearly all calls. >> >>> >> >>> >> >>> If LSMs have a model to be unloaded, or are compled as modules, they >> >>> should mark >> >>> themselves mutable at compile time, and use the LSM_HOOK_INIT_MUTABLE >> >>> macro >> >>> instead of the LSM_HOOK_INIT macro, so their hooks are on the mutable >> >>> chain. >> >> >> >> I'd rather consider these types of hooks: >> >> >> >> A) hooks that are either const or marked as RO after init >> >> >> >> B) hooks that are writable for a short time, long enough to load >> >> additional, non built-in modules, but then get locked down >> >> I provided an example some time ago [1] >> >> >> >> C) hooks that are unloadable (and therefore always attackable?) >> >> >> >> Maybe type-A could be dropped and used only as type-B, if it's >> >> acceptable that type-A hooks are vulnerable before lock-down of type-B >> >> hooks. >> >> >> >> I have some doubts about the usefulness of type-C, though. >> >> The benefit I see htat it brings is that it avoids having to reboot >> >> when >> >> a mutable LSM is changed, at the price of leaving it attackable. >> >> >> >> Do you have any specific case in mind where this trade-off would be >> >> acceptable? >> >> >> > A useful case for loadable/unloadable LSM is development automate QA. >> > >> > So you have built a new program and you you want to test it against a >> > list of different LSM configurations without having to reboot the >> > system. So a run testsuite with LSM off then enabled LSM1 run >> > testsuite again disable LSM1 enable LSM2. run testsuite disable >> > LSM2... Basically repeating process. >> > >> > I would say normal production machines being able to swap LSM like >> > this does not have much use. >> > >> > Sometimes for productivity it makes sense to be able to breach >> > security. The fact you need to test with LSM disabled to know if any >> > of the defects you are seeing is LSM configuration related that >> > instance is already in the camp of non secure anyhow.. >> > >> > There is a shade of grey between something being a security hazard and >> > something being a useful feature. >> >> If the only value of a feature is development I strongly >> advocate against it. The number of times I've seen things >> completely messed up because it makes development easier >> is astonishing. If you have to enable something dangerous >> just for testing you have to wonder about the testing. >> Casey Schaufler we have had different points of view before. I will point out some serous issues here. If you look a PPA and many other locations you will find no LSM configuration files. Majority of QA servers around the place run with LSM off. There is a practical annoying reason. No point running application with new code with LSM on at first you run with LSM off to make sure program works. If program works and you have the resources then transfer to another machine/reboot to test with LSM this creates a broken workflow. When customer gets untested LSM configuration files and they don't work what do support straight up recommend turning the LSM off. Reality enabling LSM module loading and unloading on the fly on QA servers will not change their security 1 bit because they are most running without LSM at all. Making it simple to implement LSM configuration testing on QA servers will reduce the number of times end users at told to turn LSM off on their machines that will effect over all security. So we need to make the process of testing LSM configurations against applications on the QA servers way smoother. > So, first, this gives us a security benefit for LSMs which do not have > unloadable hooks. For those, they will always be able to load at boot-time, > and get protected hooks. Given that we can't really remove > security_delete_hooks until this SELinux removes their dependency on it, I'm > not sure we that this happy accident of safe (un)loading should be > sacrificed. > > I think having LSMs that are loadable after boot is extremely valuable. In > our specific use case, we've wanted to implement specific security policies > which are not capable of being implemented on the traditional LSMs. We have > the capability of deploying a Linux Kernel Module throughout our fleet. > Recent e
Re: [PATCH v4 0/1] Safe LSM (un)loading, and immutable hooks
On Thu, Apr 5, 2018 at 9:29 AM, Casey Schaufler wrote: > > On 4/5/2018 3:31 AM, Peter Dolding wrote: > > On Thu, Apr 5, 2018 at 7:55 PM, Igor Stoppa wrote: > >> On 01/04/18 08:41, Sargun Dhillon wrote: > >>> The biggest security benefit of this patchset is the introduction of > >>> read-only hooks, even if some security modules have mutable hooks. > >>> Currently, if you have any LSMs with mutable hooks it will render all > >>> heads, and > >>> list nodes mutable. These are a prime place to attack, because being able > >>> to > >>> manipulate those hooks is a way to bypass all LSMs easily, and to create a > >>> persistent, covert channel to intercept nearly all calls. > >>> > >>> > >>> If LSMs have a model to be unloaded, or are compled as modules, they > >>> should mark > >>> themselves mutable at compile time, and use the LSM_HOOK_INIT_MUTABLE > >>> macro > >>> instead of the LSM_HOOK_INIT macro, so their hooks are on the mutable > >>> chain. > >> > >> I'd rather consider these types of hooks: > >> > >> A) hooks that are either const or marked as RO after init > >> > >> B) hooks that are writable for a short time, long enough to load > >> additional, non built-in modules, but then get locked down > >> I provided an example some time ago [1] > >> > >> C) hooks that are unloadable (and therefore always attackable?) > >> > >> Maybe type-A could be dropped and used only as type-B, if it's > >> acceptable that type-A hooks are vulnerable before lock-down of type-B > >> hooks. > >> > >> I have some doubts about the usefulness of type-C, though. > >> The benefit I see htat it brings is that it avoids having to reboot when > >> a mutable LSM is changed, at the price of leaving it attackable. > >> > >> Do you have any specific case in mind where this trade-off would be > >> acceptable? > >> > > A useful case for loadable/unloadable LSM is development automate QA. > > > > So you have built a new program and you you want to test it against a > > list of different LSM configurations without having to reboot the > > system. So a run testsuite with LSM off then enabled LSM1 run > > testsuite again disable LSM1 enable LSM2. run testsuite disable > > LSM2... Basically repeating process. > > > > I would say normal production machines being able to swap LSM like > > this does not have much use. > > > > Sometimes for productivity it makes sense to be able to breach > > security. The fact you need to test with LSM disabled to know if any > > of the defects you are seeing is LSM configuration related that > > instance is already in the camp of non secure anyhow.. > > > > There is a shade of grey between something being a security hazard and > > something being a useful feature. > > If the only value of a feature is development I strongly > advocate against it. The number of times I've seen things > completely messed up because it makes development easier > is astonishing. If you have to enable something dangerous > just for testing you have to wonder about the testing. > > [Sorry for the double post] So, first, this gives us a security benefit for LSMs which do not have unloadable hooks. For those, they will always be able to load at boot-time, and get protected hooks. Given that we can't really remove security_delete_hooks until this SELinux removes their dependency on it, I'm not sure we that this happy accident of safe (un)loading should be sacrificed. I think having LSMs that are loadable after boot is extremely valuable. In our specific use case, we've wanted to implement specific security policies which are not capable of being implemented on the traditional LSMs. We have the capability of deploying a Linux Kernel Module throughout our fleet. Recent examples include issues with specific networking address families, IPTables (over netlink API). It's not easy to block out RDS across the system while it's running, even if seccomp can do it. We have other use cases -- like being able to run systemd in unprivileged user namespaces. This comes at the cost of giving the container CAP_SYS_ADMIN. We want to be able to give PID 1 in the user namespace CAP_SYS_ADMIN, but we want to revoke these capbilities across execve, without having to control the user's installation of systemd in their container. Other times, it's about performance. There is a measureable overhead with seccomp, and apparmor. LSMs fit better for doing some of the filtering we're forced to do in seccomp, or apparmor for containers. The performance gain by implementing purpose-built policies in custom LSMs is significant. My suggestion is to change security_delete_hooks() to return -EPERM by default. Hook unloading can then be disabled by a Kconfig feature. If we need to get "more secure", we can disable unloading via cmdline, or proc / securityfs at boot time.
Re: [PATCH v4 0/1] Safe LSM (un)loading, and immutable hooks
On 4/5/2018 3:31 AM, Peter Dolding wrote: > On Thu, Apr 5, 2018 at 7:55 PM, Igor Stoppa wrote: >> On 01/04/18 08:41, Sargun Dhillon wrote: >>> The biggest security benefit of this patchset is the introduction of >>> read-only hooks, even if some security modules have mutable hooks. >>> Currently, if you have any LSMs with mutable hooks it will render all >>> heads, and >>> list nodes mutable. These are a prime place to attack, because being able to >>> manipulate those hooks is a way to bypass all LSMs easily, and to create a >>> persistent, covert channel to intercept nearly all calls. >>> >>> >>> If LSMs have a model to be unloaded, or are compled as modules, they should >>> mark >>> themselves mutable at compile time, and use the LSM_HOOK_INIT_MUTABLE macro >>> instead of the LSM_HOOK_INIT macro, so their hooks are on the mutable >>> chain. >> >> I'd rather consider these types of hooks: >> >> A) hooks that are either const or marked as RO after init >> >> B) hooks that are writable for a short time, long enough to load >> additional, non built-in modules, but then get locked down >> I provided an example some time ago [1] >> >> C) hooks that are unloadable (and therefore always attackable?) >> >> Maybe type-A could be dropped and used only as type-B, if it's >> acceptable that type-A hooks are vulnerable before lock-down of type-B >> hooks. >> >> I have some doubts about the usefulness of type-C, though. >> The benefit I see htat it brings is that it avoids having to reboot when >> a mutable LSM is changed, at the price of leaving it attackable. >> >> Do you have any specific case in mind where this trade-off would be >> acceptable? >> > A useful case for loadable/unloadable LSM is development automate QA. > > So you have built a new program and you you want to test it against a > list of different LSM configurations without having to reboot the > system. So a run testsuite with LSM off then enabled LSM1 run > testsuite again disable LSM1 enable LSM2. run testsuite disable > LSM2... Basically repeating process. > > I would say normal production machines being able to swap LSM like > this does not have much use. > > Sometimes for productivity it makes sense to be able to breach > security. The fact you need to test with LSM disabled to know if any > of the defects you are seeing is LSM configuration related that > instance is already in the camp of non secure anyhow.. > > There is a shade of grey between something being a security hazard and > something being a useful feature. If the only value of a feature is development I strongly advocate against it. The number of times I've seen things completely messed up because it makes development easier is astonishing. If you have to enable something dangerous just for testing you have to wonder about the testing.
Re: [PATCH v4 0/1] Safe LSM (un)loading, and immutable hooks
On Thu, Apr 5, 2018 at 9:34 PM, Igor Stoppa wrote: > On 05/04/18 13:31, Peter Dolding wrote: >> On Thu, Apr 5, 2018 at 7:55 PM, Igor Stoppa wrote: >> There is a shade of grey between something being a security hazard and >> something being a useful feature. > > Maybe the problem I see is only in the naming: if what right now is > addressed as "mutable" were to be called in some other way that does not > imply that it's impossible to lock it down, then I think there wouldn't > be much of a problem anymore. > > How about s/mutable/protectable/g ? > > Then it could be a boot time parameter to decide if the "extra" hooks > should be protected or stay writable, for example for performing more > extensive testing. > Due to being a shades of grey area I would say kconfig 2 option and 1 boot time parameter. Some kernels the ability to change LSM on fly should be fully disabled in the build process. The abplity to change LSM at runtime has limited valid usage cases so even if the kernel is built with the ablity to change LSM at runtime enabled it should still be off by default until enabled with boot time parameter. So those who need the feature turn it on and those who don't need it on cannot turn it on just by installing a kernel. For systems that cannot use Linux kernel command line features to turn stuff on and off a kernel configuration option to change the default to on with warning in kernel configure. So 2 kconfig entries and 1 Kernel Boot Parameter. Of course when a feature like this is enabled there should be a kernel message so its recorded in logs and is check able if a feature like this that can lower security is turn on. The ability to change LSM on fly i see the development usage cases. I can not think of a single production system usage case for anyone who is not a developer. I might be thinking way to narrow. Unless someone else can find another use case I would suggest following what I suggest how a feature like this is enabled. Naming the feature what ever you think is suitable. Peter Dolding
Re: [PATCH v4 0/1] Safe LSM (un)loading, and immutable hooks
On 05/04/18 13:31, Peter Dolding wrote: > On Thu, Apr 5, 2018 at 7:55 PM, Igor Stoppa wrote: [...] >> A) hooks that are either const or marked as RO after init >> >> B) hooks that are writable for a short time, long enough to load >> additional, non built-in modules, but then get locked down >> I provided an example some time ago [1] >> >> C) hooks that are unloadable (and therefore always attackable?) [...] >> Do you have any specific case in mind where this trade-off would be >> acceptable? >> > > A useful case for loadable/unloadable LSM is development automate QA. I did not consider this case, but I see the point. [...] > I would say normal production machines being able to swap LSM like > this does not have much use. yes, this is what I had in mind [...] > There is a shade of grey between something being a security hazard and > something being a useful feature. Maybe the problem I see is only in the naming: if what right now is addressed as "mutable" were to be called in some other way that does not imply that it's impossible to lock it down, then I think there wouldn't be much of a problem anymore. How about s/mutable/protectable/g ? Then it could be a boot time parameter to decide if the "extra" hooks should be protected or stay writable, for example for performing more extensive testing. -- igor
Re: [PATCH v4 0/1] Safe LSM (un)loading, and immutable hooks
On Thu, Apr 5, 2018 at 7:55 PM, Igor Stoppa wrote: > On 01/04/18 08:41, Sargun Dhillon wrote: >> The biggest security benefit of this patchset is the introduction of >> read-only hooks, even if some security modules have mutable hooks. >> Currently, if you have any LSMs with mutable hooks it will render all heads, >> and >> list nodes mutable. These are a prime place to attack, because being able to >> manipulate those hooks is a way to bypass all LSMs easily, and to create a >> persistent, covert channel to intercept nearly all calls. >> >> >> If LSMs have a model to be unloaded, or are compled as modules, they should >> mark >> themselves mutable at compile time, and use the LSM_HOOK_INIT_MUTABLE macro >> instead of the LSM_HOOK_INIT macro, so their hooks are on the mutable >> chain. > > > I'd rather consider these types of hooks: > > A) hooks that are either const or marked as RO after init > > B) hooks that are writable for a short time, long enough to load > additional, non built-in modules, but then get locked down > I provided an example some time ago [1] > > C) hooks that are unloadable (and therefore always attackable?) > > Maybe type-A could be dropped and used only as type-B, if it's > acceptable that type-A hooks are vulnerable before lock-down of type-B > hooks. > > I have some doubts about the usefulness of type-C, though. > The benefit I see htat it brings is that it avoids having to reboot when > a mutable LSM is changed, at the price of leaving it attackable. > > Do you have any specific case in mind where this trade-off would be > acceptable? > A useful case for loadable/unloadable LSM is development automate QA. So you have built a new program and you you want to test it against a list of different LSM configurations without having to reboot the system. So a run testsuite with LSM off then enabled LSM1 run testsuite again disable LSM1 enable LSM2. run testsuite disable LSM2... Basically repeating process. I would say normal production machines being able to swap LSM like this does not have much use. Sometimes for productivity it makes sense to be able to breach security. The fact you need to test with LSM disabled to know if any of the defects you are seeing is LSM configuration related that instance is already in the camp of non secure anyhow.. There is a shade of grey between something being a security hazard and something being a useful feature. If development people are not testing that LSM configuration are clean because they don't really have enough machined to boot up individual instances with each LSM and this results in broken LSM configuration being shipped resulting in end users turning LSM off completely. Then a little security risk from providing unload-able LSM hooks when particularly requested is not that high really. With all the different LSM options how do application/distribution makers validate all the different LSM configurations effectively is a question that does need to be answered. In answering this question allowing this form of compromised security as a option might be quite a valid move. Peter Dolding
Re: [PATCH v4 0/1] Safe LSM (un)loading, and immutable hooks
On 01/04/18 08:41, Sargun Dhillon wrote: > The biggest security benefit of this patchset is the introduction of > read-only hooks, even if some security modules have mutable hooks. > Currently, if you have any LSMs with mutable hooks it will render all heads, > and > list nodes mutable. These are a prime place to attack, because being able to > manipulate those hooks is a way to bypass all LSMs easily, and to create a > persistent, covert channel to intercept nearly all calls. > > > If LSMs have a model to be unloaded, or are compled as modules, they should > mark > themselves mutable at compile time, and use the LSM_HOOK_INIT_MUTABLE macro > instead of the LSM_HOOK_INIT macro, so their hooks are on the mutable > chain. I'd rather consider these types of hooks: A) hooks that are either const or marked as RO after init B) hooks that are writable for a short time, long enough to load additional, non built-in modules, but then get locked down I provided an example some time ago [1] C) hooks that are unloadable (and therefore always attackable?) Maybe type-A could be dropped and used only as type-B, if it's acceptable that type-A hooks are vulnerable before lock-down of type-B hooks. I have some doubts about the usefulness of type-C, though. The benefit I see htat it brings is that it avoids having to reboot when a mutable LSM is changed, at the price of leaving it attackable. Do you have any specific case in mind where this trade-off would be acceptable? [1] https://lkml.org/lkml/2017/7/10/403 -- igor
