March 5, 2009

S-bit set on the user

"With Linux processes run under a user-ID. This gives them access to all resources (files etc...) that this user would have access to. There are 2 user IDs. The real user-ID and the effective user-ID. The effective user-ID is the one that determines the access to files. Save the following script under the name idinfo and make it executable (chmod 755 idinfo).

#idinfo: Print user information
echo " effective user-ID:"
id -un
echo " real user-ID:"
id -unr
echo " group ID:"
id -gn

When you run the script you will see that the process that runs it gets your user-ID and your group-ID:

effective user-ID:
real user-ID:
group ID:

When Tux runs your idinfo program then he gets a similar output that shows the process now running under the ID of tux. The output of the program depends only on the user that runs it and not the one who owns the file.

For security reasons the s-bit works only when used on binaries (compiled code) and not on scripts (an exception are perl scripts). Therefore we create a C-program that will call our idinfo program:

int main(){
/*secure SUID programs MUST
*not trust any user input or environment variable!! */

char *env[]={"PATH=/bin:/usr/bin",NULL};
char prog[]="/home/alice/idinfo";
if (access(prog,X_OK)){
fprintf(stderr,"ERROR: %s not executable\n",prog);
printf("running now %s ...\n",prog);
execle(prog,(const char*)NULL,env);


Compile the program with "gcc -o suidtest -Wall suidtest.c" and set the s-bit on the owner:

>chmod 4755 suidtest
>chmod u+s suidtest

Run it! What happens? Nothing ? Run it from a different user!

The file suidtest is owned by alice and has the s-bit set where normally the x is for the owner of the file. This causes the file to be executed under the user-ID of the user that owns the file rather than the user that executes the file. If Tux runs the program then this looks as follows:

>ls -l suidtest
-rwsr-xr-x 1 alice users 4741 Jan 1 21:53 suidtest

running now /home/alice/idinfo ...
effective user-ID:
real user-ID:
group ID:

As you can see this is a very powerful feature especially if root owns the file with s-bit set. Any user can then do things that normally only root can do. A few words on security. When you write a SUID program then you must make sure that it can only be used for the purpose that you intended it to be used. Always set the path to a hard-coded value. Never rely on environment variables or functions that use environment variables. Never trust user input (config files, command line arguments....). Check user input byte for byte and compare it with values that you consider valid.

When a SUID program is owned by root then both the effective and the real user-ID can be set (with setreuid() function).

Set-UID programs are often used by "root" to give ordinary users access to things that normally only "root" can do. As root you can e.g modify the suidtest.c to allow any user to run the ppp-on/ppp-off scripts on your machine.

Note: It is possible to switch off Suid when mounting a file system. If the above does not work then check your /etc/fstab. It should look like this:
/dev/hda5 / ext2 defaults 1 1
If you find the option "nosuid" there then this Suid feature is switched off. For details have a look at the man-page of mount. "

No comments:

Post a Comment