blogger templates blogger widgets
This is part of a list of blog posts.
To browse the contents go to

Modes and Permissions - setUID and setGID

setUID and setGID bit values make sense only on executable files. It servers no purpose on normal text files.

setUID
If setuid bit is set on a (executable) file it causes the program to run as it's owner, no matter who executes it.
  • Octal value is 4.
  • Symbolic notation is u+s.

setGID
If setgid bit is set on a (executable) file, it causes the program to run as a member of the group that owns it, no matter who executes it.
  • Octal value is 2.
  • Symbolic notation is g+s.

Note:
To set setuid/setgid bit that program must be group-executable or other-executable.
The Linux kernel ignores the setuid and setgid bits on shell scripts. These bits work only on binary (compiled) executables.

Both the above points are very important.
The first one is a requirement for setuid/gid to work. As a matter of fact, setting the setuid/gid are privilege modifications beneficial to anyone other than the owner of the file. The second point means that if a user tries to set it on a regular file or a script (exception are perl scrips), it sets the bit without showing any error message.
  • A uppercase S denotes that the directory is not executable and has the setuid bit set.
  • A lowercase s denotes that the directory is executable and has the setuid bit set.


eipe@eipe-system:~/share$ ls -l
total 12
-rwxr-xr-- 1 eipe dev 7 2010-12-12 16:39 lister.sh
-rwxr-sr-- 1 eipe egroup 3 2010-12-16 20:34 list.sh
-rwSrwSr-- 1 eipe egroup 22 2010-12-15 00:05 rfile


list.sh is a shell script which is group-executable and uid bit is also set.
But still when tom tries,

tom@eipe-system:/home/eipe/share$ ./list.sh
bash: ./list.sh: Permission denied


rfile is a text file (which is of course not executable) and it's uid bit is set.

tom@eipe-system:/home/eipe/share$ cat>>rfile
bash: rfile: Permission denied

To understand more about permissions let's look at the concept of user and group. A user or group ID represents the permission level. We could view it from 3 angles.
  1. Perception of the user: The user who has logged into the system. The id of this user is called the real user ID and his primary group is called real group ID.
  2. Perception of the file: A file created by any user associates permissions to it by assigning the permissions for owner (himself), group and others.
  3. Perception of the process: A process which is running has permissions attached to it just like in the case of a file. Commonly known as the effective user ID. Normally, when a user executes a file, the process which results in this execution has the same permissions as those of the user.


When a user executes a file, the process which results in the execution of the file gets the same permissions as those of the user. Within a system, it's the permission level on the process (effective user ID) that matters. Because that determines what the process is capable of doing.
Check out the tmp directory and the passwd and shadow file.

eipe@eipe-system:/$ ls -ld tmp
drwxrwxrwt 16 root root 4096 2010-12-21 22:52 tmp
eipe@eipe-system:/$ ls -l etc/passwd
-rw-r--r-- 1 root root 1734 2010-12-16 20:14 etc/passwd
eipe@eipe-system:/$ ls -l etc/shadow
-rw-r----- 1 root shadow 1379 2010-12-16 20:15 etc/shadow

The listing shows that passwd is readable by all, but shadow is unreadable by group and others.
Now how is that a user (other than the root) is able to change his password and other account information without having group/other write permission on both the passwd and shadow file.

Well, this is how Unix solves the problem.

eipe@eipe-system:/$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 37100 2010-09-03 15:58 /usr/bin/passwd

This is another passwd file that helps out other users. You can notice a 's' there. This represents the mode set-user-id (SUID). This let's the process have the privileges of the owner/creator (rather than the current user) during the instance of the program.

Thus when a non privileged user executes passwd, the effective UID of the process is not the user’s, but of root’s – the owner of the program. This SUID privilege is then used by passwd program to edit /etc/shadow.

Let's create a executable file that prints something useful. :-)

eipe@eipe-system:~$ cat /etc/passwd
eipe: x:1000:1000:Eipe,,,:/home/eipe:/bin/bash
tom: x:1001:1001:Tom,,,,:/home/tom:/bin/bash

Write the below c program and save it as printid.c
#include<sys/types.h> 
#include<unistd.h> 
#include<stdio.h> 

int main(void) 
{ 
    printf( 
        "Real       UID = %d\n" 
        "Effective UID = %d\n" 
        "Real      GID = %d\n" 
        "Effective GID = %d\n", 
        getuid(), 
        geteuid(), 
        getgid(), 
        getegid() 
    ); 
    return 0; 
}

eipe@eipe-system:~$ ls -l | grep printid
-rwxr-xr-x 1 eipe egroup 252 2010-12-22 15:45 printid.c
eipe@eipe-system:~$ gcc -o printid printid.c

eipe@eipe-system:~$ ls -l | grep printid
-rwxr-xr-x 1 eipe egroup 7249 2010-12-22 16:24 printid
-rwxr-xr-x 1 eipe egroup 252 2010-12-22 15:45 printid.c
eipe@eipe-system:~$ ./printid
Real UID = 1000
Effective UID = 1000
Real GID = 1000
Effective GID = 1000



Now tom logs in. (Better if done on another shell window)


eipe@eipe-system:~$ su tom
Password:
tom@eipe-system:/home/eipe$ cd /home/eipe
tom@eipe-system:/home/eipe$ ./printid
Real UID = 1001
Effective UID = 1001
Real GID = 1001
Effective GID = 1001


Now we set the suid bit on the file.


eipe@eipe-system:~$ chmod u+s printid
eipe@eipe-system:~$ ls -l | grep printid
-rwsr-xr-x 1 eipe egroup 7249 2010-12-22 16:24 printid
-rwxr-xr-x 1 eipe egroup 252 2010-12-22 15:45 printid.c


Again tom logs in.


tom@eipe-system:/home/eipe$ ./printid
Real UID = 1001
Effective UID = 1000
Real GID = 1001
Effective GID = 1001


Now we conclude that tom is able to run the file (because it's group or other-executable) and the program now turned into a process, get's all the privileges of eipe (because it's uid is set).
Most of the cases this poses a lot of security complications and so setuid is advised to be used very carefully)

Now lets change sgid.

eipe@eipe-system:~$ chmod g+s printid
eipe@eipe-system:~$ ls -l | grep printid
-rwsr-sr-x 1 eipe egroup 7249 2010-12-22 16:24 printid
-rwxr-xr-x 1 eipe egroup 252 2010-12-22 15:45 printid.c

Again tom logs in.

tom@eipe-system:/home/eipe$ ./printid
Real UID = 1001
Effective UID = 1000
Real GID = 1001
Effective GID = 1000

Similar to SUID, SGID also grants privileges and access rights to the process running the command, but instead of receiving those of the file’s owner it receives those of the file’s group.

When SGID is set on a directory it has a special meaning.

Files created in a directory with SGID set will inherit the same group ownership as the directory itself, not the group of the user who created the file.

We create a directory for our dev group - “devdir”.

eipe@eipe-system:~$ cat /etc/group
egroup:x:1000:
tgroup:x:1001:
dev:x:1002:eipe,tom

eipe@eipe-system:~$ mkdir devdir


Now we change the group of the devdir to dev.


eipe@eipe-system:~$ chgrp dev devdir
eipe@eipe-system:~$ ls -l | grep dev
drwxr-xr-x 2 eipe dev 4096 2010-12-22 17:51 devdir


We create a file and check it's group.


eipe@eipe-system:~/devdir$ cat>fileone
eipe@eipe-system:~/devdir$ ls -l
total 0
-rw-r--r-- 1 eipe egroup 0 2010-12-22 17:52 fileone


Now we set the dir's setgid.


eipe@eipe-system:~$ chmod g+s devdir
eipe@eipe-system:~$ ls -l |grep dev
drwxr-sr-x 2 eipe dev 4096 2010-12-22 17:52 devdir
drwxrwxr-t 2 eipe dev 4096 2010-12-16 20:34 share


We create a second file in devdir.


eipe@eipe-system:~$ cd devdir
eipe@eipe-system:~/devdir$ cat>filetwo
eipe@eipe-system:~/devdir$ ls -l
total 0
-rw-r--r-- 1 eipe egroup 0 2010-12-22 17:52 fileone
-rw-r--r-- 1 eipe dev 0 2010-12-22 17:54 filetwo


Now any file created within devdir get's it's default group as dev. If the directory is given group-writable then tom could also cd in and create his files which could be also in dev group.

No comments:

Post a Comment