A privileged program in Linux is one that has special access permissions (privileges) to use files or devices that are usually restricted. This can be done by either using the user ID of a privileged user (root based daemons fall into this category), or by a set user-ID-root (which gives the privileged program another identity effectively).
Privileged programs are a potential risk due to their use of restricted resources, and efforts need to be made to mitigate any potential misuse by someone with malicious intent.
A set-user-ID program can be made to only hold special privileges when it explicitly needs them. If the need for the privileges is only temporary, the program should be made to lose the privileges forever after its explicit purpose is served. For instance, if you want the program to drop its special privileges, add a line of code akin to:
The seteuid call described above will make the program drop its privileges and do the unprivileged work it needs to do. The way it works is that the program’s real ID is made its effective user ID. To restore the saved set-user-ID value back to the effective ID:
It will result in the program getting back its ability to do privileged work.
If, however, you’re done with the privileged work and want the program to lose its privileges permanently, add the following:
The setuid call described above will reset the entire set of existing user IDs.
You need to remember to drop all privileges before you start to execute another program, as there is a distinct chance that the second program will start with the existing privileges, making any step of reacquiring them redundant. This can be done by resetting all set-user-IDs to their real values before using exec(). Alternatively, calling setuid(getuid()) before exec() will help drop all privileges.
Often enough, a program with upgraded privileges gets access to sensitive parts of the system, like passwords, keys, etc. That makes it all the more necessary to erase any information that is likely to be misused. To rectify this problem, use setrlimit() and set the core Rlimit value to 0, to avoid core dumps.
In case the privileged program has been misused, and your sensitive information has been compromised, damage limitation is the only option left. One of the most useful techniques to secure your information would be to use a chroot ‘jail’. This technique essentially limits the scope of the rogue program, restricting its influence and access to a set number of files only. A malicious user may (intentionally or otherwise) also send random signals to a set-user-ID program. This means that the program needs to be configured to handle unexpected signals at any particular point in a program. Signal handlers need to be simplified and ‘race conditions’ must be avoided as much as possible.
Privileged programs can access system resources that are inaccessible to a normal user. If one isn’t careful, these programs can be misused and an entire system can be compromised. The strategy that needs to be adopted is simple: ensure that privileged programs are fully proofed against malicious intent, and damage limitation in case such programs have been compromised. After all, prevention is better than cure.