[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20031028054438.GA19622@netpublishing.com>
From: ggilliss at netpublishing.com (Gregory A. Gilliss)
Subject: Coding securely, was Linux (in)security
Basically what I see here is 'the programming language is responsible
to keep the programmer from writing insecure code' versus 'the programmer
is responsible for keeping the code from acting insecurely'. Or, to put
it in more mundane contexts, 'responsibility lies outside of my control'
versus 'I am responsible for my actions'. Or, politically, liberal
democrat versus conservative republican (USA definitions).
Given the limitations of the hardware (and anyone who's ever had to BRS
their box understands, for the rest just take my word that the hardware
is the reason for the code, way way down deep, HAL and other modern stuff
notwithstanding), and given the expansive growth of the medium to include
people who would maliciously impact your system given the chance, I think
the honest answer to the questions "which should it be" is ... both.
Today no one person can know enough to prevent every single little
programming glitch. The history of software (and my career, and probably
some of yours', thank you very much) has as its foundation men (sorry
ladies) who by their very imperfections created code that was imperfect.
Yes, it helped when strong typing kept the programmer from overwriting
the character with an integer, or visa versa, but BITD assembler
programmers did very well without strong typing. So to be true I think
the answer is that the language can and should incorporate mechanisms
to assist the programmer in writing (a) working, (b) elegant, and
(c) secure code. However the programmers should be as well versed in
the art and science of programming as possible in order to fully take
advantage of the language.
Let us remember that the notion of security, in comparison to the notions
of (1) fitting the code into available memory, (2) getting the code to
run in the alloted time slice, and (3) getting the code to inter-operate
with other machines/networks/environments is a relatively young one.
AFA the 'C' language bashing, I'll not listen to it any longer. One
of my most favorite memories is having breakfast with Dennis Ritchie
during BSDcon, and it's thanks to K&R that you're not all writing your
insecure open source apps using Bill Gate's evil micro-COBOL or something
equally heinous. If you don't like the tool, make like Larry Wall and
write your own. We can always use more programming languages %-)
G
On or about 2003.10.28 17:44:55 +0000, Steve Wray (steve.wray@...adise.net.nz) said:
> Sure they could possibly find other ways to write insecure code,
> but the issue is not whether its possible; of course its possible.
>
> The issue is the relative difficulty of writing insecure code.
>
<SNIP>
>
> Can there exist such a language?? I reckon so.
>
> [huge snip losing all attributions and context]
> > So which makes more sense to you? To convert the world's
> > programmers to a new language? Or to teach them to code securely?
> Surely, if
> > we were to replace C today, they would just find other ways to write
> > insecure code?
> [snipped out all the rest]
--
Gregory A. Gilliss, CISSP Telephone: 1 650 872 2420
Computer Engineering E-mail: greg@...liss.com
Computer Security ICQ: 123710561
Software Development WWW: http://www.gilliss.com/greg/
PGP Key fingerprint 2F 0B 70 AE 5F 8E 71 7A 2D 86 52 BA B7 83 D9 B4 14 0E 8C A3
Powered by blists - more mailing lists