Hi all,

My first post. Would like to get everyone's opinion on something.

Here's a hypothetical situation regarding a hypothetical commercial application:

1. The application is intended for use by normal users.
2. The application must run in a non-interactive mode (for scripting and such).
3. The application has to run as ROOT to do it's thing.
4. The application calls various standard system utilities that are not a part of the application package.

Normally, I would expect that the system utility files that are called are not world writeable.

So here's the question(s):

Does the application have any responsibility for ensuring that it isn't going to potentially be the path to privilege escalation? If so, what would you do within the app?

Thanks!

Hello and welcome to LQ.

To me, numbers 1 and 3 are conflicting. If the program needs special privileges to do a certain task (for example, bind to a port number less than 1024), I would suggest there are a few ways to minimize possibility of privilege escalation within the program (and yes, I think it is the “responsibility” of any app that needs special privileges to minimize the chance that it would be used for privilege escalation):

1. Run initially as root. Do what you need to do (e.g., bind to low port) as early as possible, and then change user.
2. Run initially as root. Change to a “normal” user, while keeping whichever POSIX capabilities are required.
3. Run initially as a non-root, dedicated user. From within your application, execute a helper application (i.e., fork()/exec()) through sudo (your dedicated user should be given permission to run this and only this helper application as root in the sudoers file). This helper application will have the sole purpose of granting your process a special POSIX capability.

Among those, number 1 is the most commonly used. This is probably because it is more “portable” (POSIX capabilities and sudo are not found everywhere). Number 3 is the most “secure” (IMHO), since the only application running as “root” is the helper, which should be small and easy to maintain/audit. Of course, some capabilities are more valuable than others, and perhaps hijacking the application with a certain capability is privilege escalation enough for some purposes. In that case, there might be an optional step for numbers 2 and 3 that involves dropping capabilities after “doing its thing” (perhaps with the help of a helper application).

P.S., notice the lack of an apostrophe in my use of “its”.