Give a user privileges to switch process UID, GID

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
4
down vote

favorite












I'm writing an application that create worker processes run under other users credential. This program works under root. However, I want to run it under a less privileged account.



Is there any way I can give a user account the permission to assign UID, GID for the process it creates?



In other word, is there anyway to limit/grant a user privilege to certain set of syscalls? Thanks!







share|improve this question






















  • "Capabilities" may be what you're looking for. See man capsh and man capset for a couple of starting points.
    – roaima
    Jan 23 at 22:44















up vote
4
down vote

favorite












I'm writing an application that create worker processes run under other users credential. This program works under root. However, I want to run it under a less privileged account.



Is there any way I can give a user account the permission to assign UID, GID for the process it creates?



In other word, is there anyway to limit/grant a user privilege to certain set of syscalls? Thanks!







share|improve this question






















  • "Capabilities" may be what you're looking for. See man capsh and man capset for a couple of starting points.
    – roaima
    Jan 23 at 22:44













up vote
4
down vote

favorite









up vote
4
down vote

favorite











I'm writing an application that create worker processes run under other users credential. This program works under root. However, I want to run it under a less privileged account.



Is there any way I can give a user account the permission to assign UID, GID for the process it creates?



In other word, is there anyway to limit/grant a user privilege to certain set of syscalls? Thanks!







share|improve this question














I'm writing an application that create worker processes run under other users credential. This program works under root. However, I want to run it under a less privileged account.



Is there any way I can give a user account the permission to assign UID, GID for the process it creates?



In other word, is there anyway to limit/grant a user privilege to certain set of syscalls? Thanks!









share|improve this question













share|improve this question




share|improve this question








edited Jan 23 at 23:08









Gilles

506k11910011529




506k11910011529










asked Jan 23 at 22:22









Archer

146111




146111











  • "Capabilities" may be what you're looking for. See man capsh and man capset for a couple of starting points.
    – roaima
    Jan 23 at 22:44

















  • "Capabilities" may be what you're looking for. See man capsh and man capset for a couple of starting points.
    – roaima
    Jan 23 at 22:44
















"Capabilities" may be what you're looking for. See man capsh and man capset for a couple of starting points.
– roaima
Jan 23 at 22:44





"Capabilities" may be what you're looking for. See man capsh and man capset for a couple of starting points.
– roaima
Jan 23 at 22:44











1 Answer
1






active

oldest

votes

















up vote
3
down vote













Giving a process the right to change its UID is equivalent to giving it the right to run as root, since it can just change its UID to root. So even if you did that, there'd be no benefit.



You can improve the security of this setup by reducing the risk that the program can be tricked into doing something unintended as root. This won't reduce the impact of a complete compromise (if an attacker is able to make your program run arbitrary code), but it can reduce the impact of a partial compromise (where the attacker is only able to convince your program to do some specific thing, e.g. to read a file and display it). To reduce the risk, reduce the window of time during which the program runs as root. Make it run as a dedicated user, but keep its real UID set to 0. When the program needs to be root, it temporarily switches its effective UID to 0, and then switches back.



Note that this is not really practical in a multithreaded program since the user ID is for a whole process, not per thread.



For better robustness and security, implement privilege separation: split your program into two processes, one that runs as root and one that runs as a dedicated user. The process that runs as root should do as little as possible. It takes requests from the other process, validates them to the extent possible, and performs them. Then, even if the other process is buggy, the most it can do is issue valid requests.



For simple needs, rather than write a program that runs as root, you may be able to have a sudo rule that directly allows the main program to run commands as a third user. Instead of relying on an intermediate root program to perform validation, you can embed the validation in the sudo rule, e.g.



myapp_user ALL = (ALL:ALL) validate_and_run


This allows myapp_user to run a command as any user, but the command has to be validate_and_run (with any arguments).






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',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    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%2f419208%2fgive-a-user-privileges-to-switch-process-uid-gid%23new-answer', 'question_page');

    );

    Post as a guest






























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    3
    down vote













    Giving a process the right to change its UID is equivalent to giving it the right to run as root, since it can just change its UID to root. So even if you did that, there'd be no benefit.



    You can improve the security of this setup by reducing the risk that the program can be tricked into doing something unintended as root. This won't reduce the impact of a complete compromise (if an attacker is able to make your program run arbitrary code), but it can reduce the impact of a partial compromise (where the attacker is only able to convince your program to do some specific thing, e.g. to read a file and display it). To reduce the risk, reduce the window of time during which the program runs as root. Make it run as a dedicated user, but keep its real UID set to 0. When the program needs to be root, it temporarily switches its effective UID to 0, and then switches back.



    Note that this is not really practical in a multithreaded program since the user ID is for a whole process, not per thread.



    For better robustness and security, implement privilege separation: split your program into two processes, one that runs as root and one that runs as a dedicated user. The process that runs as root should do as little as possible. It takes requests from the other process, validates them to the extent possible, and performs them. Then, even if the other process is buggy, the most it can do is issue valid requests.



    For simple needs, rather than write a program that runs as root, you may be able to have a sudo rule that directly allows the main program to run commands as a third user. Instead of relying on an intermediate root program to perform validation, you can embed the validation in the sudo rule, e.g.



    myapp_user ALL = (ALL:ALL) validate_and_run


    This allows myapp_user to run a command as any user, but the command has to be validate_and_run (with any arguments).






    share|improve this answer
























      up vote
      3
      down vote













      Giving a process the right to change its UID is equivalent to giving it the right to run as root, since it can just change its UID to root. So even if you did that, there'd be no benefit.



      You can improve the security of this setup by reducing the risk that the program can be tricked into doing something unintended as root. This won't reduce the impact of a complete compromise (if an attacker is able to make your program run arbitrary code), but it can reduce the impact of a partial compromise (where the attacker is only able to convince your program to do some specific thing, e.g. to read a file and display it). To reduce the risk, reduce the window of time during which the program runs as root. Make it run as a dedicated user, but keep its real UID set to 0. When the program needs to be root, it temporarily switches its effective UID to 0, and then switches back.



      Note that this is not really practical in a multithreaded program since the user ID is for a whole process, not per thread.



      For better robustness and security, implement privilege separation: split your program into two processes, one that runs as root and one that runs as a dedicated user. The process that runs as root should do as little as possible. It takes requests from the other process, validates them to the extent possible, and performs them. Then, even if the other process is buggy, the most it can do is issue valid requests.



      For simple needs, rather than write a program that runs as root, you may be able to have a sudo rule that directly allows the main program to run commands as a third user. Instead of relying on an intermediate root program to perform validation, you can embed the validation in the sudo rule, e.g.



      myapp_user ALL = (ALL:ALL) validate_and_run


      This allows myapp_user to run a command as any user, but the command has to be validate_and_run (with any arguments).






      share|improve this answer






















        up vote
        3
        down vote










        up vote
        3
        down vote









        Giving a process the right to change its UID is equivalent to giving it the right to run as root, since it can just change its UID to root. So even if you did that, there'd be no benefit.



        You can improve the security of this setup by reducing the risk that the program can be tricked into doing something unintended as root. This won't reduce the impact of a complete compromise (if an attacker is able to make your program run arbitrary code), but it can reduce the impact of a partial compromise (where the attacker is only able to convince your program to do some specific thing, e.g. to read a file and display it). To reduce the risk, reduce the window of time during which the program runs as root. Make it run as a dedicated user, but keep its real UID set to 0. When the program needs to be root, it temporarily switches its effective UID to 0, and then switches back.



        Note that this is not really practical in a multithreaded program since the user ID is for a whole process, not per thread.



        For better robustness and security, implement privilege separation: split your program into two processes, one that runs as root and one that runs as a dedicated user. The process that runs as root should do as little as possible. It takes requests from the other process, validates them to the extent possible, and performs them. Then, even if the other process is buggy, the most it can do is issue valid requests.



        For simple needs, rather than write a program that runs as root, you may be able to have a sudo rule that directly allows the main program to run commands as a third user. Instead of relying on an intermediate root program to perform validation, you can embed the validation in the sudo rule, e.g.



        myapp_user ALL = (ALL:ALL) validate_and_run


        This allows myapp_user to run a command as any user, but the command has to be validate_and_run (with any arguments).






        share|improve this answer












        Giving a process the right to change its UID is equivalent to giving it the right to run as root, since it can just change its UID to root. So even if you did that, there'd be no benefit.



        You can improve the security of this setup by reducing the risk that the program can be tricked into doing something unintended as root. This won't reduce the impact of a complete compromise (if an attacker is able to make your program run arbitrary code), but it can reduce the impact of a partial compromise (where the attacker is only able to convince your program to do some specific thing, e.g. to read a file and display it). To reduce the risk, reduce the window of time during which the program runs as root. Make it run as a dedicated user, but keep its real UID set to 0. When the program needs to be root, it temporarily switches its effective UID to 0, and then switches back.



        Note that this is not really practical in a multithreaded program since the user ID is for a whole process, not per thread.



        For better robustness and security, implement privilege separation: split your program into two processes, one that runs as root and one that runs as a dedicated user. The process that runs as root should do as little as possible. It takes requests from the other process, validates them to the extent possible, and performs them. Then, even if the other process is buggy, the most it can do is issue valid requests.



        For simple needs, rather than write a program that runs as root, you may be able to have a sudo rule that directly allows the main program to run commands as a third user. Instead of relying on an intermediate root program to perform validation, you can embed the validation in the sudo rule, e.g.



        myapp_user ALL = (ALL:ALL) validate_and_run


        This allows myapp_user to run a command as any user, but the command has to be validate_and_run (with any arguments).







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Jan 23 at 23:08









        Gilles

        506k11910011529




        506k11910011529






















             

            draft saved


            draft discarded


























             


            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f419208%2fgive-a-user-privileges-to-switch-process-uid-gid%23new-answer', 'question_page');

            );

            Post as a guest













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay