Re: Why is su preserving the environment?
On Sat, 24 Jan 2009, Arthur de Jong wrote:
> On Sat, 2009-01-24 at 11:07 +0100, Josselin Mouette wrote:
> > The question is whether we can consider safe to pass authentication
> > tokens as environment variables. Either we do, and we fix applications
> > that pass environment where they shouldn???t. Either we don???t, and we have
> > to find another way to pass them.
> You can easily get the environment of a process (of when the process
> started or the actual value depending on the application) by giving ps
> the e option.
> It seems this information is from /proc/<pid>/environ but I don't think
> all *nixes properly protect the environment. So in general I would say
> not to put authentication tokens into the environment.
> However, most applications that do something like that put a reference
> to the authentication token in the environment (e.g.
> XAUTHORITY=/tmp/.gdm0QI8NZ) which is ok as long as the access to the
> real token (socket mostly) is protected.
Agreed. Authentication tokens in the environment have been banned as an
acceptable practice from a security standpoint for a long time, now.
They're immediately visible in way too many systems, and almost always the
environment is considered public anyway and it is not subject to any kind of
auditing, let alone access control...
The other thing you absolutely must not do is to have autentication tokens
anywhere in command lines, for the same reasons.
There are two main safe paths to pass along authentication tokens: by
reference to protected files, or directly through open fds shared by the
processes (only works on parent/children stuff), through private pipes or
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot