Security - Runing Daemon, program as root or user vs sudo su












1















I have some questions about Linux security:




  • Running a process as root is a big mistake (root has too much power + a program get too much permissions in the system). I always ran processes as a user (I just used chmod, chown to have access to special files and to be able to run them). Is that a better, than running a process/daemon/program as root?


  • What if I use sudo su and then start a process, is it equal to the security of running process as user? Or instead is it the same as running a process as root?


  • Should I install software as root? Or maybe as a regular user?

  • What about editing configuration files, should I do it as root or maybe, as I did before, with sudo su from my regular unprivileged user account?










share|improve this question














bumped to the homepage by Community 1 hour ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.






migrated from serverfault.com Oct 16 '15 at 13:09


This question came from our site for system and network administrators.























    1















    I have some questions about Linux security:




    • Running a process as root is a big mistake (root has too much power + a program get too much permissions in the system). I always ran processes as a user (I just used chmod, chown to have access to special files and to be able to run them). Is that a better, than running a process/daemon/program as root?


    • What if I use sudo su and then start a process, is it equal to the security of running process as user? Or instead is it the same as running a process as root?


    • Should I install software as root? Or maybe as a regular user?

    • What about editing configuration files, should I do it as root or maybe, as I did before, with sudo su from my regular unprivileged user account?










    share|improve this question














    bumped to the homepage by Community 1 hour ago


    This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.






    migrated from serverfault.com Oct 16 '15 at 13:09


    This question came from our site for system and network administrators.





















      1












      1








      1








      I have some questions about Linux security:




      • Running a process as root is a big mistake (root has too much power + a program get too much permissions in the system). I always ran processes as a user (I just used chmod, chown to have access to special files and to be able to run them). Is that a better, than running a process/daemon/program as root?


      • What if I use sudo su and then start a process, is it equal to the security of running process as user? Or instead is it the same as running a process as root?


      • Should I install software as root? Or maybe as a regular user?

      • What about editing configuration files, should I do it as root or maybe, as I did before, with sudo su from my regular unprivileged user account?










      share|improve this question














      I have some questions about Linux security:




      • Running a process as root is a big mistake (root has too much power + a program get too much permissions in the system). I always ran processes as a user (I just used chmod, chown to have access to special files and to be able to run them). Is that a better, than running a process/daemon/program as root?


      • What if I use sudo su and then start a process, is it equal to the security of running process as user? Or instead is it the same as running a process as root?


      • Should I install software as root? Or maybe as a regular user?

      • What about editing configuration files, should I do it as root or maybe, as I did before, with sudo su from my regular unprivileged user account?







      security process users root daemon






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Oct 15 '15 at 19:26









      Doniu54Doniu54

      63




      63





      bumped to the homepage by Community 1 hour ago


      This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.







      bumped to the homepage by Community 1 hour ago


      This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.






      migrated from serverfault.com Oct 16 '15 at 13:09


      This question came from our site for system and network administrators.









      migrated from serverfault.com Oct 16 '15 at 13:09


      This question came from our site for system and network administrators.
























          1 Answer
          1






          active

          oldest

          votes


















          0














          The general idea is for a process to ask for (and have) the least amount of privilege it needs to do its job. Examples of this are web servers that bind to port 80 (which might need root) but then change to a non-privileged system user afterwards.



          You may have noticed "might need root" not, "must have root". Traditionally, processes would have to start as root to bind to a port less than 1024 and would then change later. Now with capabilities if set up correctly you don't need to do this. CAP_NET_BIND_SERVICE will let you bind to a port less than 1024 not as root.



          This is another iteration of "doing the same with less". Why run as root with ALL the access that gives when you only need one aspect which is binding ports. Capabilities give you this granularity.



          The difference between starting the daemon as root or as a different user and sudo as root is minor and generally will give the same results.



          For editing, admin work etc most people prefer being a "standard" user and sudo for those tasks. Making it impossible to login as root closes one possible insecure door.



          Software generally is installed as root. Why? Because if your webserver can modify its binaries or config files (why yes apache, I think your publically accessible directory should be /etc) is a bad idea.






          share|improve this answer























            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%2f236650%2fsecurity-runing-daemon-program-as-root-or-user-vs-sudo-su%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            0














            The general idea is for a process to ask for (and have) the least amount of privilege it needs to do its job. Examples of this are web servers that bind to port 80 (which might need root) but then change to a non-privileged system user afterwards.



            You may have noticed "might need root" not, "must have root". Traditionally, processes would have to start as root to bind to a port less than 1024 and would then change later. Now with capabilities if set up correctly you don't need to do this. CAP_NET_BIND_SERVICE will let you bind to a port less than 1024 not as root.



            This is another iteration of "doing the same with less". Why run as root with ALL the access that gives when you only need one aspect which is binding ports. Capabilities give you this granularity.



            The difference between starting the daemon as root or as a different user and sudo as root is minor and generally will give the same results.



            For editing, admin work etc most people prefer being a "standard" user and sudo for those tasks. Making it impossible to login as root closes one possible insecure door.



            Software generally is installed as root. Why? Because if your webserver can modify its binaries or config files (why yes apache, I think your publically accessible directory should be /etc) is a bad idea.






            share|improve this answer




























              0














              The general idea is for a process to ask for (and have) the least amount of privilege it needs to do its job. Examples of this are web servers that bind to port 80 (which might need root) but then change to a non-privileged system user afterwards.



              You may have noticed "might need root" not, "must have root". Traditionally, processes would have to start as root to bind to a port less than 1024 and would then change later. Now with capabilities if set up correctly you don't need to do this. CAP_NET_BIND_SERVICE will let you bind to a port less than 1024 not as root.



              This is another iteration of "doing the same with less". Why run as root with ALL the access that gives when you only need one aspect which is binding ports. Capabilities give you this granularity.



              The difference between starting the daemon as root or as a different user and sudo as root is minor and generally will give the same results.



              For editing, admin work etc most people prefer being a "standard" user and sudo for those tasks. Making it impossible to login as root closes one possible insecure door.



              Software generally is installed as root. Why? Because if your webserver can modify its binaries or config files (why yes apache, I think your publically accessible directory should be /etc) is a bad idea.






              share|improve this answer


























                0












                0








                0







                The general idea is for a process to ask for (and have) the least amount of privilege it needs to do its job. Examples of this are web servers that bind to port 80 (which might need root) but then change to a non-privileged system user afterwards.



                You may have noticed "might need root" not, "must have root". Traditionally, processes would have to start as root to bind to a port less than 1024 and would then change later. Now with capabilities if set up correctly you don't need to do this. CAP_NET_BIND_SERVICE will let you bind to a port less than 1024 not as root.



                This is another iteration of "doing the same with less". Why run as root with ALL the access that gives when you only need one aspect which is binding ports. Capabilities give you this granularity.



                The difference between starting the daemon as root or as a different user and sudo as root is minor and generally will give the same results.



                For editing, admin work etc most people prefer being a "standard" user and sudo for those tasks. Making it impossible to login as root closes one possible insecure door.



                Software generally is installed as root. Why? Because if your webserver can modify its binaries or config files (why yes apache, I think your publically accessible directory should be /etc) is a bad idea.






                share|improve this answer













                The general idea is for a process to ask for (and have) the least amount of privilege it needs to do its job. Examples of this are web servers that bind to port 80 (which might need root) but then change to a non-privileged system user afterwards.



                You may have noticed "might need root" not, "must have root". Traditionally, processes would have to start as root to bind to a port less than 1024 and would then change later. Now with capabilities if set up correctly you don't need to do this. CAP_NET_BIND_SERVICE will let you bind to a port less than 1024 not as root.



                This is another iteration of "doing the same with less". Why run as root with ALL the access that gives when you only need one aspect which is binding ports. Capabilities give you this granularity.



                The difference between starting the daemon as root or as a different user and sudo as root is minor and generally will give the same results.



                For editing, admin work etc most people prefer being a "standard" user and sudo for those tasks. Making it impossible to login as root closes one possible insecure door.



                Software generally is installed as root. Why? Because if your webserver can modify its binaries or config files (why yes apache, I think your publically accessible directory should be /etc) is a bad idea.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Dec 26 '15 at 10:29









                Craig SmallCraig Small

                49626




                49626






























                    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%2f236650%2fsecurity-runing-daemon-program-as-root-or-user-vs-sudo-su%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

                    CARDNET

                    Boot-repair Failure: Unable to locate package grub-common:i386

                    Aws NAT - Aws IGW- Aws router