Re: Software Design (was: Re: [tlug] Confessions of a closet OpenBSD user)

[Uva Coder <uvacoder@example.com>]

On Sun, Jun 30, 2002 at 02:38:13PM -0400, Josh Glover wrote:
> Viktor Pavlenko wrote:
 
> I am not sure I follow, Uva? Are you saying that elegance does not 
> matter, or that code can appear to be inelegant and really be elegant?

No, here's an analogy. If you are a bridge builder and the basic
fundamentals your bridge design are flawed, then the plans should
be sent back and revised. Entrusting that the bridge builder has the
talent to build an elegant bridge doesn't matter if the bridge may
eventually collapse due to poor design. To sit and blame the bridge
building techniques doesn't sit well with me. I believe the problem
actually lies in design, and not the construction. 
 
> I mean, a webserver exploit is now a kernel exploit. That is *so* much 
> worse than even a root exploit!

This has become something simuliar to discussing theology; there is
so much based on long established standards and thoughts. 

The current trend in trusted OSes has been to reduce the capabilities
of the root user, and disseminate the power across several users. I've
seen this in trusted versions of Linux, Solaris, and HP-UX. I believe
that this fundamental idea behind this is flawed. So what are the
the alternatives? One solution is to get rid of the root user
all together; well, that is what Bell-Labs did in Plan 9 version 4.
But just getting rid of the root user in UNIX (Linux) wouldn't be
enough, the whole security model of UNIX should be redesigned. This
begins with rethinking the UNIX philosophy then implementing a new model. 
Of course, this may create either a new UNIX or another OS altogether.
IMO implementing LIDS or some other security scheme makes the UNIX
(Linux) environment not feel like UNIX (Linux) anyway, so why not
start with a redesign. 
 
In the present state of Linux I would agree with you about kernel
exploits. However, I think this too relates back to bad design and
old assumptions. Thoses designs and assumptions served a purpose
once but are now outdated.
 
It might be easier if I wrote a paper with references, then posted
it to a convenient location vice failing to explain my point. :-(
  
> I can! ;) Think of it this way, Uva: the system libraries ([g]libc) are 
> userland. Sloppiness here affects any application that is not statically 
> linked against a different set of libraries. How many security 
> vulnerabilities have we seen over the years because of sprintf() and 
> friends being vulnerable to buffer overflows and string format exploits?

I understand your point entirely, but what I'm saying is that it
doesn't have to be this way. There are so many old assumptions
that this is how it must be that it doesn't allow for innovation.

> I like you just for your repeated Plan 9 references. I played with it 
> very briefly, and absolutely loved the design philosophy. Would that I 
> had a bit more time...

I'm not trying to advocate that everyone switch over to Plan 9. I'm 
just bewildered that there hasn't been any progress in the fundamental
security model of Unix for years. I don't consider LIDS, or the NSA
ideas progress in the right direction. I think its just a bandaid,
and we are not taking on the real issue.

> I cannot agree with you here, Uva. "In-the-box" thinking is sometimes 
> just what we need for higher quality software. A solid design, following 
> good, formal software engineering practises is what "in-the-box" 
> thinking can accomplish. Of course, creativity, both in design and in 
<snip>
> And I think that what Viktor points out in his closing line is a symptom 
> of lack of a good design. This feature creep, if you will, is even more 
> tempting when you do not have a series of extremely complicated UML / 
> finite state machine diagrams to update. In this way, laziness can 
> sometimes save the day... ; 

I agree with you. But back to the bridge builder analogy, I'm not
attacking building techniques. 

-- Uva Coder

Plan 9 homepage: plan9.bell-labs.com