My morning email slog was greatly enhanced by some choice quotes from Peter Gutmann on the IETF Security Area Advisory Group list:
Compare this to the example I gave earlier of performing a TLS exchange with Amazon. This performs an in-depth test of all the crypto algorithms (corresponding to the FIPS algorithm tests, including ones that FIPS ignores), and the crypto mechanisms (many/most of which FIPS again ignores). In other words simply by connecting to Amazon using TLS and ordering a “Scrubs” DVD for $19.95 I’m getting more comprehensive algorithm testing than I can for a five-figure sum with the FIPS algorithm tests.
This was based on a FIPS-140 crypto certification costing $100,000 (which was challenged in a followup as costing a mere $30,000).
He then describes what he believes would be a better way to use the $100k in assuring a crypto product, including the purchase of a $45k home theater system, beer, and setting a up fake banking web site as a honeypot to attract Russian mafia.
I’d like to say, somewhat for the sake of the OpenSolaris folk who are currently having a bit of a rough time, that I personally strongly disagree with certain statements coming out of the Linux Foundation, such as those claiming that the “L in LAMP is literal”. 
Of course, LAMP has long been representative of the concept of a free software stack. The term itself has been tremendously useful as a means to identify an open approach to developing and deploying systems. The L does of course not have to mean Linux any more than the P needs to mean PHP or Perl. Aside from OpenSolaris, there are many good choices for operating systems in an open stack, such as OpenBSD.
While LF is an industry consortium representing several companies and organizations with various interests in Linux, it certainly does not generally represent the Linux community.
As a Linux developer, I’d like to continue to extend support and encouragement to OpenSolaris developers.
I believe that such attacks on other open projects serve to damage the general interests of FOSS. Interestingly, LF has granted itself authority to respond to “competitors’ attacks” , a role which is surely undermined by themselves undertaking such attacks, especially on emerging FOSS projects.
Rafal Wojtczuk of McAfee Avert Labs posted an interesting analysis of the “qaaz” exploit for the recent vmsplice vulnerabilities.
Since 2.6.23, it has been possible to prevent applications from mapping low pages (to prevent null pointer dereferencing in the kernel) via the /proc/sys/vm/mmap_min_addr sysctl, which sets the minimum address allowed for such mappings.
So, if you have a recent kernel still affected by the vmsplice issue, try:
echo 65536 > /proc/sys/vm/mmap_min_addr
(If it is not already set, of course).
If using SELinux, the system must be running in enforcing mode.
Note that there was a bug in the mmap_min_addr code until 2.6.24-rc5, although I do not believe it affects mitigation of this particular exploit.
Generally, it is a good idea to have mmap_min_addr set, although it is disabled by default in the upstream kernel as it can affect a some applications (e.g. users of vm86 mode such as X).
As SELinux is able to selectively enforce the setting via policy, it can be enabled for the general case on recent SELinux systems. If not using SELinux, processes with CAP_SYS_RAWIO are allowed to bypass the setting.
Serge Hallyn of IBM and general kernel hacking fame has written a great article on Role-based access control (RBAC) in SELinux.
The article is also something of a tutorial, implementing a security scheme for a simple store cash register system, with downloads available for a Gentoo-based SELinux from Scratch qemu image; and for standard Fedora 8 systems.
It’s great to see these kinds of projects coming from the community!