RE: Programming languages used for security

["Wall, Kevin" <Kevin.Wall () qwest com>]

David Crocker wrote...

> I think there are two other questions that should be asked before
> trying to answer this:
>
> 1. Is it appropriate to look for a single "general purpose" programming
> language? Consider the following application areas:
>
> a) Application packages
> b) Operating systems, device drivers, network protocol stacks etc.
> c) Real-time embedded software
>
> The features you need for these applications are not the same. For
> example, garbage collection is very helpful for (a) but is not
> acceptable in (b) and (c).  For (b) you may need to use some
> low-level tricks which you will not need for (a) and probably not
> for (c).

I did not mean to imply that a *SINGLE* general purpose programming
language be the optimal, end-all, be-all solution for all software
problems. Rather, I was trying to understand what would we, as security
professionals, find useful in a programming language in terms of specific
feature sets, etc. (At this point, I don't even want to particularly
discuss syntax and semantics, although I would argue that these things
do have an impact on secure coding as well.)

The very reason that I stated "a GENERAL PURPOSE programming language"
rather than just "a programming language" is I didn't want the
discussion to digress into fine grained application areas such as
"for web applications, you need features F1 and F2, but for
programming firewalls, you want features F1' and F2'", etc.
For any given application area, I'm of the opinion that you can
design an application specific prog language that will be better
suited and likely offer more security than you can in the general
case. However, this is usually just not practical, which is why we
have other mechanisms to extend the basic functionality of programming
languages (usually application specific libraries). (Of course,
sometimes the language itself goes beyond that; for example Prolog
offers its "Declarative Clause Grammar" form which is great for parsing.
And Forth can be used or abused almost ad infinitum.)

My vary reason for posing these questions is to see if there is any
type of consensus at all on what mechanisms / features a language
should and should not support WITH RESPECT TO SECURE PROGRAMMING.
For example, you mentioned garbage collection. To that I would add
things like strong static typing, encapsulation that can not be
violated, very restrictive automatic type conversion (if allowed
at all), closed "packages" or libraries or some other programming
unit, elegant syntax and semanatics (oops, said I wouldn't go
there ;-), etc.

In the past few days (actually, all through my career), I've hear a
lot of gripes about what people think is wrong regarding languages,
but little in terms of what they think is valuable.

> 2. Do we need programming languages at all? Why not write precise
> high-level specifications and have the system generate the
> program, thereby saving time and eliminating coding error?
> [This is not yet feasible for operating systems, but
> it is feasible for many applications, including many classes of
> embedded applications].

Well, I guess I'd argue that this is _somewhat_ irrelevant. If you are
proposing something like Z or VDM, than that in essence becomes your
programming language for all practical purposes. How it's translated
to machine code is not what I was trying to get at. IMO, I think that
formal programming languages have their place, but given that 95%
of programmers are weak in formal proofs, they are likely to be at
least as error prone as more conventional programming languages for
all but a select few.  So, if you wish, you can rephrase my original
question from "general purpose programming language" to "general
purpose high-level specification method". In either case, what would
you like to see to specifically support writing secure software?
(Obviously, the details will vary at spec methods vs. traditional
prog languages as you are working at different levels, but I think
my questions could be generalized / extended to deal with specifiction
languages as well.

-kevin wall

> David Crocker, Escher Technologies Ltd.
> Consultancy, contracting and tools for dependable software development
> www.eschertech.com
>
>
> Kevin Wall wrote:
>
> > >
>    If a GENERAL PURPOSE programming language were designed by
>    scratch by someone who was both a security expert and
>    programming language expert, what would this language (and
>    it's environment) look like?
>
>    More specifically,
>
>       + What set of features MUST such a language support (e.g.,
>         strong static typing, etc.)?
>       + Perhaps just as importantly, what set of features should
>         the language omit (e.g., pointer arithmetic, etc.)?
>       + What functionality should the accompanying libraries support
>         (e.g., encryption, access control, etc.)?
>       + What would be the optimal paradigm (from a theoretical, rather
>         than pragmatic perspective) that such a language would fit into
>         (e.g., object-oriented, functional, imperative, logic
> programming,
>         etc.)? [Note: I mention "theoretical, rather than pragmatic" so
>         that such a language would be unduly influenced by the fact that
>         presently developers familiar with OO and imperative styles
> vastly
>         out number all the others, with functional coming up a distant
>         3rd.]
>       + (Related to the previous item) Would such a language be compiled
>         or interpreted or something in between.
>
> Also, if anyone chooses to discuss these issues, let's leave things like
> portability and performance out of the equation UNLESS you feel these
> things directly have an impact on secure coding. I think that we can
> all agree that we'd desire a portable and fast-executing language
> (although perhaps a slow-executing language would be more secure in
> that it might slow down the propagation of malware ;-).
> <<