[MUSIC]
And in this one,
we're going to talk about running subcommands, spawning subprocesses.
Now, why is this a security issue?
Well, many, many years ago, on a system that I worked on,
games were extremely popular, and all of them had what was called an escape.
So you would be playing your game, and if you wanted to do type commands,
you would then type a specific character.
And then you could just, it would give you a command interpreter,
and you could just do whatever commands you wanted.
The problem was people at this place were very competitive so
we had the high score files.
And in order to write to the high score file,
the game had to be a privileged user, in this case it was root.
Well one of the graduate students found out that when you spawned
the command interpreter the UID was not reset.
So, in essence to become root,
what you would do is find a game with a high score file, start up the game,
immediately type that character to get to that command interpreter and presto,
you're now the system administrator That was not good,
we'll talk about how to fix that in a moment.
It's not just games that have this problem, system programs did as well.
On one system, when the system crashed,
it would save memory in a core dump, of course.
And then you could use a program called crash to analyze the core dumps.
Crash was not privileged user, it ran as you.
However, in order to do the analysis, it needed to be able to read memory.
So to prevent a user from accessing things other than memory,
that the representation of memory was a file and
that file was owned by a group called kmem.
The crash program was run setgid to kmem.
So, it ran as for example, Bishop, but the group was kmem and
that group could read memory.
Same problem, when you spawned the subshell, it didn't reset the GID.
So I could then spawn a subshell, a command to interpreter, and
then I could go in and since kmem could write to memory, I could go in and
alter contents of the computer's current memory.
This includes my UID, I could change that to 0 and all of a sudden I am root.
Or I could look at what other people were typing, or I could
delete data from their program's memories, or you could alter their programs.
So that was a very serious problem.
The point is, identity is more than just the user,
it's also the group and you have to be aware of both of those.
The reason these problems arise is because when you spawn a program,
the privileges, or the rights, are preserved across that spawning.
For example, on Linux, the system call
to spawn a subcommand is some variant of exec, execve,
execvp, execlp, execl, whatever.
And that doesn't change the UIDs or the GIDs.
So if I'm running a privileged program and then want to run an unprivileged
sub program, my program has to do the resetting.
Now the way you typically do this is first of all you split the program,
you fork it into two processes.
The newly created process,
the child one, is still running with the program's privileges.
You use setgid to change the GID to something safe, then you use setuid to
change the UID to something safe, then you spawn the subcommand.
And here are some general guidelines.
If you're running a privileged program, UID or GID, the slide here
says UID, first of all, apply the principle of least privilege.
If you don't need a privilege, get rid of it.
Drop to the lowest level of privilege you need to complete your task.
And as I said earlier with the FTP example,
if you do need to upgrade privileges temporarily, use the saved UID idea.
So your program is running as root to do its task,
then you drop the privileges and change it, for example, to Bishops.
Now, the UID route saved as the saved UID and so
now I can flip back to that when I need it, when they need it.
A third rule of thumb, and this is critical,
don't allow users to run arbitrary programs from within privileged programs.
If you want them to be able to run programs like a command interpreter or
whatever, then drop privileges first.
Because if the users can run arbitrary programs,
you can't control what they're going to do.
Whereas if you drop privileges then the only thing they can do is
what they could normally do anyway.
The key point here is that you do the resetting
after you do the split, after you do the fork, and
do it unless it is absolutely essential to keep the privileges.
Now many systems of library functions that will do this sort of thing for you,
that would spawn subprocesses automatically.
On Linux the tool are popen and system.
On some versions of Linux, these will automatically drop privileges,
but on others they won't and I would not depend on it.
In general, avoid using those functions when you're dealing with privileged
programs Okay, so how should you identify users?
Well, there are a couple of system calls to do this.
If you want the real user, that is the identity of the user who's
running the program, use getuid, that gets you the real UID.
If you want to know the identity of the user who's privileges the program
is running with, use geteuid, that's the effective UID.
And now this next one is tricky, if you want to know who the user is logged in as.
Some systems in section two of the manual have a system
called call get login and you can use that.
But it's imperative you get the system call and not the library function because
the system call will give you the correct identity of the user who logged in.
However, the library function doesn't work that way.
The library function get log in, it lets you see
who is logged into the terminal that the standard input is coming from.
If it's getting input from a file then it looks to see
who is logged into the terminal where the standard output is going.
If that's going to something other than a terminal, it looks to see who is
logged in on the terminal where the error messages are going.
And if those are going in a file, then it will give you a null,
meaning it won't be able to figure out who has logged in.
But the point is who's logged in at the terminal or who's working at the terminal
may not be the person who is running the program.
And as a result of that, you may get the wrong identity or the wrong privileges.
cuserid is a variant of that, by the way.