Re: [SC-L] Programming languages used for security

2004-07-10 Thread Crispin Cowan
Dana Epp wrote:
My what a week of interesting discussions. Lets end this week on a 
good and light hearted note.
Insert various analogies between programming languages and automobiles 
here :)

   * $MY_FAVORITE_LANGUAGE is like a $REALLY_COOL_CAR, while
 $YOUR_FAVORITE_LANGUAGE is like a Yugo.
   * $C_OR_ASSEMBLER_ITS_REALLY_THE_SAME_THING is like a thermonuclear
 missile, in that it is fast and powerful, but if you are not
 careful, you can give yourself an ouchie :)
Crispin
--
Crispin Cowan, Ph.D.  http://immunix.com/~crispin/
CTO, Immunix  http://immunix.com



RE: [SC-L] Programming languages used for security

2004-07-10 Thread Wall, Kevin
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, 

Re: [SC-L] Programming languages used for security

2004-07-10 Thread Dana Epp
My what a week of interesting discussions. Lets end this week on a good 
and light hearted note.

Admit it. We all know the most secure programming language is Logo anyways.
HLNIt's hip to be 'rep 4 [ fwd 50 rt 90]'/HLN
Laugh. Or the world laughs at you. Have a good weekend guys.
Crispin Cowan wrote:
David Crocker wrote:
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 agree completely that one language does not fit all. But that does not 
completely obviate the question, just requires some scoping.

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].
 

The above is the art of programming language design. Programs written in 
high-level languages are *precisely* specifications that result in the 
system generating the program, thereby saving time and eliminating 
coding error. You will find exactly those arguments in the preface to 
the KR C book.

Crispin

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



RE: [SC-L] Programming languages used for security

2004-07-10 Thread David Crocker
Crispin Cowan wrote:


The above is the art of programming language design. Programs written in
high-level languages are *precisely* specifications that result in the
system generating the program, thereby saving time and eliminating
coding error. You will find exactly those arguments in the preface to
the KR C book.


Whilst I agree that the distinction between specification and programming
languages is not completely clear cut, there is nevertheless a fundamental
difference between specification and programming.

In a programming language, you tell the computer what you want it to do,
normally by way of sequential statements and loops. You do not tell the computer
what you are trying to achieve. Indeed, current programming languages provide
hardly any means of expressing what you want to achieve; typically, the only
concession they make in this direction is an assert statement, which lacks the
expressivity needed (e.g. you can't easily use an assert statement to say that
an array contains the same objects that it did on entry to the current function,
but they are now arranged in ascending order).

In a specification language, you tell the computer what you are trying to
achieve, not how to achieve it. This is typically done by expressing the desired
relationship between the input state and the output state. The state itself is
normally modelled at a higher level of abstraction than in programming (e.g. you
wouldn't refer to a hash table, because that is implementation detail; you would
refer to a set or mapping instead).

The distinction becomes somewhat blurred when you assemble a program from
library classes, because you are relying on those classes to represent some data
without worrying about how they represent it, and calling their methods to
achieve some state changes without worrying about the steps they go through to
achieve it. Unfortunately, in the absence of precise specifications for those
classes, it sometimes happens that what is achieved by calling a method is not
quite what you wanted; or you may sometimes fail to meet the preconditions of
the method, resulting in a crash or exception.

My belief is that a software development language should be capable of
expressing both specification and programming. Most of the time, its users will
write the specifications and let a tool refine them to a program. Where a higher
degree of optimization is needed, the software developer can manually refine
parts of the specification to a program.

It is not difficult to extend such a language to be capable of expressing
expected behaviour as well. This paves the way for tools that attempt to prove
that the specification exhibits the expected behaviour (and that any manual
refinements are correct implementations of the corresponding specification).

In case anyone is wondering what this has to do with security, expected
behaviour includes things like array indices are always in bounds (i.e. no
buffer overflows no matter what input is provided), and the browser address bar
always shows the full URL of the current page.

David Crocker
Escher Technologies Ltd.
Consultancy, contracting and tools for dependable software development
www.eschertech.com






Re: [SC-L] Programming languages used for security

2004-07-10 Thread James Walden
Wall, Kevin wrote:
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.
 

Off the top of my head, I'd like some of the features you mentioned, like
   Garbage collection
   Static typing (with no auto conversions, but with type inferencing)
   Secure encapsulation
I'd also add a rich set of data types, including:
   Numeric types with restrictions as Larry Kilgallen mentioned earlier 
and unlimited precision types
   Strings
   Lists
   Arrays (bounds-checked)
   Associative arrays (aka hashes)
   Unions (as in ocaml, not C, which will also provide enumerated and 
boolean types)
   Functions (first-class functions)
   XML (like Xen)

I also want a taint checking feature like perl's, as a general purpose 
language has to communicate with external programs which don't share its 
data types, like web servers sending CGI parameter strings or databases 
receiving SQL query strings.

As for syntax, I want to be able to use functional, imperative, or 
object-oriented techniques as best fit my problem domain.

--
James Walden, Ph.D.
Visiting Assistant Professor of EECS
The University of Toledo @ LCCC
http://www.eecs.utoledo.edu/~jwalden/
[EMAIL PROTECTED]



Re: [SC-L] Programming languages used for security

2004-07-10 Thread der Mouse
 Programs written in high-level languages are *precisely*
 specifications that result in the system generating the program,

 Whilst I agree that the distinction between specification and
 programming languages is not completely clear cut, there is
 nevertheless a fundamental difference between specification and
 programming.

 In a programming language, you tell the computer what you want it to
 do, normally by way of sequential statements and loops. You do not
 tell the computer what you are trying to achieve.  [...]

This is really just arguing over what words should be used for creating
software using such languages.  You call it specification (versus
programming), others call it declarative programming (versus
imperative programming).

Personally, I think the latter is the more useful way of looking at it.
Complexity cannot, ultimately, be hidden; build a specification
language powerful enough to build a whole application and it will have
complexity enough that writing useful specifications in it demands the
kind of mental discipline that is usually thought of as programming -
and provides the same kind of capability for expressing error.  (The
errors will be at a higher level, because the language is higher level,
but they will occur if the thing being built is nontrivial.)

/~\ The ASCII   der Mouse
\ / Ribbon Campaign
 X  Against HTML   [EMAIL PROTECTED]
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B




RE: [SC-L] Programming languages used for security

2004-07-10 Thread Wall, Kevin
David Crocker wrote:

 Whilst I agree that the distinction between specification and
 programming languages is not completely clear cut, there is
 nevertheless a fundamental difference between specification
 and programming.
 
 In a programming language, you tell the computer what you want
 it to do, normally by way of sequential statements and loops.
 You do not tell the computer what you are trying to achieve.
[snip]
 In a specification language, you tell the computer what you are
 trying to achieve, not how to achieve it. This is typically done
 by expressing the desired relationship between the input state
 and the output state. The state itself is normally modelled at
 a higher level of abstraction than in programming (e.g. you
 wouldn't refer to a hash table, because that is implementation
 detail; you would refer to a set or mapping instead).

I'm sorry, but I don't quite see how this description sufficiently
delineates between declarative programming languages (such as
SQL, various logic and functional prog langs (Prolog, ML, Haskell,
Miranda, etc.)) from specification languages.

Do you consider them declarative programming languages and specification
languages one in the same? (Note: PLEASE, let's not turn this into a
discussion of language X is / is not a declarative programming
language, especially since the last time I used Prolog was in 1989
and the others I've only read about and/or wrote a few toy
programs. ;-)

My impression always has always been that a declarative programming
language is a high-level language that describes a problem rather
than defining a solution, but that pretty much sounds like your
definition of a specification language.

-kevin wall
---
Kevin W. Wall   Qwest Information Technology, Inc.
[EMAIL PROTECTED]   Phone: 614.215.4788
The reason you have people breaking into your software all 
over the place is because your software sucks...
 -- Former whitehouse cybersecurity advisor, Richard Clarke,
at eWeek Security Summit