Date: Sun, 6 Feb 2011 22:16:49 +0300 From: Solar Designer <solar@...nwall.com> To: owl-users@...ts.openwall.com Subject: 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.