[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20110905012403.GC31987@openwall.com>
Date: Mon, 5 Sep 2011 05:24:03 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: [Pkg-xfce-devel] Bug#639151: Bug#639151: Bug#639151: Local privilege escalation
On Mon, Aug 29, 2011 at 01:40:16PM +0200, Yves-Alexis Perez wrote:
> By the way, would you know some kind of lib for ???safe privileges
> dropping??? for that kind of usage. I quickly looked at glib and while
> they do have some primitives for process spawning, there's nothing
> related to dropping privs. It looks like something which might be
> useful.
No, I am not aware of a generic library with functionality like that.
Additionally, while effective credentials switching for accessing users'
files feels like the obvious best thing to do in a program, things are
less obvious when you need to do that from a library. One issue is
threads. Switching only fsuid/fsgid/groups or switching
euid/egid/groups with direct kernel syscalls (not thread-aware at least
on Linux) rather than with library functions (thread-aware at least on
glibc) helps with this (but is non-portable or makes assumptions).
But then what about signals? Signal handlers installed by the main
program or by other libraries may not expect to be invoked with
temporarily changed effective credentials. Should our library block all
signals before it switches credentials, then unblock after it has
restored the old credentials? Maybe. But this does get complicated,
dirty, risky.
To give credit where it's due, the above concern regarding signals
originates (for me) from an off-list discussion I had with Rich Felker -
the author of musl, a new lightweight libc for Linux:
http://www.etalabs.net/musl/
In Openwall's "tcb suite" (specifically, in libtcb, which is used by
libnss_tcb), we switch fsuid/fsgid/groups before accessing
/etc/tcb/*/shadow files, because the /etc/tcb/* directories have users
as their owners:
http://www.openwall.com/tcb/
We don't block/unblock signals.
musl supports our tcb password shadowing scheme too, but instead of
credential switching, it takes precautions when accessing those files as
root. Either approach has its pros and cons. I've already mentioned
the signals issue with credential switching. And an issue with trying
to access files as root safely is that even when you do everything you
can, a race condition remains: an attacker may replace the file to read
with a hard link to a tape device, which would rewind the tape on
open(2). (There might be other devices with side-effects on open, too.)
Arguably, this is purely theoretical and thus acceptable. I'd say it's
more acceptable when accessing /etc/tcb/*/shadow than when accessing
dot-files in a user's home directory, because /etc/tcb (this directory
itself) is normally root:shadow, mode 710, so it'd take a group shadow
compromise before this DoS attack may be attempted.
I hope these examples are helpful, and I hope you don't mind me plugging
these two pieces of software. ;-)
Alexander
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.
