[kwlug-disc] Security arguments

[Paul Nijjar]

On Tue, Sep 22, 2009 at 06:42:25PM -0400, Chris Frey wrote:
> On Tue, Sep 22, 2009 at 02:38:04PM -0400, Paul Nijjar wrote:
> 
> Very good point.  But I don't think that programming well is easy,
> nor can it be made easy without some unforeseen cost.
> 
> A better way, in my view, is to make programming badly hard.
> 
> In other words, it should be impossible, or it should hurt, to make
> mistakes in programming.  But this sort of mentality isn't something
> most programmers like.  I think many programmers actively try to
> escape such constraints.

I think Perl's taint mode is a step in the right direction. In the few
web programming tutorials I have seen, they emphasize turning taint
mode on. That does not solve every problem, but it provides a means
for santizing input that is built into the language. 

I spent too much time thinking about this yesterday, and I think my
tentative position goes something like this: 

0. Everybody starts out as a newbie. 
1. Newbies make mistakes and (by definition) don't understand every
nuance of their programming/sysadminning environments. 
2. Therefore, mistakes will be made. 

This has some implications: 

0. If you expect your programmers and sysadmins to go through hoops to
make their code secure, then there will either be a lot of insecure
code or there won't be any newbies (so your language will die). 

1. Therefore, as much as possible you want sensible defaults that
avoid common security problems. 

2. In addition, as much as possible you want to limit the damage that
bad code does (at least by default). 


I think that Linux distros have learned these lessons the hard way. 
Now when you install Ubuntu there is no SSH server enabled by default,
and almost all ports are closed. I think that is sensible, because a
newbie has to worry less about stupid SSH worms. 

I think that we still have a long way to go in designing our tools so
that they have better defaults. That is not the same as dumbing them
down -- if I want to then I can still install an SSH server and open
all my ports. But in this case it costs me effort to disable the
default protections, which is aggravating but probably a better
policy. 

I think I am also re-evaluating the relevance of these "Windows vs.
Linux" comparisons. I still think that they miss the fundamental
point, but I think that they are a good way of identifying common
problems in software. They also give people who are evaluating
alternatives some information on which to base their comparison. As
such they are misleading (especially when written by zealots) but it
is better to have some basis for comparison than nothing. 


> You mention "C [vs.] programming languages that are not insane."  But in
> my view, once people stomped out buffer overflows by moving to PHP, they
> fell into the same trap of "make it easy" and got SQL injections instead.

That's true. It is still better than programming your webpages in C
and dealing with BOTH buffer overflows and SQL injections. 

> So it's left to each individual programmer to take responsibility for
> his own code, and make programming hard for himself: finding the best
> way to do a given task, and eliminating repetition.  This takes time,
> money, patience, and attention to every detail.

I think this means our software will always be bad. Either newbies
will be dissuaded from writing software (which is actually the
situation with me -- I am terrified to release code because I know
little about securing it correctly) or newbies will write code and it
will have bugs. 

I still maintain that the tools can do more the encode what we know
about security. That will not solve every problem, but if it gets rid
of the easy stuff then at least the Russian Mafia will have to be more
creative in finding ways to attack our systems. 

- Paul