Re: Why is su preserving the environment?

2009-01-24 Thread Steve Langasek
On Sat, Jan 24, 2009 at 08:41:37AM +0100, Josselin Mouette wrote:

 it has been brought to my attention (through #512803) that su does not
 clean the environment at all. This has several security implications:
   * variables like PERL5LIB or GTK_MODULES can be passed to another
 user, leading to unwanted execution of code;
   * variables like DBUS_SESSION_BUS_ADDRESS or XDG_SESSION_COOKIE
 export authentication information that could be used to obtain
 private information such as passwords in gnome-keyring.

 Before I work around this specific issue in the fugliest way, shouldn’t
 we prevent su from preserving the environment?

 There have been several security advisories related to sudo not cleaning
 the environment, and the final call has been to make env_reset the
 default. Is there any reason why su should not be considered vulnerable
 the same way?

Because su does not attempt to control what commands are being run; if you
can su to another user, you can run arbitrary commands as that user, which
means there's no sense in trying to filter the environment.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Re: Why is su preserving the environment?

2009-01-24 Thread Reinhard Tartler

Josselin Mouette j...@debian.org writes:

 it has been brought to my attention (through #512803) that su does not
 clean the environment at all. [... ] 

 Before I work around this specific issue in the fugliest way, shouldn’t
 we prevent su from preserving the environment?

compare this:

 su -c env

to

 su -c env -


the latter command indeed prunes the environment, and calling

 su -c gnome-terminal -

sucessfully fails (heh) with failing to open a display. whats the
problem here?

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Re: Why is su preserving the environment?

2009-01-24 Thread Josselin Mouette
Le samedi 24 janvier 2009 à 09:04 +0100, Reinhard Tartler a écrit :
 the latter command indeed prunes the environment, and calling
 
  su -c gnome-terminal -
 
 sucessfully fails (heh) with failing to open a display. whats the
 problem here?

su - is actually pruning the environment as it starts a login shell.
This should be slightly orthogonal to preserving the environment.
Actually, su -p - *does* preserve it. When not starting a login shell,
the -p option does actually nothing (and the documentation doesn’t
mention this).

I think Steve has a point, and as he explains, this is not a big
security issue; however it is breaking the expectations you have when
logging as another user. For example, it is not expected that starting
an application as the other user will re-use the running one, and it is
not expected that accessing the GNOME keyring will show the passwords of
the original user.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée


Re: Why is su preserving the environment?

2009-01-24 Thread Christoph Moench-Tegeder
## Josselin Mouette (j...@debian.org):

 I think Steve has a point, and as he explains, this is not a big
 security issue; however it is breaking the expectations you have when
 logging as another user. For example, it is not expected that starting
 an application as the other user will re-use the running one, and it is
 not expected that accessing the GNOME keyring will show the passwords of
 the original user.

That behaviour is well decumented in the manpage (at least on my
Debian systems)... The current environment is passed to the new shell.
Assumptions is the mother of all screwups, especially when using
mighty tools without reading the docs :)

Regards,
Christoph

-- 
Spare Space


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Re: Why is su preserving the environment?

2009-01-24 Thread Josselin Mouette
Le samedi 24 janvier 2009 à 11:00 +0100, Reinhard Tartler a écrit :
 Well, then how about gnome-keyring or other applications not expecting
 that behaviour should then check the effective user id in addition to
 the session cookie in the environment variable?
 
 In any case, this behaviour should probably be somewhere properly
 documented, at least in the developer and/or user documentation of
 gnome-keyring (I have to admit that I didn't check it myself, since I
 haven't developed an application which uses gnome-keyring yet).

It’s not a problem in gnome-keyring, gnome-terminal or another
application. I don’t think it even lies in D-Bus which is responsible
for the passing of these authentication tokens.

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.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée


Re: Why is su preserving the environment?

2009-01-24 Thread Matthew Johnson
On Sat Jan 24 11:00, Reinhard Tartler wrote:
 Josselin Mouette j...@debian.org writes:
 
  I think Steve has a point, and as he explains, this is not a big
  security issue; however it is breaking the expectations you have when
  logging as another user. For example, it is not expected that starting
  an application as the other user will re-use the running one, and it is
  not expected that accessing the GNOME keyring will show the passwords of
  the original user.
 
 Well, then how about gnome-keyring or other applications not expecting
 that behaviour should then check the effective user id in addition to
 the session cookie in the environment variable?
 
 In any case, this behaviour should probably be somewhere properly
 documented, at least in the developer and/or user documentation of
 gnome-keyring (I have to admit that I didn't check it myself, since I
 haven't developed an application which uses gnome-keyring yet).

Well, if they are using DBUS this should be fine. You cannot connect to
a session bus with a uid other than the one it is running as (including
root)

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature


Re: Why is su preserving the environment?

2009-01-24 Thread Arthur de Jong
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.

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part


Re: Why is su preserving the environment?

2009-01-24 Thread Josselin Mouette
Le samedi 24 janvier 2009 à 10:05 +, Matthew Johnson a écrit :
 Well, if they are using DBUS this should be fine. You cannot connect to
 a session bus with a uid other than the one it is running as (including
 root)

Clearly that’s not the case, since the original issue happens over
D-Bus. In this case, not for authentication, but clearly the application
launched as root can connect to the session bus.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée


Re: Why is su preserving the environment?

2009-01-24 Thread Matthew Johnson
On Sat Jan 24 14:08, Josselin Mouette wrote:
 Le samedi 24 janvier 2009 à 10:05 +, Matthew Johnson a écrit :
  Well, if they are using DBUS this should be fine. You cannot connect to
  a session bus with a uid other than the one it is running as (including
  root)
 
 Clearly that’s not the case, since the original issue happens over
 D-Bus. In this case, not for authentication, but clearly the application
 launched as root can connect to the session bus.

Well, clearly something else is going on because root can't connect to the
session bus here, this is on Lenny. I'm also part of DBus upstream and AFAIK
this part of the security policy has not changed:

 =0 [mjj29] $ dbus-launch --sh-syntax
DBUS_SESSION_BUS_ADDRESS='unix:abstract=/tmp/dbus-NcM9i9iZek,guid=c8396b814246d79f7bc863b6497b356d';
export DBUS_SESSION_BUS_ADDRESS;
DBUS_SESSION_BUS_PID=12888;
 =0 [mjj29] $ 
DBUS_SESSION_BUS_ADDRESS='unix:abstract=/tmp/dbus-NcM9i9iZek,guid=c8396b814246d79f7bc863b6497b356d';
 =0 [mjj29] $ export DBUS_SESSION_BUS_ADDRESS;
 =0 [mjj29] $ DBUS_SESSION_BUS_PID=12888;
 =0 [mjj29] $ dbus-monitor
signal sender=org.freedesktop.DBus - dest=:1.0 path=/org/freedesktop/DBus; 
interface=org.freedesktop.DBus; member=NameAcquired
   string :1.0
method call sender=:1.0 - dest=org.freedesktop.DBus 
path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string type='method_call'
method call sender=:1.0 - dest=org.freedesktop.DBus 
path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string type='method_return'
method call sender=:1.0 - dest=org.freedesktop.DBus 
path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string type='error'
^C
 =130 [mjj29] $ su
Password: 
qadesh:/home/mjj29# echo $DBUS_SESSION_BUS_ADDRESS 
unix:abstract=/tmp/dbus-NcM9i9iZek,guid=c8396b814246d79f7bc863b6497b356d
qadesh:/home/mjj29# dbus-monitor
Failed to open connection to session message bus: Did not receive a reply. 
Possible causes include: the remote application did not send a reply, the 
message bus security policy blocked the reply, the reply timeout expired, or 
the network connection was broken.
qadesh:/home/mjj29# 


-- 
Matthew Johnson


signature.asc
Description: Digital signature


Re: Why is su preserving the environment?

2009-01-24 Thread Reinhard Tartler
Josselin Mouette j...@debian.org writes:

 I think Steve has a point, and as he explains, this is not a big
 security issue; however it is breaking the expectations you have when
 logging as another user. For example, it is not expected that starting
 an application as the other user will re-use the running one, and it is
 not expected that accessing the GNOME keyring will show the passwords of
 the original user.

Well, then how about gnome-keyring or other applications not expecting
that behaviour should then check the effective user id in addition to
the session cookie in the environment variable?

In any case, this behaviour should probably be somewhere properly
documented, at least in the developer and/or user documentation of
gnome-keyring (I have to admit that I didn't check it myself, since I
haven't developed an application which uses gnome-keyring yet).

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org