5 ms·

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

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.
        comex 9y ago
        Well… it's certainly much more practical to decide "I'll only run applications I trust" than "I'll only ever visit websites I trust" or, in full generality, "I'll only ever use any application to process data whose creator I trust". But I guess that's not really the point you're making, and of course, in an ideal world native apps would be no more dangerous than websites anyway…
  - shakna 9y ago
    > That's not my name, but anyway. Apologies, my words get a bit scrambled now and then.
- coatmatter 9y ago
  The actual quote: > "Just look at this thread. It took closer to a hundred emails (ok, so I'm exaggerating, but not _that_ much) until the real reason for the tie-in was actually exposed." http://lkml.iu.edu/hypermail/linux/kernel/1804.0/01690.html http://lkml.iu.edu/hypermail/linux/kernel/1804.0/01690.html

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.
        comex 9y ago
        Well… it's certainly much more practical to decide "I'll only run applications I trust" than "I'll only ever visit websites I trust" or, in full generality, "I'll only ever use any application to process data whose creator I trust". But I guess that's not really the point you're making, and of course, in an ideal world native apps would be no more dangerous than websites anyway…
- shakna 9y ago
  > That's not my name, but anyway. Apologies, my words get a bit scrambled now and then.
coatmatter 9y ago
The actual quote: > "Just look at this thread. It took closer to a hundred emails (ok, so I'm exaggerating, but not _that_ much) until the real reason for the tie-in was actually exposed." http://lkml.iu.edu/hypermail/linux/kernel/1804.0/01690.html http://lkml.iu.edu/hypermail/linux/kernel/1804.0/01690.html