In succinct form:

The problem with Solaris 10 x86's boot process is not so much that itis trying to pretend that it has OpenBoot, the problem is that it isdoing such a clumsy and awkward job of faking it.

I will admit that I am not a fan of the Solaris 10 x86 boot process. Iunderstand why it is trying very hard to pretend that it is just likeSPARC hardware with OpenBoot, and I can even sympathize with Sun'smotivations for

Here is something that has struck me recently: virtualization andabstraction cannot eliminate security concerns, they can only move themfrom one place to another . In other words, virtualization by itselfdoesn't do anything to prevent security bugs; it just means that theyhappen in a different place.

(By virtualization I mean more than hardware and OS virtualization, Ialso include things like the JVM.)

The advantage of virtualization is that it moves the problem inwards,towards the center of the security onion, where fewer people

Yesterday I said that the kerneldirectly executes programs in place. Because I feel like walkingthrough the details, here is what the kernel does to start ELF programs onx86 Linux; for simplicity, I'm going to talk about 32-bit programs.

• First, the kernel maps the program's text, data, and BSS into memory. Almost allprograms require these to be mapped at fixed addressesstarting from 0x08048000 (128 Mb)

The real problem with setuid scripts on Unix isnot that writing secure shell scripts is challenging and obscure, itis that they are fundamentally insecure because of how the kernel runsthem. While the kernel runs programs by directly loading them intomemory , it runs scripts by running thescript's interpreter with the filename of the script, leaving it up tothe interpreter to read and execute the script itself. As is normal onUnix, there is nothing that keeps what file the filename points tothe same between these two