Forgot your password?
typodupeerror
Security Linux

Openwall Linux 3.0 — No SUIDs, Anti-Log-Spoofing 122

Posted by Soulskill
from the wouldn't-an-open-wall-be-a-gate dept.
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."
This discussion has been archived. No new comments can be posted.

Openwall Linux 3.0 — No SUIDs, Anti-Log-Spoofing

Comments Filter:
  • Re:Anti-debian key? (Score:5, Informative)

    by wowbagger (69688) on Friday December 17, 2010 @05:04PM (#34592606) Homepage Journal

    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)

    by Khopesh (112447) on Friday December 17, 2010 @05:06PM (#34592642) Homepage Journal

    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.

  • by verbatim_verbose (411803) on Friday December 17, 2010 @05:21PM (#34592840)

    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.

  • by fandingo (1541045) on Friday December 17, 2010 @05:23PM (#34592874)

    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)

    by zn0k (1082797) on Friday December 17, 2010 @05:33PM (#34593006)

    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)

    by characterZer0 (138196) on Friday December 17, 2010 @05:41PM (#34593120)

    Debian itself blocks the bad keys.

  • Re:Not Trolling? (Score:4, Informative)

    by MichaelSmith (789609) on Friday December 17, 2010 @06:20PM (#34593628) Homepage Journal

    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.

  • by JSG (82708) on Friday December 17, 2010 @06:42PM (#34593884) Homepage

    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)

Karl's version of Parkinson's Law: Work expands to exceed the time alloted it.

Working...