CMPE455 Lab 1 - Access Control
CMPE455 Lab 1 - Access Control
Contents
1
Example 18 .......................................................................................................................................... 13
Example 19 .......................................................................................................................................... 14
Example 20 .......................................................................................................................................... 14
Example 21 .......................................................................................................................................... 14
Example 22 .......................................................................................................................................... 15
Example 23 .......................................................................................................................................... 15
Example 24 .......................................................................................................................................... 15
Example 25 .......................................................................................................................................... 16
Challenge 1.......................................................................................................................................... 16
7. Command umask ............................................................................................................................ 16
Example 26 .......................................................................................................................................... 16
Challenge 2.......................................................................................................................................... 16
8. Set UID (SUID) ................................................................................................................................. 17
Example 27 .......................................................................................................................................... 17
Example 28 .......................................................................................................................................... 17
Example 29 .......................................................................................................................................... 18
Example 30 .......................................................................................................................................... 18
9. Writing a SUID program in C ........................................................................................................... 18
Example 31 .......................................................................................................................................... 18
Example 32 .......................................................................................................................................... 19
Example 33 .......................................................................................................................................... 20
Example 34 .......................................................................................................................................... 21
Example 35 .......................................................................................................................................... 21
Challenge 3.......................................................................................................................................... 21
Challenge 4.......................................................................................................................................... 22
Challenge 5.......................................................................................................................................... 22
Challenge 6.......................................................................................................................................... 22
10. Linux Extended ACLs ................................................................................................................... 22
Example 36 .......................................................................................................................................... 22
11. Conclusion ................................................................................................................................... 23
References .............................................................................................................................................. 23
2
Our lab material is based on [1]. Section 1 describes the task. Sections 2, 3 briefly introduce the most
important Linux commands and access control concepts. You will work with Fedora Linux‐based
operating system in the laboratories. Sections 4‐10 contain examples (prepared in Kali Linux (with
alex@lenovo in the screenshots) and Fedora (with linuxlab@asus in the screenshots) operating systems)
and challenges. Section 11 concludes the material.
1. Task
Read material below in line with running your own examples repeating Examples 1‐36
(screenshots) shown in the lab material (use your own user name instead of alex or linuxlab e.g “chmod
701 /home/your_username/”). There are Challenges 1‐6 expected to be solved by you. The lab shall be
done in groups. Each group prepares a report on the work done containing screenshots of your variants
of the Examples 1‐36, Challenges 1‐6 solutions, and explanations. Due date for reporting is on the lab
link0. You will run your examples and solutions and explain them answering the questions of the Lab
Assistant.
When we open the terminal, we see an image as above. “linuxlab” is our user name, "asus" after
the "@" sign is the name of the machine we use, and "~" means the user's home directory.
Same way, “root” is an username(which has all privileges on the system), “asus” is machine
name and “#” means we are logged in as administrator(root).
3
Sudo command ‐ The sudo command makes it easier to manage your Fedora system. Certain
commands in Fedora expect to be run only by a privileged user or administrator. The sudo
command lets you run a command as if you're the administrator, known as root. For instance,
“sudo chmod 666 somefile”.
Su command – switch user. For example, “su student” command can be used for switching
between current user and student user.
Ls command – lists directory contents of files and directories. For example, when run “ls
/home/linuxlab” command, contents of /home/linuxlab directory will be shown on terminal
window.
Cd command – changes the current directory. For example, “cd Desktop” command changes the
current directory to /Desktop directory. (in the same way, “cd ..” command can also be used to
return to the previous directory.)
Mkdir – This command creates a new directory. Example usage for creating a new directory with
name “myLabWorks”: “mkdir myLabWorks”.
Rm command – this command can be used for deleting some file or directories. For example, we
can delete the “test.txt” file with "rm test.txt".
4
3. Introduction to access control
Access control enforces authorization by determining and enforcing which actions are allowed. Some
terminology: a subject is an active entity taking actions, such as a user or program, and an object is the
(often passive) resource that can be accessed, such as a file or network resource. Access control
mediates subjects' access to objects by enforcing a security policy, limiting which actions are and are not
allowed. The policy expresses what is allowed, either formally or informally as a set of rules. An access
control mechanism is the code or thing that enforces a policy. An access control model is a way of
representing and reasoning about a policy or types of policy.
Example 1
File
path
5
Owner can Group can Others can The file has File File Files Last
read, write, read and read and this many owner grou size modif
execute execute execute names (hard is root p is (byt ied
links)
The meaning for a regular file (as is the case for /bin/ls, the first symbol is – (dash)):
● r: Read the contents of the file
● w: Change the contents of the file
● x: Execute the file as a process (The first few bytes describe what type of executable it is, a program or
a script)
For a directory (the first symbol is d):
● r: See what files are in the directory
● w: Add, rename, or delete names from the directory
● x: 'stat' the file (view the file owners and sizes), cd into the directory, and access
files within
● t (instead of x), AKA the “sticky bit”: write is not enough to delete a file from the directory, in this case
you also need to own the file.
The permissions for each file are stored in the file’s inode. An inode is a data structure in Unix
filesystems that defines a file. An inode includes an inode number, and defines the location of the file on
disk, along with attributes including the Unix file permissions, and access times for the file. View the
inode number for this file:
ls ‐i /bin/ls
Example 2
File type may be also l for links on the files (with the help of the links one and the same data can be
accessed using different file names linked to one and the same inode for hard links).
Example 3
6
Thus, we see that the both files share the same inode. Thus, change of one of these files will affect also
the other one.
Deleting one of the names simply decrements the link counter. Only when that
reaches 0 is the inode actually removed:
rm /bin/tmp/ls
Example 4
Permission denied! Interestingly, in this case as a normal user we can create the
link to /bin/ls, but cannot then delete that link since the sticky bit is set for the /tmp/
directory.
ls ‐ld /tmp/
Note the “t” in the permissions, and refer to the meaning described above.
Example 5
Example 6
7
Look through this information. Note that the output includes the access rights, along
with the last time the file was accessed, modified, and when the inode was last
changed.
The output from stat includes the format that the information is stored as, along with a more “human
readable” output. As we know, user accounts are referred to by UIDs by the system, in this case the UID
is 0, as the file is owned by the root user. Similarly, groups are identified by GID, in this case also 0. The
actual permissions are stored as four octets (digits 0‐7), in this case “0755”. This translates to the (now
familiar) human‐friendly output, “‐rwxr‐xr‐x”. For now we will ignore the first octet, this is normally 0,
we will come back to the special meaning of this later. Each of the other three octets simply represents
the binary for rwx, each represented as a 0 or a 1. The first of the three represents the user, then the
group, then the other permission. An easy and quick way to do the conversion is to simply remember:
●r=4
●w=2
●x=1
And add them together to produce each of the three octets. So for example, rwx = binary 111 = (4 + 2 +
1) = 7.
Likewise, r‐x = binary 101 = (4 + 1) = 5.
Therefore, “‐rwxr‐xr‐x” = 755.
cat /etc/passwd
8
Example 7
We see that /etc/passwd can be read every user. Let us now create a new user, student with password
student. We need for that task to use super user rights with the help of sudo. Rights of the users allowed
doing sudo (from sudo group) are enlisted in /etc/sudoers file
cat /etc/sudoers
Example 8
9
We see that sudo group users have the same permissions as root. Groups and their members can
viewed by
cat /etc/group
Example 9
We see that user alex belongs to sudo group as well as to adm (can monitor system tasks), cdrom (can
access CDROM), and dip (can use tools such as ppp, dip etc. to dial‐up connection) groups. A new user is
created by
10
Example 10
Example 11
11
Example 12
Enter a number of lines of content. Press Ctrl‐D when finished entering a “secret” (that others may see).
Your first aim is to ensure your “mysecret” file is not visible to other users on the same system. First
view the permissions of your newly created file:
ls –l ~/mysecret
Example 13
Example 14
Thus, the permissions are changed from 644 (rw‐) to 770 (rwxrwx‐‐‐) for /home/tmp/somefile when
using sudo command. Or you can make relative changes: u‐x would remove the owner (user) the ability
to execute the file. Example:
chmod u‐x /home/tmp/somefile
Example 15
12
Likewise, o+w would add other’s ability to write to the file
Example:
Example 16
Use chmod to give read‐write permissions to yourself to your mysecrets file and everyone else no
permissions to the file:
Example 17
cat /home/alex/mysecrets
Example 18
Create a file “~/myshare”, and grant everyone read‐write access. Test whether you have correctly set
permissions. Also give other necessary permissions to other users for finding file “~/myshare”.
13
Example 19
Create “mygroupshare”, grant only read access to everyone in your group. Test whether you have
correctly set permissions.
Example 20
Example 21
14
Create a new group mygroup using
Example 22
Example 23
Change back mygroupshare group to alex and give alex group only read access to mygroupshare:
Example 24
Create a new group called “staff”, and create a file that you and a fellow classmate
(other user) can collaborate on (both edit). Test whether you have correctly set permissions. Both users
should be able to edit the file, yet other users should not have write access.
15
Example 25
Challenge 1.
mkdir test
touch test/test1 test/test2 test/test3
Use a single chmod command to recursively set the permissions for all files contained in the new “test”
directory.
Hint: “man chmod”
7. Command umask
Remember that our newly created file started with permissions that meant that everyone could
read the file. This can be avoided by setting the user file‐creation mode mask (umask) . Every process
has a umask: an octal that determines the permissions of newly created files. It works by removing
permissions from the default “666” for files and “777” for new executables (based on a logical NOT).
That is, a umask of “000” would result in new files with permissions “666”. A umask of “022” (which is
the default value) gives “644”, that is “rw‐ ‐r‐ ‐r‐”. The umask system call can be used to set the umask
for the current process.
Check the current umask value:
umask
Example 26
Challenge 2.
Using the umask builtin command, set your umask so that new files are only rw
accessible by you (but not to your group or others):
umask XXX
where XXX is the new umask to use.
Test your new umask value by creating a new file and checking its permissions:
touch newfilename
ls ‐l newfilename
Do the permissions read “rw‐‐‐‐‐‐‐”? If not, change the umask and try again.
16
8. Set UID (SUID)
Sometimes a user needs to be able to do things that require permissions that they should not
always have. For example, the passwd command is used to change your password. It needs read and
write access to /etc/shadow. Clearly not every user should have that kind of access! Also, the ping
command needs raw network access... Again not something that every user can do. The Unix solution is
set UID (SUID). Using SUID, processes can be given permission to run as another user. For example,
when you run passwd, the program actually runs as root (on most Unix systems). In fact, every process
actually has multiple identities, including:
● The real UID (RUID): the user who is running the command
● The effective UID (EUID): the way the process is treated
Example 27
The “s” in the file permissions means that the file UID will be used as the effective UID. Run
stat /usr/bin/passwd
Then switch to another user (bob) and run passwd
Example 28
Digit 4 in the octet permissions 4755 means that the file will be executed with UID=root. Thus, the SUID
bit is stored in the first (user) permission octet in the inode.
Viewing the processes running from another bash tab with
ps –af
17
Example 29
Example 30
Example 31
18
Remember, vi is modal. Press “i” to enter insert mode, then enter this code:
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
#include <errno.h>
int main()
{
printf(" UID GID \n"
"Real %d Real %d \n"
"Effective %d Effective %d \n",
getuid (), getgid (),
geteuid(), getegid());
FILE *fp = fopen("mysecrets", "r");
if (fp == NULL) {
printf("Error: Could not open file");
exit(EXIT_FAILURE);
}
char c;
while ((c=getc(fp)) != EOF) {
putchar(c);
}
putchar('\n');
return EXIT_SUCCESS;
}
Example 32
Save your changes and quit (Esc, “:wq”). You may use any other text editor (e.g., editor):
19
Compile the program (which uses the C code to create an executable):
gcc accessmysecrets.c ‐o accessmysecrets
Example 33
20
Example 34
Note that the program outputs its real and effective identity.
Change to another user, and execute the program:
/home/yourusername/accessmysecrets
Example 35
Note that the effective ID is that of the owner of the program. You should also see the
contents of the mysecrets file, even though you don’t have access to the secrets file
directly.
Challenge 3
Switch to another user and use the SUID accessmysecrets program to
get read access to any one of the owner user’s files!
Hint: there is a security problem with this code.
Another hint: think about hard links.
Solution:
There is a security problem caused by not using an absolute filename when opening
the file, it opens “mysecrets” rather than “/home/user/mysecrets”. Remember, any
user can create a hard link to a file (therefore they can make a “copy” of the SUID
program wherever they like).
Make a hard link to the SUID program in a directory that the attacker can write to,
then also make a hard link to any file the SUID user owns, and name it “mysecrets” in
the same directory as the program, then when you execute the program it will write
out the contents of the file.
You can exploit this vulnerability as follows:
su ‐ student
ln /home/user/accessmysecrets /tmp/access
ln /home/user/someotherfile /tmp/mysecrets
/tmp/access
21
Challenge 4
Modify the program to correct the above vulnerability.
Challenge 5
Modify the program so that only the first line of the mysecrets file is
displayed to others.
Challenge 6
Modify the program so that the script checks the UID and only continues
for a specific user (for example, if the user is root).
Hint: “man getuid
Example 36
22
11. Conclusion
At this point you have:
1. Learned about file permissions, hard links, and inodes
2. Learned about octal representations of permissions
3. Changed Unix file permissions to grant access to specific users and groups, using chmod
4. Used umask to change the permissions applied to new files
5. Learned about Set UID (SUID), become more familiar with C, and compiled a SUID C program
6. You may have also done some more programming of your own
7. Used Linux Extended ACLs to configure more advanced security policies
Well done!
References
1. Z. Cliffe Schreuders. Access controls and Linux/Unix file permissions,
z.cliffe.schreuders.org/edu/ADS/Access%20Controls.pdf
23