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 ;-). > <<
