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.