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.