I wonder that an SUID program like
passwd is using the
setuid() function call. Why does it drop root privileges?
Against what types of attack does this help? Buffer-overflow?
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.Sign up to join this community
First I'll discuss the setuid bit, which passwd uses and is distinct from the
setuid() system call (which passwd does not use). There is perhaps some confusion in the question in this regard.
It is not a protection against a buffer overflow, it's vunerable to such, or basically anything which would allow an attacker to use a privileged process for some nefarious unintended purpose. This is because the setuid bit is the opposite of "dropping privileges"; it bestows root privileges, but only to the process and not the actual user. That includes
That form of setuid requires the filesystem setuid bit set on the executable;
passwd has this because it needs privileges to read and write
/etc/passwd. However, we hope passwd does not have any known security vulnerabilities (eg, potential overflow exploit) that would allow a nefarious person to get it do something other than reading and writing /etc/passwd (and other than doing that properly!), since it does run as root, and therefore could do anything -- except it is designed to do only one specific thing, and getting it to do anything else should (again, hopefully) be impossible.
So using setuid in that sense is not protection against anything, but it is often discussed in relation to vulnerabilities because potential vunerabilities are very important WRT setuid executables.
BUT: the setuid bit sets the euid and not the actual uid, so it is actually parallel to the
seteuid() system call and not
There is an opposite form of "setuid" that is about dropping privileges, which involves the actual
setuid() system call and does not require the setuid bit. This is when a process running as root (because root or sudo started it) changes its uid to a less privileged user. Servers and daemons often do this if they need root privileges at start up (eg, to open a privileged port) but not subsequently. That way if the server subsequently gets jacked, it does not have superuser privileges. You cannot call
setuid(0) and get root privileges back (but you can with set*e*uid).
It's simply a preventative measure. Any app could potentially be vulnerable to any exploit conceivable if miscoded. The trick to reducing the possible damage is to perform actions with the least privileges required. Dropping running as root when not needed is an excellent start.