Openwall Linux 3.0 — No SUIDs, Anti-Log-Spoofing 122
solardiz writes "Openwall GNU/*/Linux (or Owl for short) version 3.0 is out, marking 10 years of work on the project. Owl is a small, security-enhanced Linux distro for servers, appliances, and virtual appliances. Two curious properties of Owl 3.0: no SUID programs in the default install (yet the system is usable, including password changing); and logging of who sends messages to syslog (thus, a user can't have a log message appear to come, say, from the kernel or sshd). No other distro has these. Other highlights of Owl 3.0: single live+install+source CD, i686 or x86_64, integrated OpenVZ (host and/or guest), 'make iso' & 'make vztemplate' in the included build environment, ext4 by default, xz in tar/rpm/less, 'anti-Debian' key blacklisting in OpenSSH. A full install is under 400 MB, and it can rebuild itself from source."
Re:Anti-debian key? (Score:5, Informative)
The exploit was years ago, but you never know when somebody generated a key under the broken system, and hasn't regenerated their key due to (missing the memo|laziness|stupidity) and is still using a weak key.
So, many distros block the bad keys to force people to clean up.
Re:Anti-debian key? (Score:5, Informative)
Can someone explain (for real) the point of the 'anti-Debian' key blacklist?
Is it because of the Debian-specific vulnerability in OpenSSH? I thought that was a couple years ago.
Yes. There are still lots of keys out there that were generated with this bug, so it is still worthwhile to test for that. When it comes to uber-secure projects like OWL and OpenBSD, this will likely never change; it's a trivial check for a nontrivial gain.
Re:/bin/su isn't SUID?! (Score:4, Informative)
See Fedora's page [fedoraproject.org] for the same feature.
In short, there is a system now which gives programs certain capabilities based on tags set in the file system. With this, running as root is not needed for most things.
Dropping SUID doesn't improve security (Score:5, Informative)
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.
There's a lot of talk lately regarding replacing the SUID bit on program
binaries in Linux distros with filesystem capabilities. Specifically,
Fedora and Ubuntu are heading in that direction.
Fedora:
http://fedoraproject.org/wiki/Features/RemoveSETUID [fedoraproject.org]
https://bugzilla.redhat.com/show_bug.cgi?id=646440 [redhat.com]
Ubuntu:
http://www.outflux.net/blog/archives/2010/02/09/easy-example-of-fscaps/ [outflux.net]
https://wiki.ubuntu.com/Security/FilesystemCapabilties [ubuntu.com]
While in general this is a good idea, there are issues with it, in
arbitrary order:
- Some currently-SUID programs are aware of them being (potentially)
SUID, and will drop the "more privileged" euid when it is no longer
needed, but they will probably not be aware of them possessing
capabilities. This may result in larger parts of the programs
(sometimes orders of magnitude larger) running with elevated privileges
(or with allowed-to-be-elevated privileges, which is a privilege on its
own and is usable through vulnerabilities that allow for arbitrary code
execution). Let's consider ping, which appears to be the classical
example of "where filesystem capabilities will help" (or so it is
claimed). IIRC, it starts by acquiring a raw socket (NB: of a certain
somewhat-limited type), then drops root privs (if it was installed SUID
root and run by non-root), then proceeds to parse the command-line,
resolve the provided hostname, and so on. If the SUID bit is replaced
with cap_net_raw+ep, as seen in Kees' example above, will ping know to
drop this capability? Hardly. Not without a source code patch.
Besides, dropping the capability might [need to] require privileges
beyond CAP_NET_RAW itself (recall the capability-dropping attack on
sendmail from a decade ago). So does moving from SUID root to
cap_net_raw+ep improve security? Most likely not. On the contrary, it
results in hundreds of lines of ping's code and thousands of lines of
library code (DNS resolver) running with elevated privileges, as
compared to just a few lines of ping.c, which was the case with simple
SUID root. Granted, those "elevated privileges" are a lot less than
root privileges, but they're a lot more than having a single raw socket
of a specific type.
- In some cases, the capability sets being granted are (almost)
equivalent (or expandable to) full root powers. This is seen in:
http://people.fedoraproject.org/~dwalsh/policycoreutils_setuid.patch [fedoraproject.org]
-%attr(4755,root,root) %{_bindir}/newrole
+%attr(0755,root,root) %caps(cap_audit_write,cap_setuid) %{_bindir}/newrole
-%{_sbindir}/seunshare
+%attr(0755,root,root) %caps(cap_setuid,cap_dac_override,cap_sys_admin,cap_sys_nice) %{_sbindir}/seunshare
This mostly just sweeps the SUID root under the rug, where the sysadmin
will hopefully not see it and thus feel safer. However, it may expose
more problems in the programs if they knew to drop root, but wouldn't
know to drop the capabilities (same issue I described above for ping).
Granted, vulnerabilities of certain classes might become unexploitable
or be partially mitigated. For example, if no direct code execution is
possible (not a buffer overflow, etc.), but "only" privileged access to
an attacker-provided arbitrary pathname is possible, then "newrole"
above would be protected, but "seunshare" above would not (because of
cap_dac_override).
- Completely getting rid of SUID root pro
Re:Rebuild itself? (Score:4, Informative)
http://www.openwall.com/Owl/ARCHITECTURES.shtml [openwall.com]
> Cross-builds are not supported: it is not possible to build packages for an architecture different than that of the build host, nor for a flavor of the architecture newer than that implemented in the build host's CPU.
No, it can't do cross-compiling. And ARM is not supported.
Re:Anti-debian key? (Score:5, Informative)
Debian itself blocks the bad keys.
Re:Not Trolling? (Score:4, Informative)
By definition, it's impossible for open source software to practice security through obscurity.
When you have mass quantities of obscure code it is certainly possible to do that for a while.
Re:VMWare support? RAM requirements? (Score:4, Informative)
There's always pfSense as an alternative to m0n0wall. I run many of those under VMWare.
I chose it for its easy multi external link capabilities, after I gave up on Linux for this and was pleasantly surprised by its ease of use, stability and huge range of features.
It is nearly bullet proof as I discovered when one of a customer's VMFS died. All the other VMs fell over immediately but the pfSense router carried on running without its "hard disc" for two days before I replaced it. Internet access downtime was 2 seconds as I cut it over. Admittedly the web interface vanished but the routing, VPNs, firewall etc carried on running.
As to OWL, its a Linux distro so it will have no problems with being a VM - that's the whole point of virtualization. You might have to select "Linux other (64 bit)" but my many Gentoo's run happily like that
Why on earth should the devs even think about VMWare, HyperV, KVM or whatever - that's your job! Apart from considering making the guest tools pre-packaged what should they be doing? I doubt they care whether you spec your boxen from Dell. HP, IBM or PC World so why should they care whether it is physical or VM?
As to asking about RAM requirements - I'd suggest (without even having looked at it) >=256Mb depending what you do with it. I've no doubt that fact is covered on their web site. If you are using ESXi and not just playing on your home PC then the answer would probably be "who cares, RAM is cheap as chips"
Go on - try it, I might even do the same.
Cheers
Jon
PS You have a 5 digit /.ID. Have you been moonlighting on other OSs for the last 10 years, asking such questions 8)