Dana Epp wrote:

> .... I think they should be taught the powers and failures of C.

Your course sounds enticing. I'm tempted to sign up for it.

Your course should also make a clear distinction between security, 
safety, reliability and availability.
One can write secure code that is not safe and vice versa - and one can 
write reliable code that is not safe and vice versa - and one can write 
reliable code that is not secure and vice versa. Finally one can write 
code that is secure, safe, reliable but not robust and vice versa. In 
many instances the software requirements, design and implementation 
concerns for security, safety,  reliability and availability overlap.  
Safety ensures that bad things do not  happen. Security ensures that  
unauthorized access to information is not allowed. Reliability ensures 
that the system and its software  behaves as specified during a given 
interval of time.  Availability ensures that the system and its software 
are not unavailable for use for more than a given period of time. Higher 
availability is provided by failure tolerance to system and software 
failures and human error.

I suspect that C has a pervasive hold because a large amount of legacy C 
code exists. When modifying or enhancing existing C code one should use 
a safer subset either by enforcing coding standards like in Safer C or 
eliminating a large class of errors which are not allowed by some newer 
C compilers, e.g., Safe C and Cyclone. If I had my druders, instead of 
using C, I would chose Spark - the safer Ada subset which allows you to 
guarantee that there are no runtime errors.

But if you are stuck with C, you should consider adding the following 
book to the reading list in your security course. It provides an 
extensive list of all the shortcomings and hazards of C.
(1995) Safer C: Developing for High-Integrity and Safety-Critical 
Systems/ by Hatton, L. 
/http://www.oakcomp.co.uk/SCT_About.html  provides a corresponding 
toolset to be used with Safer C/
/<>
"The Safer C toolset goes to considerable effort to enforce the 
well-known MISRA C standard. The MISRA C standard was developed by a 
consortium of car manufacturers with the intention of introducing the 
notion of safer language subsets for programmable control systems in the 
auto industry."

There is also some interesting research to make C compilers safer but I 
have not had any experience using them:

http://www.cs.wisc.edu/~austin/scc.html
http://www.cs.wisc.edu/~austin/talk.scc/
<>SCC: The Safe C Compiler -SCC is an optimizing C-to-C compiler which 
implements the extended pointer and array access semantics needed to 
provide efficient, reliable and immediate detection of memory access 
errors in /unbridled/ C codes.

http://www.zork.org/safestr/ - Provides a safer string handling library 
for for Safe C.

http://www.research.att.com/projects/cyclone/ provides another safer C 
dialect. Here is a excerpt from their introduction:

"Cyclone is a language for C programmers who want to write secure, 
robust programs. *It's a dialect of C designed to be /safe/: free of 
crashes, buffer overflows, format string attacks*, and so on. Careful C 
programmers can produce safe C programs, but, in practice, many C 
programs are unsafe. Our goal is to make /all/ Cyclone programs safe, 
regardless of how carefully they were written. All Cyclone programs must 
pass a combination of compile-time, link-time, and run-time checks 
designed to ensure safety.

There are other safe programming languages, including Java, ML, and 
Scheme. Cyclone is novel because its syntax, types, and semantics are 
based closely on C. This makes it easier to interface Cyclone with 
legacy C code, or port C programs to Cyclone. And writing a new program 
in Cyclone ``feels'' like programming in C: Cyclone tries to give 
programmers the same control over data representations, memory 
management, and performance that C has."

Yours safely,

Jim Ronback
Tsawwassen, BC

Reply via email to