Speaking of ping in particular, I have to admit that in Owl 3.0 it is simply restricted to invocation by root by default (mode 700) - not great, but usually acceptable. It can be re-enabled with "control ping public", and this setting will persist over upgrades, but it re-introduces the risk. We're working towards a better solution - specifically, we're testing a Linux kernel patch implementing non-raw ICMP sockets, which we intend to submit to LKML soon. (It already works for us, including via our patched ping, but this stuff was too cutting-edge to include it in the release.)

traceroute just works on Owl out of the box, though - we're using an implementation that makes use of Linux-specific kernel features (upstream, no patches) such that it does not need any special privileges to run (it is installed mode 755 and it works for all users). (This is similar to what we're trying to implement for ping, but it's already a reality.)

You're talking of Fedora's approach with fscaps (and there are errors in your description). We don't do that. We're smarter than that! So your comment does not apply to Owl, at all. I've explained what we actually do in further comments. It is also shown in our presentation slides:

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

Specifically:

http://www.openwall.com/presentations/Owl/mgp00013.html
http://www.openwall.com/presentations/Owl/mgp00020.html

(and further slides, just click "next").

Exactly. And our solution to the "accountability" problem when there's more than one sysadmin is multiple root accounts - we typically prefix their usernames with "r_" for clarity, and we keep the main "root" account locked. We even have our own msulogin program, replacement for sulogin, to allow for single user mode console logins under any one of multiple root accounts that might exist on the system. The rest of Linux tools happened to just work with multiple root accounts fine, with no changes needed on our part.

That said, if anyone truly wants to use the traditional absurd approach of su'ing to root, they can re-enable su with "control su wheelonly" (there are other possible settings as well). Of course, this makes /bin/su SUID root... but you asked for it. This setting will persist over Owl upgrades. See "man control", "control" (just run it with no options for a list of facilities and their possible settings).

No, we don't! We're smarter than that. I've explained what we do in further comments (in the thread about my criticism of Fedora's approach).

There were in fact cases where other Linux distros had to issue updates and advisories - e.g., for an issue in crontab (to use the same example that I used for some other comments here) - whereas on Owl not only the vulnerability did not exist in the first place, but also it would have been mitigated due to the greatly reduced privileges of the crontab program (to use the same example again). To give another example, the recent glibc vulnerability with LD_AUDIT and $ORIGIN (discovered by Tavis Ormandy) not only did not affect Owl for a couple of reasons (including due to a glibc hardening patch), but also would be mitigated by not having a single SUID program if the vulnerability did exist on Owl (it did exist on almost all other distros). As you can see from this, we often have multiple layers of security hardening that help (with this being one of the layers) whereas others sometimes happen to have none - and are vulnerable.

At this point, our weakest link is the Linux kernel - large and monolithic - so that's pretty much the only place where critical vulnerabilities that do affect us are still being found... There's little we can do about this (while staying Linux), but it may be a focus area for further security hardening now that we have an almost perfect userland. Also, Owl differs from other/major distros as it relates to exposing the Linux kernel to attack - we expose less of it - e.g., we exclude kernel module auto-loading, we have saner/safer permissions on device files, and we have no SUIDs by default (which mitigates some classes of potential vulnerabilities in the Linux kernel's program startup code - such vulnerabilities were found/fixed in the past).

That was regarding "no SUIDs". As to the detection of log record spoofing, it does not stop attacks, but it is a security feature. When you review logs, you typically want to have a way to know whether the records are genuine, at least under the assumption that the system has not been compromised yet. On traditional Unix/Linux/BSD/..., you had to assume that any (pseudo-)user could have trivially produced any of the log records, pretending to be any system service or even the kernel.

> BTW Fedora 15 is also dropping SUID, so while Openwall is the only current distro. It's by no means the only one in development.

Right, however Fedora's approach is (1) completely different and a lot worse than ours (in my opinion, indeed) and (2) either won't result in complete removal of SUID programs or will leave many with root-equivalent capability sets. This means that they will continue to expose the dynamic linker, libc startup, and relevant parts of the Linux kernel to the usual risks associated with SUID root program startup - something that we avoid.

> Ubuntu is also removing SUID, but I don't know their timetable.

They're aware of the drawbacks of Fedora's approach, so they don't hurry to implement it. They're also aware of our proposed alternative. :-)

> Here's one of the better criticisms of dropping SUID, and it's from an Openwall developer. These criticisms are echoed by almost everyone thinking about removing SUID.

I am glad that you liked my criticism of Fedora's approach, however it appears that you misunderstood me. I criticized their specific approach with fs capabilities, not the idea of getting rid of SUIDs in general. The approach taken by us in Owl (many years ago, but only widely publicized now) and the one being taken by Fedora now are completely different (SGID and changes elsewhere in the system in Owl vs. fscaps in Fedora). The purpose of my criticism was to make other folks, including Fedora developers, consider the issues and the alternatives. It was not to discourage them from taking the move, but rather to give them an opportunity to consider our approach, which we consider to be the better and "real" one.

With our approach implemented in Owl, a used-to-be-SUID program runs SGID to a group dedicated to a certain purpose - e.g., editing a user's crontab. Other parts of the system have been modified such that privileges of that group are sufficient for but can't be expanded further than its intended purpose - e.g., permissions on /var/spool/cron and extra checks in crond (for crontab file ownership and more) are such that a possible compromise of group crontab would not give the attacker almost anything - no ability to edit another user's crontabs without also finding a (second) vulnerability in crond or in system components relied upon by crond. Yes, we could as well not use SGID - just make the crontab program fully unprivileged and the /var/spool/cron directory writable by anyone (the sticky bit prevents messing with another user's existing crontabs). The reasons why we chose to use SGID and a group are: (1) this is needed to prevent some DoS attacks (such as taking up another user's would-be crontab filename) and (2) it is an extra layer of security (so direct attacks on crond are not possible without compromising crontab first). Our changes to crontab/crond have since been adopted by ALT Linux, OpenBSD, and even by upstream ISC (Vixie) cron (but most distros somehow don't hurry to make use of this functionality, continuing to install crontab SUID root...)

Fedora's approach is to replace SUID root with fscaps - that is, the programs are still granted a lot of privilege, just somewhat less than they were with SUID root. In many cases (perhaps even in most, where ping might be the only exception), such capability sets are in fact root-equivalent, so this is sweeping SUIDs under the rug. Also, there's no second layer of security. See the difference?

> I wrote a program once that needed SUID for about a hundred asm instructions.

Sure the program may be tiny, but it exposes parts of the dynamic linker, libc startup, and even extra parts of the Linux kernel code for attack. All of these components have historically had vulnerabilities exploitable specifically via SUID programs. The point behind not having a single SUID program in a default install of Owl is primarily to mitigate potential vulnerabilities in those components. I do agree that, as the distro level, it would otherwise be possible to live with a few tiny SUID programs, but the risk with other exposed components is very real - so we avoid it.

> CAP would be wasted as chroot() is one of those known to grant root power.

Right. Red Hat are going to "waste" capabilities like this. We are not doing that (we use SGIDs and changes elsewhere in the system instead). (To be fair, there is a subtle reason why even root-equivalent capability sets may be slightly better than directly running as root when we consider some specific vulnerability classes. This is just too complicated to discuss in a comment like this.)

> I do hope a lot of the work gets ported to other distributions so it is in common use.

Not only to other distributions, but also to upstreams (for software that we package). Both of these things have been happening throughout the 10 years (individual pieces and concepts got into "base systems" of ALT Linux, Mandriva, FreeBSD, DragonFly BSD, OpenBSD; other Openwall software is also packaged for all major Linux distros and *BSDs; many of our patches got into upstream repositories/versions of software that we package), but we still do have more stuff to "export" - and we're trying to.

Is this news to anyone? Working under the assumption of a partial compromise is the only sane way to "do" security. We even do it at our homes, for both virtual (e.g., SSH rather than Telnet over LAN) and physical security (e.g., one may lock the door to their apartment even though there's a concierge downstairs).

No, it does not. (That's not to mention that the problem "in OpenBSD" is probably a hoax.)

In context of another discussion, we've reviewed our Linux kernel source tree for relevant code from OpenBSD - there's none. Additionally, we don't include userland software for IPsec support - so it is not supported on Owl out of the box. Instead, OpenVPN may be easily installed and works great on Owl, and we might add it to the base system for the next Owl release. I am sending this comment via an OpenVPN tunnel between two Owl boxes.

You must be alluding to this story's title. It actually mentions two distinct properties of Owl, our focus on security (more on it below) and our inclusion of a complete build environment and full source code (even on our live+installable CDs, which also include all of the binary packages - yes, it is possible to rebuild from source even while CD-booted should you want to for some weird reason - we sometimes use this as a stress test).

We have a policy to audit certain security-critical portions of code in software that we're about to include into Owl, and we fix whatever issues we find. (We also submit our patches upstream and share them with other distros. You're likely currently running software with our fixes even if you have never heard of our project - e.g., do you use xinetd or OpenSSH?) And we make sure the programs will normally not be run with excessive privileges; quite often, this involves minor re-design of the program to introduce privilege reduction (e.g., syslogd, klogd, crontab/crond, Nmap) or privilege separation (e.g., telnetd).

As to third-party software that one might install on top of Owl, we include some security hardening measures that will mitigate the impact of many security bugs. This includes pam_mktemp, which will create per-user $TMPDIR on login (or on cron job startup, for that matter), and "transparent" modifications to many system libraries (starting with glibc). More importantly, the Owl userland separates Unix (pseudo-)users to a greater extent than many other Linux distros do. We got rid of almost all SUID programs, which would pose a risk of "local" attacks (only "ping" remains for now, and you can "control ping restricted" to limit its use to root). If you run the additional programs under separate accounts (e.g., a user runs an IRC client, or you run an IRC server under a dedicated pseudo-user account), then your risk of having a possible compromise propagate to other accounts is lower than it would be with typical Linux distros.

Finally, there are OpenVZ containers for even greater separation. A real-world example: several instances of DokuWiki "live" in the same container (separate Apache virtual hosts and Unix accounts). This container has Apache, PHP, DokuWiki on top of the Owl userland. Another website, not requiring PHP, is placed into another container on the same server. No PHP, no DokuWiki in that container, thus lower risk from those. For a "mail server", a third container may be created, maybe with no added programs (Postfix, popa3d, procmail, Mutt, mailx are a part of Owl) or maybe with some mail-specific ones.

Now what's that, a serious write-up in response to a sarcastic comment? Whatever.