lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ