Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 23 Aug 2013 14:33:19 +0200
From: Ludwig Nussel <>
Subject: Re: [PATCH] implement privmode support in dash

Simon McVittie wrote:
> On 22/08/13 18:59, Tavis Ormandy wrote:
> After researching this sort of thing a bit a few months ago, I'm of the
> opinion that any set*id executable that doesn't filter its environment
> through a whitelist is Doing It Wrong.

I'd go one step further and claim that anyone using a setuid program to
solve anything is doing it wrong in the first place :-)

> Unfortunately, many set*id executables don't do that: notably, many
> su(8) implementations call into PAM (and hence into arbitrary
> distribution- or sysadmin-chosen libraries) with a caller-supplied
> environment. I think sudo might do the same, but it wasn't clear to me.

That's kind of mandatory. Some pam modules rely on having access to the
calling user's environment (pam_xauth or pam_krb5 for example IIRC).

> I asked the PAM mailing list what their security policy is[1] but
> haven't seen any reply so far.

I doubt there is any policy. Has PAM evolved at all the last few years?

Wrt su IMHO replacing that setuid binary with an implementation that
uses a client/server model (think of a local ssh) is long overdue.
su (and sudo) as is just doesn't fit into todays world anymore. The
security issues are just one symptom of that.


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