[MUSIC]
We're going to look at managing privileges here.
How do you do it right?
We've shown how to do it wrong, but what do we do to do it right?
Well, for that, there's several different ways to do it.
And in order to do that, I have to give some background on users and groups.
And then we'll talk about these setuid and setgid privileges, and
then we'll talk about jails and other restrictions.
Now, on a typical Linux system, there are four types of UIDs, at least.
The real user ID, which is whoever is running the program.
The effective user ID,
that's who the program runs, whose privileges the programs run as.
The audit UID, which is what gets written to log files, and it's typically the ID
of the user who first logged in, it's sometimes called the login ID as well.
And then we talked about the saved UID earlier.
Every process has those four UIDs associated with it.
So now, here's an example.
This is not privileged program, it's just a standard Linux program called doit.
When the user Holly runs it, all of those UIDs are the same.
Holly logged in, ran this program, so the audit or login UID is holly.
Holly is running the program, so the real UID is holly.
It's running with Holly's privileges, so the effective UID is holly.
And the saved UID is holly also.
Now, if you look at this output on Linux,
notice the s following the first rw,
this is output from ls-l.
That little s means that that setuid.
The owner is Matt, the group is sys.
Since it's a setuid, when Holly runs doit, it will run with Matt's privileges.
So the program starts up.
Now, the audit UID, again, is Holly because that's who logged in.
And the real UID is also Holly because that's the person running the program.
But the effective and saved UIDs are Matt,
so this program runs with Matt's privileges.
Again, with saved UID, we explained this earlier, but as a refresher,
the idea here is to provide a mechanism to limit privileges in accordance
with the principle of least privilege.
If you need privileges only for a short period,
you start the program up with those privileges and immediately drop them.
The effective UID reverts to whoever's running it, but
the saved UID becomes the UID of the person whose privileges you just dropped.
When you need them again, you simply issue a setuid call to change back to
the saved UID, and you'll get those privileges or rights back.
Here's how you get the UIDs, there's several system calls that will do this.
The FreeBSD comment after the getlogin system call there
is to emphasize that at least on FreeBSD, which is a variant of Unix which is
similar to Linux, the getlogin function there is a system call.
On some versions of Linux, it's also a system call, on others, it is not,
it's a library function.
And remember what we warned you about with library functions.
Now, to get the audit UID, sometimes you have to be root.
The reason for this is that on those systems,
the designers didn't want you to know whose
identity was being written into log files.
And the warning about getlogin is repeated here.
If you want to get the saved UID,
notice that earlier on there was no system call for getting saved UID.
In general, you can't get it directly,
you have to first of all use geteuid to get the effective UID.
And then when you change them, that old effective UID is the saved UID.
On a few systems, they have a system called very specifically that will return
the real effective and saved UIDs.
And on those systems, you actually can't get it directly.
Okay, so we've talked about getting them, how do you set them?
Well, there are a number of system calls to do this.
They are all analagous to the get versions,
just here they change it instead of getting it.
The one caveat is the function seteuid.
If you are root when you issue that, Then the real effective and
saved UIDs are all changed, so you have to be careful.
On the other hand, if you're not root,
then the effective UID is simply changed to the argument.
If you're root and you only want to change the effective UID,
then you have to use seteuid.
And that's normally what you would do when you are running as root and
want to drop privileges temporarily.
Because when you do the EUID, it saves the old effective UID.
And again, on some systems, you can change the audit or login UID if you're root.
And the specific reason for this is that when you log into a system,
the server you're dealing with is running its root,
it has to in order to give you the privileges you want.
But then if you couldn't change that, then everybody would be seen as root.
So the superuser, the root user,
the administrator can change that to the user who's logging in.
Now, if you want to get user names associated with UIDs,
there are a couple of functions to do this.
getpwuid is the main one, that actually takes an integer or user identifier,
integer UID, and looks up in the authentication database and
returns the associated information.
By the way, notice the line of code that begins with
user_name, this is an example of robust programming.
If I simply assigned up- >pw_name to user name, what
happens if there's no such entry in the user database corresponding to that UID?
Well, getpwuid returns null.
And then it'd be dereferencing a null pointer, and
that would cause, ideally, my program to crash.
If not, it would cause undefined behavior.
So that's why you do the check for null first.
You can use an if statement for this, this is a C conditional.
Similarly, if I have a user name and I want to get the associated information
including the UID, then I would use get pw_name.
And as I said earlier, if I want to get the login name,
then I might be able to do it with getlogin, assuming it's a system call.
If it's a library function, then this describes exactly how it works.
And here is another issue for you.
The authentication database on Linux systems
is a file and it's readable by everybody.
This includes the authentication information,
which is typically a hash password.
So the point is, even if it's readable, the user can't see what the password is.
And on other systems, in fact,
the actual authentication information is stored elsewhere, in a protected file.
Why couldn't you make the password file, the authentication database,
accessible only by root?
That would avoid you having to store the authentication information,
the hashes, in a separate file.
Think about that a bit while we go on to the next video.