Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Re: Re: Executing Root Commands from user level

by arhuman (Vicar)
on Jan 18, 2002 at 20:36 UTC ( [id://139854]=note: print w/replies, xml ) Need Help??


in reply to Re: Executing Root Commands from user level
in thread Executing Root Commands from user level

I would not recommend this.

Some people already took some time to explain why SUID shell script can not be secure.
(In fact some OS simply forbidd them for that reason...)

Just my humble opinion although...


"Only Bad Coders Code Badly In Perl" (OBC2BIP)

Replies are listed 'Best First'.
Re: Re: Re: Executing Root Commands from user level
by Masem (Monsignor) on Jan 18, 2002 at 20:50 UTC
    True, a C-shell-based SUID script can be very insecure, though with a script this simple, all the user would have to do is make sure the PATH is set specifically. Or as the article states, this could also be done directly in perl, thus removing much of the insecurity overhead with Cshell scripts.

    However, at least IMO, I would think that being able to set one 'program' to be SUID for a specific group of users is better than allowing one user SUDO access, as the former is more specific about what you are allowing. Say the box is a web dev box, as it appears, and you have teammember Bob on it would does script developement; Bob, while compentent, isn't fully trustworthy at least to your team, but management says he needs to be able to change web server configurations and restart the http server for him to work. Allowing Bob SUDO access to the box could be very very bad, if he truly is a problem. On the other hand, allowing Bob into the access group that can run the apache restart program via a suid bit, means that the only damage he can effectively do (besides erasing config files) is starting and stoping the web server; the rest of the box remains secure. In addition, if Bob's account was broken into by someone more malicious than Bob, and BOB had SUDO access, you could kiss your box goodbye; limiting what can be done via suid programs will prevent a total compramise of the box.

    -----------------------------------------------------
    Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
    "I can see my house from here!"
    It's not what you know, but knowing how to find it if you don't know that's important

      Allowing Bob SUDO access to the box could be very very bad, if he truly is a problem. On the other hand, allowing Bob into the access group that can run the apache restart program via a suid bit, means that the only damage he can effectively do (besides erasing config files) is starting and stoping the web server; the rest of the box remains secure.

      Either I miss somthing either you ignore that sudo can be configured to grant precise/limited access to some prog.

      User_Alias WEBMASTERS = user1, user2, user3 User_Alias SYSADMINS = user3, user2 User_Alias DUMBUSERS = user4 # User privilege specification root ALL=(ALL) ALL WEBMASTERS www = NOPASSWD: /usr/sbin/apachectl SYSADMINS wiz = NOPASSWD: /bin/wiz DUMBUSERS blah = NOPASSWD: /bin/blah

      Here I allow user1,user2,user3 (WEBMASTERS's sudo group) to use apachectl
      Here I allow user2,user3 (SYSADMINS's sudo group) to use the ueber-elite /bin/wiz command
      Here I allow user4 (DUMBUSERS's sudo group) to use the /bin/blah (I really don't trust him ;-)

      If an intruder compromise the user4 account he can't do more than executing /bin/blah.

      Sudo offer tons of other features (ask for passwd, execute under other UID...).
      You really should give it a try...


      "Only Bad Coders Code Badly In Perl" (OBC2BIP)

        One of sudo's features that I like best is its logging capability. Sure, it's easy enough to build user logging into an SUID script, but with sudo you don't have to; it's already there. No points for guessing which method will lead to more logging being done.

        --
        :wq

        Ok, I've seen versions of sudo (maybe thrown together for a specific system) that lack the fine grained control that the modern versions of sudo appear to have, and that turned me off to the use of sudo in favor of other fine-grained solutions.

        But you and I both have the same message: security (in general, and in this case) means to only allow specific cases to be accepted, instead of denying general cases, as it's more likely to find a hole in those general cases that will break your security than in the former case. So if the original poster does use sudo, make sure to set up the sudo table as arhuman as indicated to make sure only those that need to restart apache have the ability to do so , and only that ability. And this would require no extra special script or the like, just the line that is above in the sudo configuration file.

        -----------------------------------------------------
        Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
        "I can see my house from here!"
        It's not what you know, but knowing how to find it if you don't know that's important

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://139854]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others scrutinizing the Monastery: (5)
As of 2024-03-28 17:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found