The first question is, are
you running with privileges? On many systems, there
is a system called issetugid that returns one if issetugid set GID
and zero if it's not. Some systems don't have that. If that's not present, what you can try
doing is comparing the real UID to
the effective UID. If the two don't match, then you're definitely setuid. If the two match, you
may or may not be. The question is, is the saved UID the same
as both of those? If it is, you're not setuid. If it's not, then you are, and you can do something
similar with the groups. So now, a few rules
about programming. The setuid program gives privileges for the life
of the process, and to all the descendants,
you can revoke them. But when you start off,
that's what you get. So the person who owns the program is the one with whose privileges
that program runs. So the owner of the program
or the programmer needs to constrain the environment to make sure that the point
of the program runs, any assumptions it
makes are minimal. The environment in
which the program starts is called the initial protection
domain. Excuse me. So the process as it starts
up from the setuid program. Setuid program must make
sure that when it starts, it knows what's in
the environment, then it's cleaned
out anything that it doesn't like or it's reset the environment that completely which is the better way to do it. So let's go back and take
a minute, and just review. Sometimes, this can
be very helpful. What is privileged? Well, here, what we mean is
simply is that a program runs with rights that it
would not normally have, and it doesn't have to be
administrative rights. For example, if you
have a Matt at Holly, and Holly is
a privileged program, and Matt runs it, that program will run with Holly's privileges. But Holly is not
the administrator, so there's a difference here. Now, some programs require that you change
this effective UID, as the program is running. A good example of
this is a program that allows you to
change privileges, the systems have these. On Linux, it's called su or sudo. So those programs
run as startup as the administrator because
only the administrator can change privileges
or change user IDs. Once it figures out what
the new user ID is, it drops the root privileges, and works with
the privileges of the user. So only root can do this thing. Now, some files
are owned by root, and some roots starts
up some programs. Setuid programs ordinary users startup,
but they become root. So what's the difference? Well, the key difference is this. When root starts something, root controls the environment
in which that process runs. So the administrator
can constrain that process and ensure that everything is set up properly. But with a program that adds privileges that
started up by a user, you can't make that assumption. Because the user may do
something with the environment that will cause the program to give it incorrect privileges. As a good example of this, one common trick to
get root privileges on Linux systems is to
do sudo /bin/sh, or /bin/csh, or whatever, or a bash that will give you a command interpreter running
with root privileges. If you do this, you need to make absolutely sure that you're running in roots environment
then not in your own. Because the user
environment is untrusted, and there are options to sudo an su that will allow
you to do that. So inferior list the difference between a setuid program
and root running a program is major
because you make the assumption that root or the administrator is not going to try to compromise the system. If root of the administrator
is going to try to compromise this system where
you think he or she might, don't worry about
secure programming, and you've got
much bigger problems. However, you can't make the assumption that
the user is not going to try to subvert the system because that's what attackers do. So in theory, it sounds major, but there's an old saying. In theory, theory and
practice are the same thing. But in practice,
they're different, and this is a good example. No administrator is perfect, administrators make mistakes. So if the program
is supposed to be run by root or by
the administrator, it should do some checking to be sure that the
administrator hasn't made a mistake in setting up the environment when the
program runs or in issuing the commands within the
program or the program itself. So in reality, always program
securely and robustly, it doesn't matter whether
the user is trusted, because even the most trusted
users can make mistakes. Let's go back to the
games program that I talked about in video 1. How do you fix that? Let's
look at how we would fix that. There are four
possible solutions. The first one is just
trust the users. Say, "Okay. Yes, you can become the administrator
when you play a game, but don't do anything about it. Okay. Just don't do that. Only do safe things." There are two problems with this. The first one is, yes, all you users may be
very, very trustworthy, but as you said in
the last a minute ago, users make mistakes. The second one is, there's an implicit
assumption in that, that no account is
ever compromised, and that the only people
who will ever use your system are
the authorized users. We found that not to be true. Systems can be
compromised very easily. Otherwise, why would we need to worry about
secure programming? So let's forget that one. The second one which
is probably the most appealing to a lot of people
is get rid of the games. I mean, the computers or their
peers or their to do jobs. Why you playing games? Well, the fact of the matter is people have tried that
and it doesn't work. People bring it on games, bringing games from the outside
or write their own. So let's ignore that
possible solution as well. There are two possible
remaining solutions, creating a restricted user
and a restricted group. If you're going to do
a restricted user, what we do is we
create that user, give it a restricted area
on the system, make all the high score files owned by that user and
writable by the user, and then make the game
setuid to that user. Now, we're in
this situation I described earlier where the game
runs with privileges, but not administrative
privileges. So when you spawn that sub-shell, you now have privileges of
the owner of the games. So if you want to delete
the high score files, you can. But you won't be able
though, for example, alter the time in the system and do other things
that we could do. The users can then delete
the games if necessary, but that would probably
became very unpopular. Creating a restricted group is actually a little bit
better in this case because group IDs or group privileges are
typically more restricted. So what we do is we create
a group called games and put all the high score files in an area that
games can write too, and make them writable by games, but not writable by anyone else. Now, if I spawn
the sub-shell, again, I can still delete
the files, but nothing else. If the games and
the programs themselves are unwritable by group
in the areas they're stored in our and
writable by group, I can't even delete the games. The high score file must be
writable by the group though. So the information in
there can be deleted. There's no way around
that, unfortunately. Which is better in general
to use setuid or setgid? Well, in general, setgid
is probably better. If you need to log in, you're going to have
to make it setuid. But otherwise, the setgid due to a quirk in administration is typically more
restrictive than a user. Also, logging and auditing
when you write log files, they typically use the UID
rather than the GID. So if an attacker does something, you're a little bit more likely to see it in the log file. Also, if the group is
compromised, again, the only thing they can do is whatever that group
can do and typically groups are privileges that
are much more constrained. This is an example of the
application of the principle of least privilege since groups have fewer privileges typically. Not always, but typically. That said, there are a couple of cautions that are
really important. The first one is that
just because it setgid, doesn't mean it's not dangerous. Setgid programs can
be very dangerous. It depends on what
that group can do. Second, if the administrator is running a
non-privileged program, well, the program
still running with the privileges of
the administrator. If the administrator
does something untoward or makes a mistake, boom. So just because the
program is not privileged, not setuid, doesn't
mean it's safe, it depends on who's running it. For example, I could
easily accidentally delete all my files by
running the command RM, remove or Del appropriately. To me, that's dangerous, and there's nothing to protect me. The administrator could
delete all my files. That program again, the deletion programs
typically unprivileged. But with the
administrator's privileges since the administrator
is running it, anybody's files could be deleted. The third one is
a technical point. When you set up
the environment in which this program is
going to be running whether you're doing it
as the administrator running the program or the program itself cleaning out its environment to make sure that it can't do
anything untoward, bear in mind that
the user and group identities are part of that
initial environment, and you wanted to make
those safe as well to give the program the least amount of privileges it has
in order to run. Again, this is simply an application of the principle
of least privilege. Let's move on to the next video.