Tracy R Reed wrote:
He does say least privilege is not as important as we think. I tend to
disagree with that. The example he cites is one case where least
privilege doesn't help that much but in many other cases it is critical.
I think his point is that least privilege, as often implemented, is
insufficient. If the least privilege you have is capable of wiping out
the user's data, it's not "least" enough.
DJB uses testing to check that all of his code works as expected and
continues to work as he makes changes. I need to start doing this.
I haven't found a good way of doing this for many kinds of code. It's
very difficult (I have found) to do unit tests of (for example)
real-time feeds of data coordinated with other real-time feeds of data
from other sources.
certain perl programmers who hated to pull out just 4 lines of their
code into a standalone function.
Me, I never got a FORTH function *more* than four lines long to work. Of
course, FORTH is trivial to pull out into a function.
But a standard Erlang way of dealing with
errors is that the program dies but then the interpreter/virtual machine
just restarts it.
I'm already doing this in my current project, with a Tcl program
watching for and restarting a C++ program that has too many bugs to fix
right. :-)
He makes good points about using the operating systems network tools,
access tools, database tools (filesystem) etc. and makes some very good
points which reduce the amount of potentially buggy code.
You can hit a bottleneck, tho. I worked on one system that kept the
"database" in the file system (back when a DBM cost $100,000). After a
year or two, we wound up buying the DBM anyway, because an incremental
dump wound up taking >24hours to scan what changed in the last 24 hours.
Section 5.2 makes a good point and basically uses a functional
programming idea to sandbox calculations such as rendering a jpg into a
bitmap avoiding potential exploits caused by malicious data. Expensive
to do in a Unix style process but perhaps not so bad in a sandboxed
thread in a virtual machine like Erlang or Java.
Or in a language that actually can enforce such restrictions.
IBM came up with a language called NIL (Network Implementation Language)
that they later generalized into something called Hermes. It sounds like
it was a lot like Erlang. High-level, everything was processes and
SQL-like tables and unlimited-length integers and asynchronous messages
and such. Except the compiler was good enough to turn a "create this
process, send it a message, wait for an answer, and then the process
exits" into an inline function call without actually copying any of the
variables. It actually could compile to code faster than C, because it
didn't have to push any arguments on the stack, yet was safe enough that
customers could run their own functions on the networks switch that had
no memory addressing hardware.
Plus, when something *did* happen that was unexpected (like you powered
off the machine that process happened to be running on), it would
migrate the state over to a different machine, replay it in the right
order, and catch it back up, so you didn't in practice have to code
recovery semantics.
Indeed, they had the code for SNA all written, and one customer wanted
it to run on redundant load-balanced switches with hot fall-over. The
team doing the research realized they didn't need to actually change the
NIL code. They just improved the compiler.
Yet you couldn't access off the end of an array, overflow an integer
counter, or do any of the 105 other things that programmers using unsafe
languages don't think about happening while they're coding. And it was
efficient enough to run big real-time switches back when hardware was
expensive.
Tracy R Reed wrote:
> The idea that you should recognize certain patterns as a deficiency of
> the operating system was one of those "bloody obvious" bombshells that
> is only obvious in retrospect--and only possible with open source OS
> systems.
Nonsense. People knew about deficiencies in OSes and languages long
before "open source" was around, or they wouldn't have been improving
it. "Open source" just makes it relatively cheap and easy to get
involved in such improvements, which is important at a time when most of
the blatant misfeatures have been shaken out of OSes.
Probably some of the applications that the OpenBSD guys have put together are comparable (OpenSSL and OpenSSH spring to mind).
At least a couple of take-over-the-machine bugs have been found in
OpenSSH, if I recall correctly.
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
