6 ms·

I rember there was resistance from Torvalds to merge a similar FreeBSD-style secure level implementation parchset a while ago (to prevent runtime kernel module

I rember there was resistance from Torvalds to merge a similar FreeBSD-style secure level implementation parchset a while ago (to prevent runtime kernel module loading and such). Will this parchset get merged?

shakna 9y ago
> I'm done with you. You're not listening, and you're repeating bogus arguments that make no sense. > No way in hell will I merge anything like this. > Linus [0] I highly doubt it. [0] http://lkml.iu.edu/hypermail/linux/kernel/1804.0/01607.html http://lkml.iu.edu/hypermail/linux/kernel/1804.0/01607.html
- cjbprime 9y ago
  Don't worry, the mean time between Linus saying something like that and then merging anyway is about ten minutes.
- aepiepaey 9y ago
  The "no way in hell" part clearly refers only to automatically enabling lockdown mode if the kernel was booted using secure boot. Lockdown mode itself is very likely to be merged. It becomes clearer if you read http://lkml.iu.edu/hypermail/linux/kernel/1804.0/01597.html http://lkml.iu.edu/hypermail/linux/kernel/1804.0/01597.html which was linked elsewhere in the comments here.
  - shakna 9y ago
    I read a fair way down the thread, but Garett and Linus continue to butt heads. Michael Garett seems to think lockdown without Secure Boot makes no sense. The kernel team seem to disagree. I didn't get to a point where any resolution was met, but Linus did complain about over 100 emails wasted before a legitimate reason they should be linked came out.
    - mjg59 9y ago
      > Michael Garett seems to think lockdown without Secure Boot makes no sense. The kernel team seem to disagree. That's not my name, but anyway. I don't think it makes no sense. I think asserting that it adds meaningful security in the absence of some other mechanism for gaining trust in the kernel is misleading, and I think the reduction in functionality associated with it isn't worth it unless you have that security benefit. As a result, I think having the default behaviour in a general purpose distribution be "Enable lockdown even if we didn't have any indication that we booted securely" doesn't make sense - more specialised projects may have a reason to do so.
      - cup-of-tea 9y ago
        > I think asserting that it adds meaningful security in the absence of some other mechanism for gaining trust in the kernel is misleading Do you think it's possible to do security at all without being educated? You seem to be advocating "doing the right thing" for the user, but if the user doesn't know how to do the right thing himself then any hope of security is out of the window anyway.
        mjg59 9y ago
        A perfectly informed user will never run an application that will modify their SSH configuration, so by that argument there's no need to prevent arbitrary user access to that file. We do our best to protect users without getting in their way because it's impossible to expect everybody to do everything right all the time.
        comex 9y ago
        Nitpick - a perfectly informed user can certainly run an application (such as a browser) that gets exploited by some external input to attempt to modify their SSH configuration.
        mjg59 9y ago
        A perfectly informed user would never have navigated to a site that was running malicious code. That's basically the point - the threat model today is sufficiently complicated that there's no such thing as a perfectly informed user, so we have to design systems to be resilient against users making mistakes.
newnewpdro 9y ago
Casually following the discussion on lkml has me under the impression that something will probably be merged in this vein - they're just bickering over important details and having communication problems. Edit: *Eventually Considering Linus has been arguing in favor of the value of lockdown in lieu of SecureBoot he's obviously on-board with the patchset conceptually. The problem seems to be in how SecureBoot and lockdown are currently related in the implementation when he's arguing they're entirely independent of one another. The things just fall apart in the communications.
snvzz 9y ago
Linus seems perfectly fine with the implementation. Except for it being tied to UEFI boot.

shakna 9y ago

> I'm done with you. You're not listening, and you're repeating bogus arguments that make no sense. > No way in hell will I merge anything like this. > Linus [0] I highly doubt it. [0] http://lkml.iu.edu/hypermail/linux/kernel/1804.0/01607.html http://lkml.iu.edu/hypermail/linux/kernel/1804.0/01607.html

cjbprime 9y ago
Don't worry, the mean time between Linus saying something like that and then merging anyway is about ten minutes.
aepiepaey 9y ago
The "no way in hell" part clearly refers only to automatically enabling lockdown mode if the kernel was booted using secure boot. Lockdown mode itself is very likely to be merged. It becomes clearer if you read http://lkml.iu.edu/hypermail/linux/kernel/1804.0/01597.html http://lkml.iu.edu/hypermail/linux/kernel/1804.0/01597.html which was linked elsewhere in the comments here.
- shakna 9y ago
  I read a fair way down the thread, but Garett and Linus continue to butt heads. Michael Garett seems to think lockdown without Secure Boot makes no sense. The kernel team seem to disagree. I didn't get to a point where any resolution was met, but Linus did complain about over 100 emails wasted before a legitimate reason they should be linked came out.
  - mjg59 9y ago
    > Michael Garett seems to think lockdown without Secure Boot makes no sense. The kernel team seem to disagree. That's not my name, but anyway. I don't think it makes no sense. I think asserting that it adds meaningful security in the absence of some other mechanism for gaining trust in the kernel is misleading, and I think the reduction in functionality associated with it isn't worth it unless you have that security benefit. As a result, I think having the default behaviour in a general purpose distribution be "Enable lockdown even if we didn't have any indication that we booted securely" doesn't make sense - more specialised projects may have a reason to do so.
    - cup-of-tea 9y ago
      > I think asserting that it adds meaningful security in the absence of some other mechanism for gaining trust in the kernel is misleading Do you think it's possible to do security at all without being educated? You seem to be advocating "doing the right thing" for the user, but if the user doesn't know how to do the right thing himself then any hope of security is out of the window anyway.
      - mjg59 9y ago
        A perfectly informed user will never run an application that will modify their SSH configuration, so by that argument there's no need to prevent arbitrary user access to that file. We do our best to protect users without getting in their way because it's impossible to expect everybody to do everything right all the time.
        comex 9y ago
        Nitpick - a perfectly informed user can certainly run an application (such as a browser) that gets exploited by some external input to attempt to modify their SSH configuration.
        mjg59 9y ago
        A perfectly informed user would never have navigated to a site that was running malicious code. That's basically the point - the threat model today is sufficiently complicated that there's no such thing as a perfectly informed user, so we have to design systems to be resilient against users making mistakes.

newnewpdro 9y ago

Casually following the discussion on lkml has me under the impression that something will probably be merged in this vein - they're just bickering over important details and having communication problems. Edit: *Eventually Considering Linus has been arguing in favor of the value of lockdown in lieu of SecureBoot he's obviously on-board with the patchset conceptually. The problem seems to be in how SecureBoot and lockdown are currently related in the implementation when he's arguing they're entirely independent of one another. The things just fall apart in the communications.

snvzz 9y ago

Linus seems perfectly fine with the implementation. Except for it being tied to UEFI boot.