Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question
1  
I don't think passwd does call setuid() to drop privileges, but it does have the setuid bit set so that it will escalate privileges when executed. At least, that is the important thing to understand about passwd in this regard. –  goldilocks Feb 16 '13 at 12:32

2 Answers 2

up vote 5 down vote accepted

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

share|improve this answer
    
thank you, the last paragraph is the most valuable for me, but the explanation is very good, thank you –  flatronka Feb 17 '13 at 9:51

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.

share|improve this answer
    
thank you, basically this is the answer :) –  flatronka Feb 17 '13 at 9:53

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.