Purpose of using setuid() in SUID programs

Question

I wonder that an SUID program like passwd why using setuid function call, why he drop root privilege? What types of attack is against(buffer-overflow)?

thanks for the answers

Answer 1

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 passwd.

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 setuid().

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).

Answer 2

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.