Hello again. The goal of
these first lessons is to show you how to
manage users and privileges in
the computing environment. Common security problems
occur when you give a user too many rights or
the wrong permissions. We will look at examples of poor privilege management
and how to fix them. Now, the goals of this part are to show you how
to manage privileges, because on a computer,
as you know, users have rights to
do certain things, and one of the problems
in security is what happens if you give
a user too many rights, or if you give them
the wrong permissions. In that case, they
can do things that you probably don't
want them to do. So there are three common areas
where this occurs. The first one is when you run
a program or sub-process. The second one is
when, for example, you need to give someone
privileges for a period of time. The third is when your
program is trying to identify which user is running it so you know what
privileges to give them, and we'll look at all of
these as we go along. Okay, now on a Linux system
and on many other systems, one of the big problems is, suppose a user needs
privileges temporarily, how did you do this? The way many systems do this is through a technique
called setuid. There, a program
is marked setuid. So normally when you
run the program, it runs with your privileges, but for setuid, it runs with
the owners' privileges. So for example, if a program
is owned by user root, and user Bishop runs it, if it's setuid, that process
has roots privileges. If it's not, it has
Bishop's privileges. Now setgid is similar
but deals with groups. Now, when a program runs, it runs in the environment
that I as the user has set up. That's also true for
setuid or setgid programs, which I'm going to simply
call privileged programs. The privilege programs run. They've given me
extra privileges, but I control the environment
in which they run. So unless the program is
sensitive to that and checks to be sure that
the environment is what it wants before it does things, it gives me extra information
or extra rights. Then the author of
the program may have made assumptions
that simply don't hold. In that case, I might
be able to manipulate the program to gain
additional privileges, or do things that I should
not otherwise be able to do. So when you are writing
one of these programs, or when you're reviewing it, where are the problems
likely to arise? Well, first of all, look at the program and
ask what it does. Does it change privileges? If it does, then once you
start doing is looking for places where the privileges
are necessary. These privileges should be given before that and dropped
immediately after, so the program doesn't retain those extra privileges
throughout its entire run. This ties into the principle of least privilege which says, "A process should only have sufficient privileges to carry out its task and no others." The same is true
with a program that starts up a sub-process. Sometimes the sub-process doesn't need all the privileges
of its parent. In that case, it should
drop those privileges. The third type of
program to look for is how does it identify
who's actually running it? This is a problem of
identity management. The reason it's important is, if Bishop is running
a program but the program erroneously
identifies the user as, say, Thomas, and the program will run
with Thomas as privileges, but Bishop will be running it, so he will be able
to do what Thomas can do and won't be able to
do what Thomas can't do. So that causes problems that
may give Bishop abilities, or restrain his abilities to
do what he's supposed to do. Now, you can look at the source code for the
programs, if you've got that. If not, what you can do
is look at the manual. Manual pages and
descriptions of how to use programs are great for looking for potential problems, because you look for what they say and what they don't say. When you have the source, as you go through the source, there are library functions and system calls that
are relevant here, and we'll talk about
those in a few minutes. You can use any sort of a
searching program to find them. If you don't have the source, then you have to look
at the executable, and the key there is to look for the functions or system calls
that the program makes. There are various ways
to do this. On the Linux system, for example, sometimes using the program nm will give you that information. It may not, but if the program symbol table is
stripped, then it won't. But you can also use strings
to find embedded commands, and here you look for commands that will be run
as a sub-process. If you're on other systems, there are similar mechanisms. Now, if a program is running, in addition to looking at the manual pages in the source
code if you have it, you can actually look at what the program
is actually doing. This has how many, for example, intrusion detection systems work. There are a number of
different programs to do this. On Linux, there are
dynamic debuggers, and there are also tracing
functions that will show you what system calls are made
as the program goes along. On other systems, you can
look at the log files, because they have
extensive logging capabilities. If those are turned on, often, those will show you in real time what the program
is actually doing. Now, if the program is
dynamically loaded, you can also use various programs to determine what dynamic libraries are
actually being loaded. It's very useful if those other libraries contain functions to change privileges, or to spawn children, or to find identity. But the standard ones, they're typically not as useful.