[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140927215110.GW23797@brightrain.aerifal.cx>
Date: Sat, 27 Sep 2014 17:51:10 -0400
From: Rich Felker <dalias@...c.org>
To: oss-security@...ts.openwall.com
Subject: Re: Re: CVE-2014-6271: remote code execution through
bash (3rd vulnerability)
On Fri, Sep 26, 2014 at 12:26:05PM -0600, Kurt Seifried wrote:
> On 26/09/14 12:12 PM, Rich Felker wrote:
> > On Fri, Sep 26, 2014 at 02:06:21PM +0100, Simon McVittie wrote:
> >>> Tell everyone to stop using setuid/setgid now and forever?
> >
> > Yes!
> >
> >> Minimizing use of setuid/setgid, and making sure the setuid/setgid
> >> things are suitably hardened, is a good idea. However, tools for
> >> controlled privilege escalation (sudo, pkexec, Apache suexec) rely on
> >> setuid in order to work. There's a reason the feature exists at all.
> >
> > These could all be done by having the process with root privileges
> > inherit them from a daemon parent that already has root, rather than
> > requiring the kernel to elevate the privileges of a process via the
> > setuid bit. This inherently eliminates all attacker control of the
> > process's initial state and limits the input/attack surface to the
> > communication channel clients have with the daemon (e.g. a single unix
> > socket).
>
> setuid/setgid is not just for root. For example the Postfix server makes
> use of various groups and setuid/setgid binaries and directories so that
> there are well defined interfaces between Postfix components that run
> with different privilege levels.
But the same could be achieved, with none of the risks of
setuid/setgid, via IPC to a daemon that already has the right
user/group.
Rich
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
