Hey Jim,

All good points. I haven't seen that book and will have to see about grabbing it.


Jim & Mary Ronback wrote:

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


--
Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]




Reply via email to