secure sudo configuration 3

[daFranze]

I have an application running on my servers (a data backup utility), which is administrated by some guys which have barely no UNIX know how. Most administration is done via a GUI but sometimes they need to edit files, watch logfiles or delete files within their application. I am thinking about confuguring sudoers to enable them the things they need to do. Since I am not an experienced sudo user I am thinking about some configuration pitfalls.

Host_Alias SERV_BACKUP = serv1, serv2, serv3
User_Alias BACKUPADM = user1, user2, user3

# can I limit them to delete files within their dir with this command?
BACKUPADM SERV_BACKUP = NOPASSWD: /usr/bin/rm /my/applicationdir/*

# how save is this? think about "sudo cat /my/applicationdir/mypasswd > /etc/passwd"
# can I prevent this by any option(s)?
BACKUPADM SERV_BACKUP = NOPASSWD: /usr/local/bin/less /my/applicationdir/*
BACKUPADM SERV_BACKUP = NOPASSWD: /usr/bin/cat /my/applicationdir/*

since the application is linked to the OS Filesystems (/var /etc /opt) a chroot environment might not be the best solution.
Any suggestions how to configure sudo save?

Best Regards, Franz
--
System Manager (Solaris, HP-UX, Linux, some networking, some SAN)

 

[Annihilannic]

Unfortunately the parameter pattern-matching facility in sudo rules is not very powerful, so it is difficult to prevent someone from running /usr/bin/rm /my/applicationdir/../../etc/passwd for example. In your case I would be more comfortable with writing a wrapper script that allows them to do what they need to do, but has hidden implementation (i.e. they can't view the script contents) so you can do your own validation of the parameters.

The sudo cat /my/applicationdir/mypasswd > /etc/passwd example you gave is not a great concern because the redirection happens in the non-privileged shell. I don't think it's possible to make a sudo rule with redirection, since it does not call a shell to interpret the command line.

Do they have to run these commands as root, or as another user that they don't normally log in to directly?

Annihilannic.

 

[daFranze]

Thanks Anni for your reply.
I found out myself, that the redirection is not performed in the privileged shell, so I don't bore about redirection problems.

to prevent the usage of things like /my/app/../.. I changed this to:
BACKUPADM SERV_BACKUP = NOPASSWD: /usr/local/bin/less /my/applicationdir/[!..]*
which works fine!

Do you have any suggestions to make it more secure?

>> Do they have to run these commands as root, or as another user that they don't normally log in to directly?

yes, they need to work as root, since it is a backup solution (hp Data Protector) and not as an unprivileged user.
Our "problem" is, that these guys do not have ANY experience in UNIX nether as a UNIX user nor as an UNIX admin. I don't want them to change any system settings without "our" permission or information.



Best Regards, Franz
--
System Manager (Solaris, HP-UX, Linux, some networking, some SAN)

 

[Chapter11]

Wrapper scripts are the way to go, with as much validation of parameters as you can do in a script.

sed s/"^[.\/]*"/""/g | sed s/"\.\.\/"/""/g

should strip any preceding . or /'s from whatever is fed to it, and also any occurrences of "../".

Ideally you don't even process user args directly, but use if/then or case statements to map them into legal values - this would be the way I do it, as I have to deal with exactly the same sort of issues.

 

[spamly]

I'd also agree with wrapper scripts. While sudo is a fantastic resource, it can be tricky to secure.

It does look like you've got the right idea about sudo configuration exploits and how to manage them though.

 

[daFranze]

Thank you for your assistance, for your help, for your time!

Best Regards, Franz
--
System Manager (Solaris, HP-UX, Linux, some networking, some SAN)