| |||||||||||||
OpenWall 3.0OpenWall 3.0Posted Dec 23, 2010 21:49 UTC (Thu) by smoogen (subscriber, #97)Parent article: Linux capabilities support for user namespaces
As a Fedora person, I just wanted to point out that there may have been a setuid-less OS shipped before Fedora 15. The openwall project released their 3.0 on December 10th which states that their default install does not have setuid but some setgid programs. I don't know if they are using capabilities or not (have it on my after Xmas list of things to check out) but thought it should be noted.
(Log in to post comments)
OpenWall 3.0 Posted Dec 23, 2010 22:03 UTC (Thu) by smoogen (subscriber, #97) [Link]
And in reading the next section I see they have instead implemented kernel fixes to allow for setgid programs to open icmp versus capabilities.
OpenWall 3.0 Posted Jan 6, 2011 16:23 UTC (Thu) by solardiz (guest, #35993) [Link]
ping is a special case. For everything else, we made purely userland changes to eliminate the need for having any SUID programs. You may want to check out these links:
http://www.openwall.com/tcb/
also mentioned in the "next section" that you referred to:
OpenWall 3.0 Posted Jan 6, 2011 16:38 UTC (Thu) by solardiz (guest, #35993) [Link]
Also, this description - "kernel fixes to allow for setgid programs to open icmp" (from your comment) - is not entirely correct. What we're proposing on LKML is adding non-raw ICMP sockets (where one can only send certain things and receive certain relevant responses). This is not the same as permitting some programs to access the existing (raw) ICMP sockets. And this is post-Owl-3.0 stuff; on our 3.0 release, we left out the ping special case (ping is simply restricted to invocation by root by default, although this is configurable; our traceroute works as non-root fine).
Overall, Owl 3.0 is primarily about the hardened userland. We do not use filesystem capabilities, and our userland is usable with mainstream kernels (although we do provide and recommend a specific RHEL5/OpenVZ patched kernel). In fact, some people are running our userland in OpenVZ containers on non-Owl host systems (we provide pre-created OpenVZ templates of the userland), although we generally use Owl for both "host" and "guest" ourselves.
suid less os's. Posted Dec 24, 2010 5:59 UTC (Fri) by ebiederm (subscriber, #35028) [Link]
Sigh plan 9 did this years ago; without suid, without sgid, and without capabilities.
Linux has all of the capabilities plan 9 did, so going suidless without caveats is possible if someone would care.
Frankly being able to raise the priveleges of an existing process is such a dangerous mechanism and so limiting on system design that I wish someone would care, and remove all suid, sgid, and capabilities use from a distro. It is hard to count how many neat new features have been shelved because of the requirement to support suid root executables.
suid less os's. Posted Jan 5, 2011 12:13 UTC (Wed) by michaeljt (subscriber, #39183) [Link]
> Sigh plan 9 did this years ago; without suid, without sgid, and without capabilities.
I'm no expert on Plan 9, but from a bit of quick googling it looks to me like it had local server processes to do privileged things for other processes that didn't have the rights to do them themselves. Which sounds rather like DBus/PolicyKit to me.
OpenWall 3.0 Posted Dec 26, 2010 22:42 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
I don't really understand all this setuidless craziness.
Sure, having setuid on 'ping' is crazy, but having setuid bit on 'sudo' is downright logical.
OpenWall 3.0 Posted Jan 6, 2011 17:01 UTC (Thu) by solardiz (guest, #35993) [Link]
Having sudo and allowing for the use of su to elevate privileges is downright illogical in most cases (on servers, which is what Openwall GNU/*/Linux is for). Here are some excerpts from past discussions on the topic:
http://www.openwall.com/lists/owl-users/2004/10/20/6
The alternative to the su/sudo approach is direct root logins. And the solution to the accountability problem (with multiple sysadmins) is multiple root-privileged accounts (with a distinct naming convention for clarity).
Occasional exceptions do exist. In our experience, less than 10% of server systems would potentially benefit from sudo, and a safer approach can be used on those anyway: we generally prefer ssh forced commands - that is, command=... in authorized_keys - even if this is to be invoked by a local account on the system itself, such as by a support person who is not a "full" sysadmin.
OpenWall 3.0 Posted Jan 6, 2011 17:15 UTC (Thu) by solardiz (guest, #35993) [Link]
As to the "setuidless craziness" in general, it makes more sense once you actually have no SUID programs(*) left on the system - like we do not on a default install of Owl 3.0. This mitigates the impact of potential vulnerabilities in parts of ld.so, libc, and the kernel. Relevant vulnerabilities in each one of these components have been discovered (and fixed) in the past, and more are to be introduced/discovered/fixed.
(*) ...nor any similarly-privileged-on-exec programs, such as with fscaps with a root-equivalent capability set. We do not use fscaps in Owl 3.0.
|
|||||||||||||