Slashdot Mirror
Openwall Linux 3.0 — No SUIDs, Anti-Log-Spoofing
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."
While OpenWall won't see much adoption on it's own I do hope a lot of the work gets ported to other distributions so it is in common use.
Not trolling, but Linux Security is somewhat atrocious these days with the whole security via obscurity approach, so I for one have a better state of mind when I know I can protect myself even in the result of a succusful exploit.
If you ignore ACs because they are anonymous - you're an idiot.
This is pretty interesting, I just wonder what happens to Fortress Linux?
"Never give up, never surrender!"
Can it do so with cross-compilation? I want this as an ARM distro...
"Flyin' in just a sweet place,
Never been known to fail..."
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.
THL phish sticks
While I'm not terribly interested in the distribution itself, its great to see a classic Slashdot story about some major or point release of a semi-well known OSS product.
Bye!
I'm not sure I believe that. The only way I can think of permitting things like su and passwd (among many others) is by running some sort of permissions escalation daemon ("owl-control" perhaps?) as root that essentially does the same thing. This moves the vulnerability from the binary to the permissions daemon.
There is almost no documentation on owl-control; the best I could find was a FreeBSD port and the (encoded) man page as plucked from CVS HEAD.
If this has been independently audited and continues to appear to be a Good Idea then perhaps it would be of interest to one of the larger distributions?
Use my userscript to add story images to Slashdot. There's no going back.
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
https://bugzilla.redhat.com/show_bug.cgi?id=646440
Ubuntu:
http://www.outflux.net/blog/archives/2010/02/09/easy-example-of-fscaps/
https://wiki.ubuntu.com/Security/FilesystemCapabilties
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
-%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
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.
http://michaelsmith.id.au
I am getting modded down because zealots have modpoints.
Most people who use Linux don't review the code nor should they be expected to. We should expect the developers to disclose security problems in a responsible way. They don't, they obscure them.
So yes, the developers do practice security via obscurity. DO I really need to go and link the interview on kerneltrap where they say and defend that practice?
If you ignore ACs because they are anonymous - you're an idiot.
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)
So if I release a program that encrypts data by XOR'ing all bits, it is not security through obscurity simply if I release it as open source? That is the classic example of security through obscurity, and making it open source doesn't change that. The open source aspect of it only means that people will potentially discover this problem.
If you've ever released something on source forge you should compare your stats regarding people accessing the source code versus downloads. You will find the source code is next to never downloaded if you are providing binaries.
The typical definition of "security through obscurity" refers to hiding bugs and vulnerabilities by keeping the design and implementation secret via closed source.
No it means placing a reliance on something which is hard to find. If I hide my house key under a pot plant in my front yard I am relying on the obscure location of the key. The garden is open source. Anybody can search it.
http://michaelsmith.id.au
I'm interested in this for a VMware guest OS, as a possible alternative to m0n0wall. Have the authors thought about that kind of implementation
Yes, Owl 3.0 works in VMware out of the box. We mostly run it in QEMU and VirtualBox for our VM-based testing, though.
BTW, you might find it curious that when you run Owl in a VM like this, you can further create OpenVZ containers with multiple instances of Owl and with other Linux distros inside that single running copy of Owl. Such container-based virtualization has no further performance overhead. :-)
How much RAM does it need to run adequately?
128 MB is plenty, probably a lot less will do. I have my QEMU set to its default of 128 MB when I do install-tests with new Owl ISOs. Also, my Owl-based router and small fileserver at home has 128 MB RAM (runs the default-enabled set of Owl services plus ntpd, named, pppd/pppoe, openvpn, squid, NFS, and a sometimes a few lftp's and ctorrent's under screen).
On the other hand, of course you may need a lot more RAM for your specific uses of Owl - e.g., to run many OpenVZ containers, to do web hosting, etc. We currently administer several 32 GB RAM machines running Owl and one 64 GB RAM machine, as well as a countless number of 4-16 GB machines - so we know Owl has no problem with these larger RAM sizes as well (and with the many OpenVZ containers running various Linux distros actually making use of this RAM).
You obviously don't know what code obfuscation is. Code obfuscation involves modifying code or the compiled binaries to obfuscate code. I didn't describe anything that involves manipulating code or the program itself. Such a step usually I explicitly said "encrypts data by XOR'ing all bits". The keyword is data. Where did I say anything about obfuscating the source code? I didn't. This has absolutely nothing to do with code obfuscation. You obviously know absolutely nothing about security because you don't even know the basic definition of common terminology.