Simple to code does not always mean simple for the user. And simple
for the user is often not easy to code.
By Daniel Hanson Sep 02 2004 03:51PM PT
I originally wanted to write a column about how the KISS principle
should really be Keep It Simple and Secure and why I thought BSD and
Linux had it right. The general consensus in the security world is
that, all else being equal, simpler software equates to secure
software. I have come to the conclusion that that this is a rather
trivial *cough* oversimplification of the problem.
I have no argument with the notion that large and opaque software is
likely to be more buggy, and where bugs exist, security holes can
usually be found. But what exactly is this notion of simplicity, how
do we define it, or perhaps, and who defines it? Simple code is often
not simple for the user, and an opaque user interaction experience
can create security problems, even though these security problems
can't be measured in a vulnerability/lines of code metric.
This balance between simple code and simple for the user has
important implications for every platform and the applications that
run on them. The growth in the various open-source Unix-like
platforms, whether they are desktop Linux or BSD server platforms,
mean that these same platforms have the most to gain or lose by how
they resolve this balancing act.
Simple code
In researching this article, the only conclusion I have reached about
analyzing code for simplicity and obtaining a resulting bug or
vulnerability count is that it's very hard to do. In fact, I have no
knowledge of any studies that have successfully compared different
software by complexity of code and bug count.
n my research, I came across all sorts of fascinating numbers and
discussions including the number of bugs per thousand lines of code
the average commercial programmer codes (0.5 according to wikipedia,
or many more according to other sources), the notion of cyclometric
complexity and how it relates to bugs (trivially more code branches
== more bugs), the different styles of measuring programmer
efficiency and a whole lot of other miscellaneous thoughts that will
sit unused in my brain for a short while.
In all of this, what bubbled to the top for me:
- in general, code that has a lower complexity is easier to
understand and maintain
- this leads to less security vulnerabilities
Additionally, there are a tremendous number of design variables that
can help this situation. The approach that many traditional programs
in the Unix world take is, "do one small task and do it well" and
"accomplish complex tasks by stringing together simple programs" to
keep complexity down. The use of standard libraries to avoid
reinventing functions, the object oriented approach to programming,
and appropriate language choices all help to contain complexity in
the underlying code.
Simple user
So if we can control the complexity in applications by using small
self contained programs, and link them together with pipes, what is
there to worry about?
While this approach works in certain environments, many people are
frankly intimidated by this approach. Would you ever run lynx -source
http://my.example.com/sourcecodeinstall.sh | sh ?
Even if I knew the http://my.example.com site, and trusted them, I
wouldn't do it, I'm too paranoid and I know what could happen. A
design that encourages users to do things "just because" with no
sanity check, or a design that causes surprise with the consequence
is a sure fire way to cause security problems on a system.
One of the best examples of a user design decision that has created
enormous security headaches can be found in the Windows world. If we
look at the history of file types, file extensions and the
explorer/shell interactions that result, we will see a history
littered with bad design decisions built on more bad design decisions
that continue to this day. In my opinion, one of the worst decisions
that Microsoft made was choosing to hide the file extension, which is
the only way a user can know what will happen when they double click
a file.
This decision, abused in various ways, has made socially engineering
a user into running a virus a far easier prospect. As things have
evolved, certain components of Windows have started interpreting what
to do with a file based on just the contents of that file, completely
ignoring the file extension. This is yet another monkey wrench thrown
at the user. Mix into this mess the notion of antivirus scanners only
checking certain files (based on file extension) and you have a
steaming pile of something that resulted because the evolution of DOS
needed a way of determining what to do with a file. Here we had a
simpler design for the initial programmer (look at the file
extension), but a far more complex user experience.
In a previous column, I was taken to task by Macintosh users for not
highlighting some of the incredibly well designed aspects of the
Macintosh platform. One of the areas that Apple gets very right, and
invests many resources to do so, is with the user experience. Very
few Mac users can claim to being surprised by the behavior of their
Mac in most situations. It makes it hard to run things as the root
user, it encourages different logins for different users, and in
general it leaves things turned off. While power users can sometimes
be frustrated because they don't have a "true" interface to an
underlying feature, novice users can be confident in what they are
doing. This leads us to the question: how much of their code overhead
and complexity is related to getting this interface just right?
Configuration files, installation of applications, management of
these applications, these are all things that an average
administrator on a Unix box must do, sometimes daily. Questions for
the security conscious administrator:
- Does the sendmail configuration file make it easy to know if you're
secure?
- Can the Open/FreeBSD ports installation tree allow easy upgrade
with detection of compromised packages?
- How does FreeBSD compare to Solaris, or Sun's Linux offering for
control of what services are running?
No simple solution
Perhaps we are moving towards a world where code complexity and the
resulting security vulnerabilities can be easily minimized while
maintaining the best user-interface approach for the task at hand. I
suspect that we continue to take baby steps, but I doubt we will ever
achieve this goal in any significant way. The amount of time and
energy required to make the right tradeoffs is too high for the
delivery deadline and adhoc nature that makes up most of the current
software development world. I fear where we will be when the current
code size of applications doubles, and the existing bug count
subsequently quadruples.
---
* Origin: [adminz] tech, security, support (192.168.0.2)
generated by msg2page 0.06 on Jul 21, 2006 at 19:04:05
search: