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.