Locking down /etc/sudoers

[Colloid Snake]

Hello-

I am attempting to lock down a server that has been neglected for a few years, and while I changed most of the permissions to allow the specific group I needed, is seems there is a file that is scripted to revert its permissions to not allow any groups to edit it.

So I would like to set up /etc/sudoers so that this group can do anything they need, as long as it is within a certain directory. I think this involves the

%users /opt/directory = groupname

but I'm having trouble with the syntax of that, and the man page is just confusing me even more. Can anyone help me out with the syntax?

[prn]

Hi Snake,

I don't blame you for finding this confusing. It's not at all clearly written.

Here's an example from on of mine. I put the scripts that I want the relevant people to run in /usr/local/sudo (I have a pretty restricted set of people I want to allow so I don't need any more granularity than this) and so here's the "User privilege specification" section of my /usr/local/etc/sudo file (that's how mine is set up anyway):

# User privilege specification
root    ALL=(ALL) ALL
operator        ganymede=NOPASSWD:/usr/local/sudo/
helpdesk        ganymede=NOPASSWD:/usr/local/sudo/

Here, "ganymede" is the name of the host and I've granted both operator and helpdesk privs to run anything in /usr/local/sudo without entering an additional password.

Personally, I suspect that this is the most comon and basic sort of config you're likely to get. I just want these folks to be able to do some specific tasks without additional hassle. (Training them to do more can be problematic.) I've put /usr/local/sudo on their paths and they don't need to know much of anything except WHEN to do what they need to do.

By making the tasks scripts in a directory they have no other privs to (especially not write priv) all they can do is run what I give them.

YMMV.

HTH,
Paul

[Colloid Snake]

Oh, cool, that's a good idea.

So in the /usr/local/sudo/ are you copying over whatever is in /bin or /sbin ? Or are you symlinking?

I would like the users coming in to be able to sudovi a specific file, so I guess my question is more: how would you pass parameters in that case? I'm thinking it would just be in a shell script, and then put that into /usr/local/sudo/ . How does that sound?

Thanks

~Snake

[prn]

So in the /usr/local/sudo/ are you copying over whatever is in /bin or /sbin ? Or are you symlinking?

Actually, I do neither. I just have scripts in /usr/local/sudo.The scripts can call normal system command from /bin or /sbin, no copying or linking required. In fact, you would not want a copy or symlink of, e.g., rm to sit in /usr/local/sudo because then the users could rm anything anywhere.

I would like the users coming in to be able to sudovi a specific file, so I guess my question is more: how would you pass parameters in that case? I'm thinking it would just be in a shell script, and then put that into /usr/local/sudo/ . How does that sound?

By sudovi, I take it that you mean you want them to be able to edit a specific file that they do not otherwise have access to, right?

I would not give them access to use vi (or emacs or any other real editor) as root. That's a HUGE security hole. Here's a thought:

Create a (normal, non-suid) script. Put it somewhere in their path, e.g., /usr/local/bin. You can even call it sudovi if you like. That script does:

1. Call a script in /usr/local/sudo to make a copy of the file you want them to edit. (You can allow some parameter here, but if you do, check it carefully to make sure they are not editing something critical like /etc/passwd. :-) )
2. Let them edit the file as themselves with a simple call to their editor of choice. (I'd prefer to user a line like "$EDITOR $FILE" rather than "vi $FILE" if for no other reason than that I prefer alternate editors myself.)
3. Copy the edited file back to where it belongs.

Or, instead of copying, I'd probably rename the original to something like original.<timestamp> and then mv the edited file to original. That way you have a record of all the changes. I might even make the backups in the form original.<timestamp>.<us er> so you even have a record of who made which changes.

As usual, YMMV. A lot depends on who your users are and why you are doing what you are doing. What works for me may be very different from what works for you.

Best Regards,
Paul

[Colloid Snake]

I meant to hop on earlier and say thanks, but I got pretty busy, and as this wasn't considered a "pressing issue" by management, it fell by the wayside. I'll have to find the time to mess around with it, but thank you for the guidance, I'm sure I will be able to figure it out with the above in mind.

Thanks

~Snake