Linux root access recovery by booting on the console












4















Very recently I recovered a root password for a Debian server by booting into single user mode. This resulted in me having access to a shell with root privileges (prompt said "root@none") Now this has left me wondering why a potential intruder can't just reboot a system and use the same process to reset the root password and infiltrate your treasure trove?!



See (https://serverfault.com/questions/482079/debian-boot-to-single-user-mode)










share|improve this question

























  • Most computer security systems accept this limitation. Generally speaking, if you have physical access to a machine, you can do anything you want to it. Trying to protect against physical tampering is a physical realm solution - software cannot help with that unless you are willing to make emergency recovery difficult.

    – Brandon
    Jun 23 '16 at 23:31











  • This is why you lock computers in cages

    – Neil McGuigan
    Jun 24 '16 at 17:40
















4















Very recently I recovered a root password for a Debian server by booting into single user mode. This resulted in me having access to a shell with root privileges (prompt said "root@none") Now this has left me wondering why a potential intruder can't just reboot a system and use the same process to reset the root password and infiltrate your treasure trove?!



See (https://serverfault.com/questions/482079/debian-boot-to-single-user-mode)










share|improve this question

























  • Most computer security systems accept this limitation. Generally speaking, if you have physical access to a machine, you can do anything you want to it. Trying to protect against physical tampering is a physical realm solution - software cannot help with that unless you are willing to make emergency recovery difficult.

    – Brandon
    Jun 23 '16 at 23:31











  • This is why you lock computers in cages

    – Neil McGuigan
    Jun 24 '16 at 17:40














4












4








4








Very recently I recovered a root password for a Debian server by booting into single user mode. This resulted in me having access to a shell with root privileges (prompt said "root@none") Now this has left me wondering why a potential intruder can't just reboot a system and use the same process to reset the root password and infiltrate your treasure trove?!



See (https://serverfault.com/questions/482079/debian-boot-to-single-user-mode)










share|improve this question
















Very recently I recovered a root password for a Debian server by booting into single user mode. This resulted in me having access to a shell with root privileges (prompt said "root@none") Now this has left me wondering why a potential intruder can't just reboot a system and use the same process to reset the root password and infiltrate your treasure trove?!



See (https://serverfault.com/questions/482079/debian-boot-to-single-user-mode)







boot security root console






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 13 at 21:19









Rui F Ribeiro

39.5k1479133




39.5k1479133










asked Jun 23 '16 at 18:22









Sam Si TayebSam Si Tayeb

4015




4015













  • Most computer security systems accept this limitation. Generally speaking, if you have physical access to a machine, you can do anything you want to it. Trying to protect against physical tampering is a physical realm solution - software cannot help with that unless you are willing to make emergency recovery difficult.

    – Brandon
    Jun 23 '16 at 23:31











  • This is why you lock computers in cages

    – Neil McGuigan
    Jun 24 '16 at 17:40



















  • Most computer security systems accept this limitation. Generally speaking, if you have physical access to a machine, you can do anything you want to it. Trying to protect against physical tampering is a physical realm solution - software cannot help with that unless you are willing to make emergency recovery difficult.

    – Brandon
    Jun 23 '16 at 23:31











  • This is why you lock computers in cages

    – Neil McGuigan
    Jun 24 '16 at 17:40

















Most computer security systems accept this limitation. Generally speaking, if you have physical access to a machine, you can do anything you want to it. Trying to protect against physical tampering is a physical realm solution - software cannot help with that unless you are willing to make emergency recovery difficult.

– Brandon
Jun 23 '16 at 23:31





Most computer security systems accept this limitation. Generally speaking, if you have physical access to a machine, you can do anything you want to it. Trying to protect against physical tampering is a physical realm solution - software cannot help with that unless you are willing to make emergency recovery difficult.

– Brandon
Jun 23 '16 at 23:31













This is why you lock computers in cages

– Neil McGuigan
Jun 24 '16 at 17:40





This is why you lock computers in cages

– Neil McGuigan
Jun 24 '16 at 17:40










2 Answers
2






active

oldest

votes


















3














Several reasons: one, you have to have physical access to the servers, and most employees don't want to lose their jobs by getting caught on CCTV video breaking into systems. Then, you have some companies that implement BIOS / boot passwords or boot loader passwords. Sometimes, the "single user" option requires a password (if set up properly ahead of time), other times it simply isn't available.



Ultimately, though, you're correct - this is a very exploitable attack vector.






share|improve this answer































    3














    A potential intruder could reboot into single user mode if they had physical access. Physical security is just as important as software security. That is why schools lock out USB drives and the BIOS. You have to lock it down.



    In /etc/default/grub you can uncomment the following line



    GRUB_DISABLE_RECOVERY="true"


    And poof! Single User mode is now gone.






    share|improve this answer



















    • 3





      You should also set a GRUB password (to prevent someone from appending init=/bin/bash to your kernel cmdline) and lock down the BIOS (so that no one can circumvent your security measures with a Live CD). You could even encrypt to root partition to ensure that no one can access your data by removing the hard disk. But even then you're still vulnerable because someone could put an exploit into your unencrypted /boot partition so you'd need to move that onto a USB stick and always carry it with you. But your firmware is still vulnerable. Or just accept that perfect security isn't achievable:)

      – Martin von Wittich
      Jun 23 '16 at 19:22






    • 4





      ... And then a creative student figures out to short the battery, and poof! The BIOS and USB locks are now gone... Really, physical access = root, period.

      – Satō Katsura
      Jun 24 '16 at 7:15











    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "106"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f291686%2flinux-root-access-recovery-by-booting-on-the-console%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    3














    Several reasons: one, you have to have physical access to the servers, and most employees don't want to lose their jobs by getting caught on CCTV video breaking into systems. Then, you have some companies that implement BIOS / boot passwords or boot loader passwords. Sometimes, the "single user" option requires a password (if set up properly ahead of time), other times it simply isn't available.



    Ultimately, though, you're correct - this is a very exploitable attack vector.






    share|improve this answer




























      3














      Several reasons: one, you have to have physical access to the servers, and most employees don't want to lose their jobs by getting caught on CCTV video breaking into systems. Then, you have some companies that implement BIOS / boot passwords or boot loader passwords. Sometimes, the "single user" option requires a password (if set up properly ahead of time), other times it simply isn't available.



      Ultimately, though, you're correct - this is a very exploitable attack vector.






      share|improve this answer


























        3












        3








        3







        Several reasons: one, you have to have physical access to the servers, and most employees don't want to lose their jobs by getting caught on CCTV video breaking into systems. Then, you have some companies that implement BIOS / boot passwords or boot loader passwords. Sometimes, the "single user" option requires a password (if set up properly ahead of time), other times it simply isn't available.



        Ultimately, though, you're correct - this is a very exploitable attack vector.






        share|improve this answer













        Several reasons: one, you have to have physical access to the servers, and most employees don't want to lose their jobs by getting caught on CCTV video breaking into systems. Then, you have some companies that implement BIOS / boot passwords or boot loader passwords. Sometimes, the "single user" option requires a password (if set up properly ahead of time), other times it simply isn't available.



        Ultimately, though, you're correct - this is a very exploitable attack vector.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Jun 23 '16 at 18:31









        JohnJohn

        11.6k11730




        11.6k11730

























            3














            A potential intruder could reboot into single user mode if they had physical access. Physical security is just as important as software security. That is why schools lock out USB drives and the BIOS. You have to lock it down.



            In /etc/default/grub you can uncomment the following line



            GRUB_DISABLE_RECOVERY="true"


            And poof! Single User mode is now gone.






            share|improve this answer



















            • 3





              You should also set a GRUB password (to prevent someone from appending init=/bin/bash to your kernel cmdline) and lock down the BIOS (so that no one can circumvent your security measures with a Live CD). You could even encrypt to root partition to ensure that no one can access your data by removing the hard disk. But even then you're still vulnerable because someone could put an exploit into your unencrypted /boot partition so you'd need to move that onto a USB stick and always carry it with you. But your firmware is still vulnerable. Or just accept that perfect security isn't achievable:)

              – Martin von Wittich
              Jun 23 '16 at 19:22






            • 4





              ... And then a creative student figures out to short the battery, and poof! The BIOS and USB locks are now gone... Really, physical access = root, period.

              – Satō Katsura
              Jun 24 '16 at 7:15
















            3














            A potential intruder could reboot into single user mode if they had physical access. Physical security is just as important as software security. That is why schools lock out USB drives and the BIOS. You have to lock it down.



            In /etc/default/grub you can uncomment the following line



            GRUB_DISABLE_RECOVERY="true"


            And poof! Single User mode is now gone.






            share|improve this answer



















            • 3





              You should also set a GRUB password (to prevent someone from appending init=/bin/bash to your kernel cmdline) and lock down the BIOS (so that no one can circumvent your security measures with a Live CD). You could even encrypt to root partition to ensure that no one can access your data by removing the hard disk. But even then you're still vulnerable because someone could put an exploit into your unencrypted /boot partition so you'd need to move that onto a USB stick and always carry it with you. But your firmware is still vulnerable. Or just accept that perfect security isn't achievable:)

              – Martin von Wittich
              Jun 23 '16 at 19:22






            • 4





              ... And then a creative student figures out to short the battery, and poof! The BIOS and USB locks are now gone... Really, physical access = root, period.

              – Satō Katsura
              Jun 24 '16 at 7:15














            3












            3








            3







            A potential intruder could reboot into single user mode if they had physical access. Physical security is just as important as software security. That is why schools lock out USB drives and the BIOS. You have to lock it down.



            In /etc/default/grub you can uncomment the following line



            GRUB_DISABLE_RECOVERY="true"


            And poof! Single User mode is now gone.






            share|improve this answer













            A potential intruder could reboot into single user mode if they had physical access. Physical security is just as important as software security. That is why schools lock out USB drives and the BIOS. You have to lock it down.



            In /etc/default/grub you can uncomment the following line



            GRUB_DISABLE_RECOVERY="true"


            And poof! Single User mode is now gone.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Jun 23 '16 at 18:31









            Zachary BradyZachary Brady

            3,406932




            3,406932








            • 3





              You should also set a GRUB password (to prevent someone from appending init=/bin/bash to your kernel cmdline) and lock down the BIOS (so that no one can circumvent your security measures with a Live CD). You could even encrypt to root partition to ensure that no one can access your data by removing the hard disk. But even then you're still vulnerable because someone could put an exploit into your unencrypted /boot partition so you'd need to move that onto a USB stick and always carry it with you. But your firmware is still vulnerable. Or just accept that perfect security isn't achievable:)

              – Martin von Wittich
              Jun 23 '16 at 19:22






            • 4





              ... And then a creative student figures out to short the battery, and poof! The BIOS and USB locks are now gone... Really, physical access = root, period.

              – Satō Katsura
              Jun 24 '16 at 7:15














            • 3





              You should also set a GRUB password (to prevent someone from appending init=/bin/bash to your kernel cmdline) and lock down the BIOS (so that no one can circumvent your security measures with a Live CD). You could even encrypt to root partition to ensure that no one can access your data by removing the hard disk. But even then you're still vulnerable because someone could put an exploit into your unencrypted /boot partition so you'd need to move that onto a USB stick and always carry it with you. But your firmware is still vulnerable. Or just accept that perfect security isn't achievable:)

              – Martin von Wittich
              Jun 23 '16 at 19:22






            • 4





              ... And then a creative student figures out to short the battery, and poof! The BIOS and USB locks are now gone... Really, physical access = root, period.

              – Satō Katsura
              Jun 24 '16 at 7:15








            3




            3





            You should also set a GRUB password (to prevent someone from appending init=/bin/bash to your kernel cmdline) and lock down the BIOS (so that no one can circumvent your security measures with a Live CD). You could even encrypt to root partition to ensure that no one can access your data by removing the hard disk. But even then you're still vulnerable because someone could put an exploit into your unencrypted /boot partition so you'd need to move that onto a USB stick and always carry it with you. But your firmware is still vulnerable. Or just accept that perfect security isn't achievable:)

            – Martin von Wittich
            Jun 23 '16 at 19:22





            You should also set a GRUB password (to prevent someone from appending init=/bin/bash to your kernel cmdline) and lock down the BIOS (so that no one can circumvent your security measures with a Live CD). You could even encrypt to root partition to ensure that no one can access your data by removing the hard disk. But even then you're still vulnerable because someone could put an exploit into your unencrypted /boot partition so you'd need to move that onto a USB stick and always carry it with you. But your firmware is still vulnerable. Or just accept that perfect security isn't achievable:)

            – Martin von Wittich
            Jun 23 '16 at 19:22




            4




            4





            ... And then a creative student figures out to short the battery, and poof! The BIOS and USB locks are now gone... Really, physical access = root, period.

            – Satō Katsura
            Jun 24 '16 at 7:15





            ... And then a creative student figures out to short the battery, and poof! The BIOS and USB locks are now gone... Really, physical access = root, period.

            – Satō Katsura
            Jun 24 '16 at 7:15


















            draft saved

            draft discarded




















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f291686%2flinux-root-access-recovery-by-booting-on-the-console%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            How to make a Squid Proxy server?

            Is this a new Fibonacci Identity?

            Touch on Surface Book