Follow Slashdot stories on Twitter

 


Forgot your password?
Close
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 More

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

Comments Filter:

  • Amazing Work (Score:4, Interesting)

    by metrix007 ( 200091 ) on Friday December 17, 2010 @03:50PM (#34592368)

    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.

    • Not Trolling? (Score:2, Troll)

      by mpapet ( 761907 )

      t Linux Security is somewhat atrocious these days with the whole security via obscurity approach

      Your ideas are intriguing to me. I would like to subscribe to your newsletter.

      • It's not surprising I have been modded down already, but I am referring to the policy of the developers not to disclosure security bugs that can result in remote compromise, and not to treat them with any priority. A policy I find appalling.

        • Re: (Score:2)

          by santax ( 1541065 )
          Don't agree with you being nodded troll, but also don't agree with what you say. There is a very good mailing-list, called full-disclosure. The devs have no choice. The bugs and exploits will be on that list. All of them.

          • The point is that Linux devs often only make a patch after being forced to. At the moment there are many problems which they just ignore as they don't consider the problems interesting or as important as getting the scheduler .0000001% faster.

            • Re: (Score:2)

              by santax ( 1541065 )
              Hmmmz only problem that comes to mind is proftpd, but the dev patched that I think. Just the distro's not. Can you name some more? Cause I believe the devs normally (95%+) fix a security problem asap.

              • Well I am referring to the Linux kernel, not anything else. Look at that recent root hole this year...it was known about for a few weeks and only fixed when pressured to via full disclosure.

                • Re: (Score:2)

                  by kermyt ( 99494 )
                  normally when people are serious about not being called a troll they will include citations to back up what they are saying. Thus far you are totally trolling. Citations please?

                  • Wow, google is hard. Let me help you with that.

                    Here [kerneltrap.org] and Here. [slashdot.org]

                    You can see here [mitre.org] that it was assigned more than 2 weeks before it was disclosed and started to be patched.

                    • You asked for proof, you can't expect an entire case history. Do your own damn research, zealot. If nothing else there is definite proof that the developers have at least on one occasion practices security via obscurity.

    • commenting to kill an accidentally bad mod...

    • Re: (Score:2)

      by Eil ( 82413 )

      Not trolling, but Linux Security is somewhat atrocious these days with the whole security via obscurity approach

      In order to qualify as "not trolling," you have to explain which parts of Linux rely on security through obscurity. The source code to Linux is completely out in the open and available to anyone who wants to study how it works. What do you think is hidden?

      • I think the security vulnerabilities are hidden in that the developers choose not to disclose them to people who don't bother to review the entire source tree. It's the perfect example of security via obscurity.

    • > 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 tha

  • This is pretty interesting, I just wonder what happens to Fortress Linux [fortresslinux.org]?

  • Rebuild itself? (Score:3)

    by Jeremiah Cornelius ( 137 ) on Friday December 17, 2010 @03:54PM (#34592446) Homepage Journal

    Can it do so with cross-compilation? I want this as an ARM distro...

    • Re:Rebuild itself? (Score:4, Informative)

      by zn0k ( 1082797 ) on Friday December 17, 2010 @04: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.

      • Bummer. Zeroshell can be made to fit - but track all those separate sources? No way.

        I guess it's packetprotector, on top of OpenWRT.

    • 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? How much RAM does it need to run adequately?

      • Re:VMWare support? RAM requirements? (Score:4, Informative)

        by JSG ( 82708 ) on Friday December 17, 2010 @05: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)

      • Agreed. Perfect appliance baseline. Most appliances don't want package mangement outside the scope of their platform workload, anyway.

      • 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 i

        • Cool, thanks! I've got a lab where we evaluate firewall and intrusion detection products, and since we just got a new big VMware box, I'd like to be able to fill it full of well-behaved client VMs, evil nasty client VMs, etc., so a distro that's reasonably small and has reasonable features and convenient management is a helpful thing.

    • No, officially we don't support ARM, but I have plans to make an ARM build of a stripped down Owl since the number of ARM-based devices is rapidly growing at my home. :) A DSL modem, a NAS box, and a couple of netbooks - all are ARM based. This gives me a lot of temptation to build Owl for ARM. :)

  • Anti-debian key? (Score:4, Interesting)

    by gandhi_2 ( 1108023 ) on Friday December 17, 2010 @03:58PM (#34592506) Homepage

    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.

  • Ah Sweet Nostalgia (Score:5, Insightful)

    by ADRA ( 37398 ) on Friday December 17, 2010 @03:58PM (#34592512)

    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.

  • The exploits named in the summary are mostly for locally connected users, which means academic environments. I mean, how would you send a message to syslog over the web?

    The kind of secure system one needs today is mostly about the web server, if it doesn't come through port 80 it never reaches the server because the router blocks it.

    • Well, a poorly written script (and there are many of these nowadays) on a web server may allow an execution of an arbitrary process on the server -- so our hardening measures will try protect the system from the inside. Indeed, this is a quick response on your question, feel free to ask if you want me to elaborate further on this topic.

    • The exploits named in the summary are mostly for locally connected users, which means academic environments.

      Yes, local users and pseudo-users. No, this is not limited to academic environments. Think shared web hosting - hundreds or thousands of local users on a system. We're actually setting up Owl-based shared web hosting systems for our clients. Besides the different user accounts belonging to different shared hosting customers, privilege separation between the accounts is also needed because one of the websites may get compromised (via a web app vulnerability) and we would not want such a compromise to easily

  • 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 [uni-marburg.de] and the (encoded) man page [openwall.com] as plucked from CVS HEAD.

    If this has been independently audited and continue

    • Re:/bin/su isn't SUID?! (Score:4, Informative)

      by verbatim_verbose ( 411803 ) on Friday December 17, 2010 @04: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.

      • No, Fedora are using a different approach. We do not replace SUID/SGID with capabilities, instead we carefully design the system to take advantage of the standard Un*x OS level permissions. JFYI, all this buzz with replacing SUID/SGID binaries emerged from the recently discovered vulnerability (BTW, Owl was among few distributions which wasn't affected by that vulnerability at all), but unfortunately people are often getting things wrong, when it comes to security. Please review the following message tha
        • Oh, fandingo has already quoted the entire message I provided link for in his/her comment "Dropping SUID doesn't improve security", however I don't agree with the comment title since proper dropping of SUID _DOES_ improve security, and Owl is one of such examples.

    • A curious detail is that there are no SUID programs in a default install of Owl 3.0. Instead, there are some SGIDs, where their group level access, if compromised via a vulnerability, can't be expanded into root access without finding and exploiting another vulnerability in another part of the system - e.g., a vulnerability in crontab(1) or at(1) can't result in a root compromise without a vulnerability in crond(8) or in a critical system component relied upon by crond(8).

      From some googling and the announcement.

      Basically if you exploit something with 'shadow' (i.e. passwd) you add a root user account to /etc/passwd and su to it. if you exploit crontab or at, you add a crontab that adds a root level account or runs a command as root or creates a SUID program. It requires some hacker creativity, but doesn't make anything secure.

      • Re: (Score:2)

        by Bert64 ( 520050 )

        Depends on the program, exploiting a setuid ping would give you root, exploiting a ping with the capability to open raw sockets would give you the ability to open raw sockets, still bad but nowhere near as critical.
        It also as you pointed out makes it harder for exploit writers, most "hackers" are script kiddies who will use exploits written by other people, which may not target things like this (and certainly don't yet).

        • 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 patch

      • Basically if you exploit something with 'shadow' (i.e. passwd) you add a root user account to /etc/passwd and su to it.

        This is not true. You can't do anything like this even if you acquire the shadow membership:

        server!galaxy:~$ ls -ld /etc/passwd /etc/tcb
        -rw-r--r-- 1 root root 3956 2010-06-03 21:08 /etc/passwd
        drwx--x--- 99 root shadow 4096 2010-06-03 21:08 /etc/tcb
        server!galaxy:~$

        and the structure under /etc/tcb/ is also not writable to shadow:

        server!root:~# ls -ld /etc/tcb /etc/tcb/galaxy
        drwx--x--- 99 root shadow 4096 2010-06-03 21:08 /etc/tcb
        drwx--s--- 2 galaxy auth 4096 2009-10-24 04:44 /etc/tcb/gal

      • From some googling and the announcement.

        Basically if you exploit something with 'shadow' (i.e. passwd) you add a root user account to /etc/passwd and su to it. if you exploit crontab or at, you add a crontab that adds a root level account or runs a command as root or creates a SUID program. It requires some hacker creativity, but doesn't make anything secure.

        That's poor analysis on your part, so your conclusion is completely wrong. Please refer to our presentation slides for an explanation of how things actually work and why the attacks you describe would not work:

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

        BTW, the announcement specifically mentioned that "a vulnerability in crontab(1) or at(1) can't result in a root compromise without a vulnerability in crond(8) or in a critical system component relied upon by crond(8)." Did you not read that? Or do you disa

        • That's poor analysis on your part, so your conclusion is completely wrong.

          Yeah, I saw; you made passwd root-owned, which is the smart thing to do. How "passwd" works with root group r-- and no SUID is a mystery to me, I'll have to look later.

          BTW, the announcement specifically mentioned that "a vulnerability in crontab(1) or at(1) can't result in a root compromise without a vulnerability in crond(8) or in a critical system component relied upon by crond(8)." Did you not read that? Or do you disagree, thereby stating that we're inexperienced in the stuff we've been doing for 10 years?

          Theo de Radt used the argument on me once that he was more experienced than me and knew what he was talking about; he took it off-list which was good for him. The argument was whether position independent executables were "very expensive" (his words) on x86 (32-bit), and in the end I ran OProfile against the whole system and found that t

          • How "passwd" works with root group r-- and no SUID is a mystery to me, I'll have to look later.

            Please take a look at our presentation slides, it only takes a few minutes. Then you might have more specific questions on the implementation, which I'd be happy to answer.

            http://www.openwall.com/tcb/ [openwall.com]
            http://www.openwall.com/presentations/Owl/mgp00020.html [openwall.com]
            http://www.openwall.com/presentations/Owl/mgp00021.html [openwall.com]
            http://www.openwall.com/presentations/Owl/mgp00022.html [openwall.com]
            http://www.openwall.com/presentations/Owl/mgp00023.html [openwall.com]

            ... he was more experienced than me ...

            Please note that what I wrote in my reply to your comment was quite different. I never s

            • Please take a look at our presentation slides, it only takes a few minutes. Then you might have more specific questions on the implementation, which I'd be happy to answer.

              Yes, I stopped my arguments short because I detected I have a distinct lack of information and there's too many possibilities I'm becoming cognizant of to continue without reading up some more.

              ... he was more experienced than me ...

              Please note that what I wrote in my reply to your comment was quite different. I never said anything about your experience. Now that you raised this topic, I can say that you appear to be familiar with Unix security. You simply had not looked at our stuff before you wrote your comment, that's all.

              True, but my comment was more to illustrate that anyone can be wrong, regardless of who they are. I learn new stuff all the time. Ueshiba O-sensei said failure is the key to success, and each mistake teaches us something; if I seem to know something about anything it's because at one point I was wrong about someth

              • I fully agree with you that "anyone can be wrong".

                I also agree with your comments on a large percentage of CPU time typically being spent in shared libraries, and I agree that they're normally PIC anyway. So, yes, 6% slowdown on main program code when going PIE does not translate to a 6% slowdown of the entire system. We typically use Owl rebuilds from source as our benchmark, so this is likely what we will use to see the overall effect of going PIE as well (that is, run a second rebuild on a system alrea

    • Re: (Score:3)

      by Bert64 ( 520050 )

      Well, setuid binaries were required to exploit the ptrace kernel vulnerability from a few years back, as well as the more recent vulnerability in glibc... An already running daemon which is running as root would not be vulnerable to either of these exploits.

      On the other hand, i believe they use capabilities - that is rather than granting full root privileges ala setuid, you grant only the permissions a program needs... For instance listening daemons may only need root privileges to bind to ports below 1024,

      • On the other hand, i believe they use capabilities ...

        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).

      • ping/traceroute only need to be able to open a raw socket etc.

        Olaf Kirch's implementation of traceroute, which we use in Owl, does not need a raw socket. It uses Linux 2.4+ features (that is, they've been available in mainstream kernels for a decade) to do exactly what the usual LBNL traceroute did (send UDP packets, detect ICMP errors), only without requiring special privileges. We install it mode 755 and it just works for all users.

    • Yes, our distro doesn't encourage users to use su or sudo. The reason is that escalating privileges from a less privileged account to a more privileged account is bad from security standpoint. I found the following message in our mailing list. In this message Solar Designer explains the issue with su/sudo: http://www.openwall.com/lists/owl-users/2004/10/20/6 [openwall.com] An excerpt from the above message: "Presently, the only safe use for su is to switch from a more privileged account to a less privileged one (whene

      • Yes, our distro doesn't encourage users to use su or sudo. The reason is that escalating privileges from a less privileged account to a more privileged account is bad from security standpoint.

        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

        • Solardiz (and/or gm.outside):

          First, thanks for participating in this thread (and for submitting the article, and for making OWL).

          Second, the documentation on owl-control is very sparse; I can't even find an HTML-rendered version of its man page (as noted in my GGP [slashdot.org]) let alone a more detailed description of its features, uses, advantages, etc. It is obviously central to the security model of the system. Please reply to the GGP with a link to more detail on owl-control (assuming you have one) as assembli

          • Khopesh - you're welcome, and thank you for your constructive comments. We might create a FAQ for Owl based on the questions/comments we've received.

            Agreed re: insufficient documentation on owl-control. This is something for us to improve. Also add our own web interface to our man pages, like *BSD's have - frankly, this has been on my to-do list for years... but there was always something more important or/and more urgent.

            I have replied to your comment's GGP with the info you have requested.

      • If you can't su or sudo, how you get anything done?

        • If you can't su or sudo, how you get anything done?

          This depends on the task. If you are a local user and need root powers - switch your console to a fresh one and login as root. If you were talking about getting root powers on a remote host, the best practice is to ssh as root directly (given that you are behind a trusted terminal).

        • If you can't su or sudo, how you get anything done?

          We normally login directly as a root user for sysadmin tasks (e.g., r_john for a sysadmin named John) and also directly as a non-root user (e.g., john) for other tasks. This applies to both console and remote logins (ssh). This is the approach we've been using for years, and it works well for us.

          As I have mentioned, those who prefer the traditional su approach, despite of its added risks (including compromise propagation from a sysadmin's non-root account to root), may "control su wheelonly".

    • some sort of permissions escalation daemon ("owl-control" perhaps?)

      owl-control is merely a tool to ease system administration - change settings and have your changes persist over system upgrades. It is one of the nice security-related features of Owl, but it is NOT key to running a reasonable Owl system without SUIDs (this is achieved by other means - SGIDs and changes to various system components). owl-control is not what you thought it was (not a "permissions escalation daemon", but merely a set of scripts).

      I do agree with you that we need to present our documentation

    • You can view the formatted control(8) man page here:

      http://docs.altlinux.org/manpages/control.8.html [altlinux.org]

      (ALT Linux have imported owl-control for their distributions, and they have contributed some changes back to us. They also happen to have placed this man page on the web.)

      I'm afraid that this is not going to help you very much, though, because owl-control is very generic and abstract, and so is its man page. Perhaps we should add a few usage examples to illustrate owl-control's purpose.

      I'll try to explain w

  • Is this stuff important? (Score:1)

    by Anonymous Coward

    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.

    Of all the Linux vulnerabilities in the past few years, how many would have been stopped by this?

    These things sound nice, but I'm wondering if they are actually useful or if they are just security theater.

    • Of all the Linux vulnerabilities in the past few years, how many would have been stopped by this?

      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

  • News that matters.

    Next up, Microsoft/Symantec/Cisco security product and costs 10's of thousands more! Can't leave the point-and-click jui jitsu black belts out.

  • Dropping SUID doesn't improve security (Score:5, Informative)

    by fandingo ( 1541045 ) on Friday December 17, 2010 @04: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

    • > 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 c

    • > 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 associat

  • the Openwall website groans and moans imploring for a facelift. it's so poignant..
    • Wanna volunteer? :) Seriously, we wanted to update the site long time ago, but we are not good at web design and our team is too small and quite busy to spend time on something we aren't good at. From the pure technical point of view, the site provides all the necessary information we wanted it to provide. True, there are no whistles and bells, but every bit of info is there. We would appreciate any help with making our site better!

      • every bit of info is there

        Actually, there are at least two things I've been planning to add to the website (but we never got around to doing that): an interface to browse our man pages and another one to browse our packages (list and contents - at least the metadata). I don't know whether this is a higher priority than a mere facelift or not.

Slashdot Top Deals

Ocean: A body of water occupying about two-thirds of a world made for man -- who has no gills. -- Ambrose Bierce

Close