setuid

You don't have to hang around Unix long to learn about "su" and setuid programs. The "setuid()" system call (and related calls like setgid) are what allows a process to switch back and forth between id's.

The kernel actually maintains three id's: the real user id, the effective user id, and the saved user-id. The saved user id is important and very useful in writing more secure programs.

Only a process that already has superuser power can change its real user id, and you often see setuid programs (the binary has had a chmod 4755 for example) owned by root so that the process has root capability when executed. But because of the saved user id, you don't necessarily have that effective id throughout: for security reasons, programs should switch you back to the saved id whenever having the more powerful id isn't necessary.

Take the example of a program that needs to open some database files, allow you to review and possibly change datam, and then write the files. Let's set the files for ownership by the "database" account:

# chown database:database datafile
# chmod 660 datafile
# chown database prog
# chmod 4755 prog
# ls -l prog datafile
-rw-rw----    1 root     database        0 Jan 19 08:13 datafile
-rwsr-xr-x    1 database tony        0 Jan 19 08:13 prog
 

When our "prog" is executed, its effective id will become "database", so it can read the file. When it is time to write the data back, it also needs the "database" effective id, but it doesn't need it in-between. So, ideally, the flow would go something like this:

• prog is executed. Real gid is you, effective id is "database". The saved user id is also "database". The program open the file and reads it into memory. It also saves the numerical database id.
• It now executes setuid(getuid()) to change the effective user id back to you. If you managed a shell escape at this point, you'd have no more power than you ever did: you couldn't read or write datafile.
• When it is time to write data, the program does a setuid(databaseid). The only reason that works is because of the saved user id: that was and is database, so the process is allowed to switch back to that. It can't switch to any other ids other than yours and that because it does not have superuser privileges.

The saved user id allows the program to shed its more powerful identity when it doesn't need it.

Comments?

More Articles by Tony Lawrence - Find me on Google+

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.