Announcement

Collapse
No announcement yet.

Ubuntu 20.10 Moving Ahead In Restricting Access To dmesg

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

  • #11
    Originally posted by gregzeng View Post
    Of special interest is which of these very many Ubuntu downstreamers will also include these Ubuntu 20.10 innovations? These downstreamers try to be more innovative, more adventurous than the big name "Canonical conservatives" upon which they are based. Mint 20.04 is the biggest of these Ubuntu outsiders. It has added many innovations. Which if any of these will make it into which of the official future Canonicals?
    It's not an innovation, it's a common sense. Linux ain't even first limiting user's access to dmesg


    Comment


    • #12
      Originally posted by birdie View Post

      Mine is not affected as I use Fedora which hasn't yet engaged in this security theatre idiocy.
      It's a great feature for RHEL so I am pretty sure it will get added to Fedora.

      Comment


      • #13
        Originally posted by uid313 View Post

        I think that Fedora and every other distribution will soon follow Ubuntu's lead and restrict access to dmesg.
        In openSUSE this change has come a long time ago.

        Comment


        • #14
          Originally posted by birdie View Post
          Speaking of "hardening guides". Many of them are outright idiotic, for instance they insist on changing your passwords regularly. Why would you do that?
          because hackers (or espionage agents, or even just pranksters) don't inform you when they know your current password.
          And also in most cases getting passwords does not involve 1337 skills where you p0wn20r the whole PC and install rootkits in the UEFI using Intel CPU vulnerabilities, but it's something more simple like looking with your eyes or overhearing conversations.
          Or any way that is not permanent, so if you change it the malicious agent has to redo his homework again to acquire the password again.

          This slows down attackers, which is what a good defence does. While if you don't change passwords they could have just compiled a list of passwords back in the day and come in your systems at the drop of a hat.

          It's never been proven to be effective against anything
          if you are too honest and boring to grasp what kinds of plans the password change limits, you really should not talk about security.

          people who are forced to change their passwords regularly start creating simple passwords
          simple passwords is not an issue if you have a half-decent system that will lock after say 20-30 wrong password attempts.

          and putting them in text files on their desktop
          Whoever has access to their desktop does not need to know the passwords in the text file. Not sure where is the issue.

          Good passwords which haven't been leaked/revealed/hacked are OK to use for eternity. Period.
          How do you tell if a password has been leaked/revealed/hacked?
          What if the malicious user does nothing obvious like "format C", is just making a copy of your databases and internal documents and none finds out? I guess that's ok right?
          Why dumb people like you that can't use logic are allowed to talk about security?
          Last edited by starshipeleven; 03 July 2020, 09:17 AM.

          Comment


          • #15
            Originally posted by Charlie68 View Post

            In openSUSE this change has come a long time ago.
            Debian also made the change years ago. I think the change was already made with stretch not sure abt. jessie.

            Comment


            • #16
              Originally posted by RahulSundaram View Post

              This is all public information readily accessible



              "The kernel syslog contains debugging information that is often useful during exploitation of other vulnerabilities, such as kernel heap addresses"

              This kconfig option was introduced and merged for a reason
              Default non-debug kernel doesn't print them. Anything else?

              Comment


              • #17
                Originally posted by birdie View Post

                Default non-debug kernel doesn't print them. Anything else?
                Not debug kernel can print these info and there has been many instances of WARN messages printing potentially sensitive info in the kernel ring buffer which ends up in dmesg. You can easily find CVE's dismissed before because distros and sysadmins have had the ability to restrict dmesg. I am sure you can find examples by doing your own research

                Comment


                • #18
                  Originally posted by birdie View Post
                  You know what this decision will actually lead to? People will start using sudo for pretty much everything without thinking. If anything, limitations like this make security worse, not better. There's very little [security] info that can be picked from dmesg and then lots of data is still available using /proc, /sys and various kernel APIs.
                  It isn't about people though. People are already sudoing everything. Worse, logging in as root directly.

                  It's about what info programs can access.

                  Comment


                  • #19
                    Originally posted by eydee View Post

                    It isn't about people though. People are already sudoing everything. Worse, logging in as root directly.

                    It's about what info programs can access.
                    Yes it is. And frankly, the Unix security model is gawd awful at protecting what intruders are really after in modern information theft. While persistence is always one of the goals, most of the time, you don't need root or even kernel exploits to gain that. Data thieves are after the data the targeted user has both on the server and the desktop. Securing dmesg, /proc, /sys, etc is part of the problem, but the fundamental Unix security model is going to have to change entirely from user based security to something else to protect against modern threats.

                    What that will look like may be capability based and it may have to be somewhat hardware VM based, but that's up to people better versed in security than me, and probably most of the neckbeards blindly following the Unix Way as if it's the end all and be all. Something major has got to change and defense must evolve to meet modern security needs not being met by any current OS.

                    Comment


                    • #20
                      Originally posted by stormcrow View Post

                      Yes it is. And frankly, the Unix security model is gawd awful at protecting what intruders are really after in modern information theft. While persistence is always one of the goals, most of the time, you don't need root or even kernel exploits to gain that. Data thieves are after the data the targeted user has both on the server and the desktop. Securing dmesg, /proc, /sys, etc is part of the problem, but the fundamental Unix security model is going to have to change entirely from user based security to something else to protect against modern threats.

                      What that will look like may be capability based and it may have to be somewhat hardware VM based, but that's up to people better versed in security than me, and probably most of the neckbeards blindly following the Unix Way as if it's the end all and be all. Something major has got to change and defense must evolve to meet modern security needs not being met by any current OS.
                      Have you tried SeLinux? Works pretty well at locking the system down.

                      Comment

                      Working...
                      X