Announcement

Collapse
No announcement yet.

Linux 5.4 Pulls In LOCKDOWN Support For Opt-In Hardware/Kernel Security Restrictions

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by tchiwam View Post
    I am wrong in thinking that this is more akin to the now pay for gr patch set than a loss of freedom ?
    Unrelated question: Is it true that GrSecurity's userbase crumbled into dust after they announced it wasn't going to be free anymore?

    Comment


    • #22
      Originally posted by starshipeleven View Post
      Yeah sure. Just preventing 99% of the tampering is as simple as disabling the kernel module support and unsafe shit like /dev/mem (both are a kernel compile option) and compiling in the kernel all hardware support modules you need.
      Disabling kernel modules is one part of hardening the system, but I dare you find a public root exploit for any existing consumer device that actually uses that path (or /dev/mem). Most of them exploit quite different avenues.

      Originally posted by starshipeleven View Post
      Then you sign your kernel image and enforce signature checking with the bootloader. Boom. Device is locked down.
      That is the locked bootloader which I am talking about.

      Originally posted by starshipeleven View Post
      Not really.
      Yes, really.

      Originally posted by tildearrow View Post
      Unrelated question: Is it true that GrSecurity's userbase crumbled into dust after they announced it wasn't going to be free anymore?
      Well, the change was aimed at eliminating the non-paying users which were the vast majority. So that would not be exactly surprising?

      Comment


      • #23
        Originally posted by tildearrow View Post

        Unrelated question: Is it true that GrSecurity's userbase crumbled into dust after they announced it wasn't going to be free anymore?
        Not only that, what are the performance hits with all the seccheck bells turned on...

        I kept on using it on outside facing servers but I don't work there anymore.

        Comment


        • #24
          Originally posted by Marc.2377 View Post
          The way I see it, anyone complaining "it hurts my freedom" regarding this patchset doesn't have the slightest clue what the patches are actually about.

          The lockdown are hardening against exploitation, rootkits and legit 'malicious actors' (as I've seen them called) - they are not about locking down on end users.
          It really depends if one got full system access or not. It now something even beyond "root" though. And I would bet soon you'll see that in e.g. phones. To lock users out of "their" devices. That aren't really "their", and even less their with this feature. However if one has got the key from this jail, it looks like powerful security feature, that's for sure.

          At this point... well, at least we have to be picky about devices.

          Comment


          • #25
            Originally posted by chithanh View Post
            Disabling kernel modules is one part of hardening the system, but I dare you find a public root exploit for any existing consumer device that actually uses that path (or /dev/mem).
            Writing to /dev/mem allows one to do absolutely arbitrary things. I even accessed HW REGS like that - without kernel even being aware I'm using hardware in question. Not just it makes things perilous (since kernel not aware, it can try access HW at same time, the result is unpredictable), many kinds of HW could actually be killed that way on lowest or physical levels. I can even propose some funny way to shoot your legs (that would leave you with unrecoverable perma-brick).

            Under normal circumstances in production system usermode should not do something like that, regardless if it root or not (its fundamentally wrong approach in multitask OS). I only did that for peripheral unsupported by kernel, to try to poke it with stick and see how it works, being dead sure kernel would not interfere with it due to lack of drivers. If someone got legit rights to do all that, they probably shouldn't mind booting "special" kernel as extra safeguard that much. After all e.g. openwrt does protects e.g. boot loader partitions by default. Just to prevent a really nasty "Game Over" scenarios. Those who really want to do exactly that end up building and booting custom kernel. Serves as very good comfirmation they know what they are doing.
            Last edited by SystemCrasher; 02 October 2019, 03:59 AM.

            Comment

            Working...
            X