Paul Vixie of Internet Systems Consortium guides us on a journey into the sublime details of the domain name system. A must read for any person dealing with network and internet technologies!

Jonathan Schwartz from Sun has some free advice for Microsoft in his blog:

Years back, Sun was under pressure in the market. Although many users loved our core Solaris operating system, others thought it was built for high end computers, not grid systems. Our computer business had failed to keep pace with the rest of the industry — which meant our volume systems looked expensive. In combination, and with a poor track record of supporting Solaris off of Sun hardware, we gave customers one choice — leave Sun. Many did. Those were the dark days.

Here is an interesting post to Dailydave by Brad Spengler from grsecurity.net which I will duplicate in part here: Few of you may have seen my comments on the following article in RedHat magazine: What’s new in SELinux for Red Hat Enterprise Linux 5?

I think the issue deserves more widespread attention among the security community, however, since RedHat seems to be involved in a concerted effort of disinformation for both SELinux and ExecShield. Take note of their misleading (another word for completely inaccurate) diagrams, inability to understand what exactly the new additions to SELinux have to do with “buffer overflows,” and then note my several comments below, where I also comment upon some ExecShield behavior under a non-NX system. I present you with links to several previous articles on RedHat security and the official ExecShield paper, all written by developers at RedHat, who make several inaccurate/misleading statements regarding the effectiveness under ExecShield in a non-NX environment (which RedHat would have you believe does not exist anymore).

I encourage you to read all the comments, however the basic idea is that ExecShield has had problems ever since it was introduced into Fedora and then into RHEL (sometimes due to improper marking with the flawed PT_GNU_STACK which under ExecShield with no NX makes the entire address space executable, other times with bugs in the ExecShield implementation that ended up leaving over half of the services on a Fedore Core 3 system being protected improperly).

Then there’s the design issue RedHat doesn’t want you to know about:
under ExecShield with no NX, every writable mapping lower than the highest executable mapping in the address space is executable.

For PIE binaries, due to their weaker form of PaX’s ASLR, this becomes even more interesting since it produces what I call “nondeterministic security.” Since PIE binaries are treated just like libraries, they may or may not be loaded as the highest-mapped library in the system. Since there is only one PIE binary loaded and many more libraries being loaded, this means that there’s a large chance that the bss/data on the main executable will be unprotected — writable and executable.

Ingo knows about this (I mailed him privately about the problems I saw with Fedora Core 3, which resulted in an updated kernel — though I don’t believe users were really notified of the fact they were being fooled into thinking certain protection was being applied to their binaries that in fact was not), but it seems he’s not talking to anyone else at RedHat if you look at the articles that keep coming out about their “security enhancements.” In my last comment I list articles I found about ExecShield with the inaccurate statements (I couldn’t find any with an accurate discussion of them). Among them: http://www.noncombatant.org/trove/drepper-redhat-security-enhancements.pdf http://www.redhat.com/magazine/009jul05/features/execshield/ http://www.redhat.com/f/pdf/rhel/WHP0006US_Execshield.pdf

I really hope I don’t see another article from RedHat about SELinux containing diagrams like:

or an article about ExecShield saying that its protection on a processor without NX is comparable to one with NX.