SECURITY IN LINUX
10.7.2 Security System Calls in Linux
There are only a small number of system calls relating to security. The most
important ones are listed in Fig. 10-38. The most heavily used security system call
It is used to change the protection mode. For example,
s = chmod("/usr/ast/newgame", 0755);
so that everyone can run it (note that 0755 is an octal
constant, which is convenient, since the protection bits come in groups of 3 bits).
Only the owner of a file and the superuser can change its protection bits.
s = chmod(path, mode)
Change a file’s protection mode
s = access(path, mode)
Check access using the real UID and GID
uid = getuid( )
Get the real UID
uid = geteuid( )
Get the effective UID
gid = getgid( )
Get the real GID
gid = getegid( )
Get the effective GID
s = chown(path, owner, group)
Change owner and group
s = setuid(uid)
Set the UID
s = setgid(gid)
Set the GID
Some system calls relating to security. The return code
an error has occurred;
are the UID and GID, respectively. The param-
eters should be self explanatory.
call tests to see if a particular access would be allowed using the
real UID and GID.
This system call is needed to avoid security breaches in pro-
grams that are SETUID and owned by the root. Such a program can do anything,
and it is sometimes needed for the program to figure out if the user is allowed to
perform a certain access. The program cannot just try it, because the access will al-
call the program can find out if the access is allow-
ed by the real UID and real GID.
The next four system calls return the real and effective UIDs and GIDs.
last three are allowed only for the superuser. They change a file’s owner, and a
process’ UID and GID.
10.7.3 Implementation of Security in Linux
When a user logs in, the login program,
(which is SETUID root) asks for
a login name and a password. It hashes the password and then looks in the pass-
, to see if the hash matches the one there (networked systems
work slightly differently). The reason for using hashes is to prevent the password
CASE STUDY 1: UNIX, LINUX, AND ANDROID
from being stored in unencrypted form anywhere in the system.
If the password is
correct, the login program looks in
to see the name of the user’s pre-
ferred shell, possibly
, but possibly some other shell such as
login program then uses
to give itself the user’s UID and GID
(remember, it started out as SETUID root).
Then it opens the keyboard for stan-
dard input (file descriptor 0), the screen for standard output (file descriptor 1), and
the screen for standard error (file descriptor 2).
Finally, it executes the preferred
shell, thus terminating itself.
At this point the preferred shell is running with the correct UID and GID and
standard input, output, and error all set to their default devices. All processes that it
forks off (i.e., commands typed by the user) automatically inherit the shell’s UID
and GID, so they also will have the correct owner and group. All files they create
also get these values.
When any process attempts to open a file, the system first checks the protec-
tion bits in the file’s i-node against the caller’s effective UID and effective GID to
see if the access is permitted.
If so, the file is opened and a file descriptor returned.
If not, the file is not opened and
1 is returned. No checks are made on subsequent
calls. As a consequence, if the protection mode changes after a file is
already open, the new mode will not affect processes that already have the file
The Linux security model and its implementation are essentially the same as in
most other traditional UNIX systems.
Android is a relatively new operating system designed to run on mobile de-
vices. It is based on the Linux kernel—Android introduces only a few new con-
cepts to the Linux kernel itself, using most of the Linux facilities you are already
familiar with (processes, user IDs, virtual memory, file systems, scheduling, etc.)
in sometimes very different ways than they were originally intended.
In the five years since its introduction, Android has grown to be one of the
most widely used smartphone operating systems.
Its popularity has ridden the ex-
plosion of smartphones, and it is freely available for manufacturers of mobile de-
vices to use in their products.
It is also an open-source platform, making it cus-
tomizable to a diverse variety of devices. It is popular not only for consumer-
centric devices where its third-party application ecosystem is advantageous (such
as tablets, televisions, game systems, and media players), but is increasingly used
as the embedded OS for dedicated devices that need a
graphical user interface
) such as VOIP phones, smart watches, automotive dashboards, medical de-
vices, and home appliances.
A large amount of the Android operating system is written in a high-level lan-
guage, the Java programming language.
The kernel and a large number of low-