What is Secure Programming?
The term Secure Programming is used a lot these days and
it seems to be a coverall for
anything that's badly written.
Well, if it's badly written,
it's not secure programming.
In a sense that's true.
But the problem often is not one of security.
If for example, your program
crashes and I don't get any extra privileges,
then the program would be said to be not robust.
But depending on the specific policy,
it might not be secure.
It might be perfectly secure.
As another example, say a program
I write has a buffer overflow in it.
I exploit that buffer overflow.
I am therefore able to get
access to my own account through
that buffer overflow because
the program does not escalate privileges.
That's not a security problem because
I'm authorized have access to my account.
But it's certainly a robustness problem because
they got the program to do
something that it shouldn't do.
So, a lot of this course is
aimed at robustness as well as security.
Because if program is not robust,
it's not going to be secure.
On the other hand, if it is
robust whether or not it poses
a security problem depends a lot on
the context in which it's used and
we'll talk about that as we go along.
We're also going to talk a little bit
about where policies and procedures fit into this.
We often speak of a system or
a program as being secure or non-secure.
That's actually lagging the truth a little bit.
It is the program or the system plus
the procedures under which it's
used that determine whether or not something is secure.
As an example, if I have
a mathematically provable system
that is mathematically proven to be secure,
and I don't supply any passwords
and hook it up to the Internet,
that's a procedural issue and it is not secure anymore.
On the other hand, if I have a system that
has vulnerabilities when you
try to come in from the Internet,
so people could break it over the network.
But my policies and procedures never allow it to
be hooked up to the network and it
never is hooked up to the network.
Then people coming in over the network will be able to
get access to it and so they can't exploit anything.
So, bear that in mind as we go through.
It's not simply is the program secure?
It's is the program in the environment in which
I'm using it and with
the procedures I'm following secure?
That's the key question here.
Now, on the next slide,
there are two key concepts.
I mentioned privilege before.
When you log into a system,
you are given certain rights or privileges.
I'm using the two terms here synonymously.
If everything you do is at that level of privilege,
then the only security threat
you pose is to your own account.
But if you run a program that does
escalate privileges even if only for a little time,
for example, you become admin or root,
the program access admin or root
during that small period of execution.
Then if I can somehow extend that period of
execution or cause the program to do
things it shouldn't during that period of execution,
I gained those extra privileges.
The other term we're going to talk about is
protection domain and basically
that's simply a term meaning
everything the program can access,
everything that it can do when it does those accesses.
So, if I can read a file,
my protection domain includes
that file plus the read write.
If I can alter a file,
my protection domain includes that file
plus the altered or write write.
Now, in general as you'll see,
we would like to keep the protection domain is
smallest possible for each process.
Because that way it limits
the damage their process can do if it's corrupted.
Again, we'll get into this more in a little bit.