Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 30 Jul 2012 11:52:21 +0200
From: Ludwig Nussel <>
Subject: Re: libdbus hardening

Florian Weimer wrote:
> On 07/30/2012 10:59 AM, Ludwig Nussel wrote:
>> Florian Weimer wrote:
>>> On 07/17/2012 12:08 PM, Florian Weimer wrote:
>>>> Note that GNU libc will likely change the name to secure_getenv.
>>>> Upstream does not want to document __secure_getenv as-is.
>>> This will be part of glibc 2.17.  autoconf instructions are available here:
>>> <>
>> Now the next step would be to make glibc automatically use secure_getenv
>> when running setuid root and require programs to explicitly call
>> insecure_getenv() or something like that :-)
> You're welcome to absorb the transition costs. 8-) I looked into this
> briefly, and the potentially insecure getenv calls are not in the
> majority, so we'd have to expect quite a bit of breakage, or at least
> add a configurable whitelist of variable names in a file in /etc.

Potential breakage would only occur in setuid programs that actually use
getenv for valid purposes though. I wonder how many of those actually

> FWIW, I consider PAM and NSS (Name Service Switch) the major problem
> areas, too.  Do you know if the APIs would allow confining plug-ins to
> subprocesses?  Then we only have to solve the transparent child
> process problem.

No idea. I'd probably rather implement the setuid binary itself as
client/server program and get rid of setuid in the first place instead
of trying to play tricks in PAM though.


 (o_   Ludwig Nussel
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imend├Ârffer, HRB 16746 (AG N├╝rnberg) 

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.