2

I have some program called foo that needs root privileges when it executes. foo needs to be able to be run by any user and can be located at any path. The reason this program can be at any path is because our company is developing program foo and each user may have a personal version of the program in some personal directory while they work on it.

My question is this, what is the most secure way to handle this? I have been researching the sudoers file and have basically 2 ideas.

1.) List all paths the program can be at in the sudoers file. This is problematic because it requires frequent editing of the sudoers list and also still poses a security risk since non root users will own their individual copy of foo and could copy some system program over foo and then use it as root.

2.) Write a script called start_foo which performs some input validation on the passed program such as size and name and then starts the passed in foo. start_foo could live in /usr/bin and owned by root but runable by anyone. This option still includes the security hole of being able to write over the users foo program with another root requiring program but hopefully the size check would catch some malicious cases.

Is there a "cannonical" way to solve this problem I haven't found or thought of? If not which of the above or possibly other solution is the best way to handle the problem?

Thanks!

Improve this question
2
  • 5
    If you allow it to be in any path (a path writable by this non-root user) then you have virtually no security at all. What's to stop them from copying /bin/bash to foo and firing up a root shell? (nothing).
    – user143703
    Mar 3, 2014 at 20:53
  • Since your company is developing the application the most secure way would be to review the requirements of full root access for your application and implement the application properly. As it was properly pointed out in one of the answers, if your application really needs root access to something then it's better to implement a small secure daemon listening on a socket and handle requests from the unprivileged foo application there.
    – galaxy
    Mar 4, 2014 at 6:27

4 Answers 4

Reset to default
5

The most secure way to handle it would probably be to give each of your developers their own little dev/test environment, perhaps a virtual machine. That way, they can only break their own development instance.

Improve this answer
2

An obvious, and most secure, solution, would be to create a new privileged daemon application, food, that handles the things your foo app should do as root, and then the foo app communicates with food using eg. sockets (Unix, TCP). If your foo app gets compromised, the attacker would be able to only communicate with the food, which would have a limited command set.

If you trust your co-workers, you can add each of them to a unix-group foodevel, use solution 2), and then allow only executing the foo programs if they are owned by this group. A person belonging to a particular group can issue a chgrp command on files, another people won't be able to.

Additionally, you may check a sUID byte solution, instead of depending on sudo. This may not be well supported by each and every programming language and you need to know a bit about the effective permissions (check man seteuid).

Improve this answer
3
  • this is actually one of the first ideas that I considered but I couldn't figure out how to use sched_setscheduler() and mklockall() with a daemon program. I don't know of any way to have some daemon program change the scheduling or paging properties of the original calling process. Suggestions?
    – sandsaturn
    Mar 4, 2014 at 13:23
  • Research capabilities. Capabilities are enough of a root without a full root. man setcap can be of your interest. For sched_setscheduler() the required capability is CAP_SYS_NICE, for mlockall(), it's CAP_IPC_LOCK. You can also increase your limits in /etc/security/limits.conf (cf. man mlockall and man sched_setscheduler).
    – czaks
    Mar 4, 2014 at 14:21
  • I should add, that setcap is the SUID of the capabilities. You may still need to set effective capabilities though (I'm not fully aware of this topic).
    – czaks
    Mar 4, 2014 at 14:23
0

Maybe use a chroot jail of some sort. Possibly creating them on the fly as required with various files that the application needs to run.

Improve this answer
0

That presents a huge problem because then the user can EDIT the script at anytime. Even if the file is read-only, they will have write privs on the directory it is in.

For that reason, you need the root-priv script to be somewhere under your control

Can you do something like

/home/central/[scriptname] <---- root writable directory only, world readable. This one you can give sudo access to

Then /home/[anyuser]/scriptname <--- not sudo access

And scriptname is a wrapper for /home/central/[scriptname]

That would be better and more feasible

And /home/[anyuser]/scriptname would be something like 

#!/bin/bash
/home/central/[scriptname] $@    # pass all arguments
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .