Important security notes

Here are a few key points to keep in mind, with regard to security:

  • The use of setuid binaries, if poorly designed, is a security risk. Particularly and especially for setuid-root programs, they should be designed and tested to ensure that, while the process is in an elevated privileged state, it never spawns a shell or blindly accepts user commands (which are then internally executed).
  • You must check the failure case of any of the set*id() system calls (setuid(2), seteuid(2), setreuid(2), setresuid(2)).

Consider this pseudo-code:

run setuid-root program; EUID = 0
do required work as root
switch to 'normal' privileges: setuid(getuid())
do remaining work as non-root
[...]

Think about this: what if the preceding setuid(getuid()) call failed (for whatever reason) and we did not check? The remaining work would continue to run with root access, very possibly courting disaster! (See the sample code from the OpenSSH-portable Git repo for a real-world example of careful checking.) Let's take a look at the following points:

  • The setuid(2) system call is deficient in a sense: if the real UID is root, then the saved-set UID is also root; hence, you cannot drop privileges! Obviously, this can be dangerous for setuid-root applications and the like. As an alternative, use the setreuid(2) API to have a root process temporarily drop privileges and regain them later (by swapping their RUID and EUID values).
  • Even if you have system administrator (root) access, you should never log in as root! You could be (quite easily) tricked into running dangerous programs as root (hackers routinely use this technique to install rootkits onto a system; once successful, do consider your system compromised).
  • When a process creates a shared object (say a file), who will own it and what will the group be? In other words, what values will the kernel set in the file's inode metadata structure for UID and GID? The answer is this: the file UID will be the creator process's EUID, and the file GID (group membership) will be the creator process's EGID. This will have a subsequent effect on permissions.
We recommend that you, the reader, definitely read Chapter 9, Process Execution, as well! In it, we show how the traditional permissions model is flawed in many respects, and why and how you should use the superior Linux Capabilities model.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.147.103.234