[owl-users] Owl-current 2011/02/05 snapshot

Hi,

We've made available the first Owl-current snapshot after our 3.0
release (new ISO images, OpenVZ container templates, and indeed packages
and sources).  The ISOs may be downloaded directly from:

http://www.openwall.com/Owl/

and the rest of the stuff is under /pub/Owl/current (or similar) on the
mirrors, as usual.

Since the release, we've moved from RHEL 5.5-based to RHEL 5.6-based
Linux/OpenVZ kernels, added support for non-raw (datagram) ICMP sockets
and made use of said support in ping(1), added several new packages
(ethtool, pv ("Pipe Viewer"), bridge-utils, libusb1, usbutils, vconfig),
updated to latest upstream versions of LILO, e2fsprogs, Nmap (adding
Nping), fixed a vulnerability in the patch(1) program (CVE-2010-4651),
and made some other enhancements and corrections:

http://www.openwall.com/Owl/CHANGES-current.shtml

The kernel is based on OpenVZ's latest "RHEL5 testing" one (as of this
writing).  There's no RHEL 5.6'ish "stable" kernel from OpenVZ yet, but
we did our own testing and patching of these kernels, and we believe
that the kernel version (with patches) currently in Owl-current is good
enough for -current.  Unlike many prior kernel updates in Owl, this one
(compared to Owl 3.0's kernel) is mostly not a security update due to
our security fix backports made from an almost-RHEL-5.6 kernel shortly
before the Owl 3.0 release.  Thus, we do not hurry to make this kernel
available in 3.0-stable yet; we will likely get a similar kernel into
3.0-stable after OpenVZ makes a "stable" RHEL 5.6-based release.
(Meanwhile, we're helping the OpenVZ folks test these "testing" kernels
by including the kernels in Owl-current.)

Yes, we've introduced support for non-raw (datagram) ICMP sockets into
the kernel.  This has been worked on by Pavel Kankovsky (a few years
ago, for Linux 2.4) and Vasiliy Kulikov (recently, for post-3.0 Owl),
with a little bit of involvement from me.  Some more info on this topic
can be found here:

http://lwn.net/Articles/420799/
http://openwall.info/wiki/people/segoon/ping

In short, this lets us start and run ping(1) without root privileges and
without a capability.  On Owl-current 2011/02/05 LiveCDs and on systems
installed from those CDs, the "ping" command is available for invocation
by all users (and it works, indeed), unlike on our 3.0 release where we
had "ping" restricted to invocation by root by default, although this
could be changed with control(8).  When upgrading from Owl 3.0 to this
Owl-current snapshot, "ping" will remain at the "restricted" setting by
default.  To enable the new mode, upgrade the kernel (not just the
userland), reboot into the new kernel, and run "control ping dgramsocket".
When upgrading systems that had previously been set to "control ping
public", this setting is automatically changed to the new "dgramsocket".
This has the side-effect of breaking "ping" for non-root until you
reboot into the new kernel.  If you want to upgrade the userland but
keep the old kernel (not the best idea), yet you want "ping" available
for use by all (despite of the added risk), you may issue "control ping
traditional" (and take the risk).

While we're at it, our upgrade instructions are here:

http://openwall.info/wiki/Owl/upgrade

It is OK to upgrade from Owl 3.0 to this Owl-current snapshot (if you're
adventurous enough) even if you might choose to go with 3.0-stable rather
than with -current later.  We have not broken 3.0 compatibility yet, so
you'll be able to make this choice later.  However, this is likely the
last Owl-current snapshot that leaves you this choice.  The very next
one will likely deviate from Owl 3.0 compatibility (slowly moving
towards making Owl 4.0 somewhat compatible with RHEL6, likely starting
with an OpenSSL update, which we're already working on).  That is,
upgrades from 3.0 (and from 3.0-stable) to Owl-current will indeed
remain possible, but switching from such systems "back" to 3.0-stable
won't be "officially" supported.

Speaking of the package updates, one thing worth mentioning is that we
not only updated to the latest Nmap 5.50, but also introduced privilege
dropping into the new Nping utility.  That is, when you run "nping" as
root (because many of its features require raw sockets), it will chroot
to /var/empty and switch to a pseudo-user dedicated to the Nmap suite
programs.  This is completely transparent to you, but it reduces the
immediate impact of possible vulnerabilities in Nping (especially those
that might potentially be triggered via malicious traffic from the
remote system).  We're similarly patching the main Nmap program, but
that's no news - we've been doing that for years.

Enjoy!  (And post your feedback to owl-users.)

Alexander