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 sockets. -- 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 Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why is su preserving the environment?
Le samedi 24 janvier 2009 à 15:39 +, Matthew Johnson a écrit : 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: You are pretty damn right. I thought it was a general D-Bus issue since bonobo uses the session bus address, but it only uses it to define a lock file for ORBit. So the problem actually lies in libbonobo - which makes it much less important in scope. Thanks for your insight. (I still think we shouldn’t keep such environment variables in processes started with su, but given the other reactions I’m not willing to argue more on this.) Cheers, -- .''`. : :' : 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?
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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why is su preserving the environment?
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?
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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Why is su preserving the environment?
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?
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?
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?
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?
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?
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-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
