Would it be possible to change the USER_PATH or _PATH_STDPATH variables to not be defined at compile time which makes them get permanently built into the sshd binary. Instead make it a config option that could be changed post-install? One use of this is being able to make the software relocatable, except for the /etc (sysconfig) files, which would really help in some circumstances. It could be an option in the /etc/ssh/sshd_config file, similar to the Subsystem option for sftp. Currently you can just relocate it yourself as long as you make sure the PATH is set correctly elsewhere, but leaving the old built in path component there could be considered a security risk. ~Jason
Such an option exists: your shell initialisation files - /etc/profile, /etc/csh.cshrc, etc. I can't possibly imagine how using the system-defined path could be a security risk, unless the system itself is busted.
but /etc/profile is only sourced for interactive shells, i think. adding /etc/ssh/environment could help
About the shell initialization files: I MUST strongly disagree with this statement from both a security and system administration point of view. Your solution does not change the fact that the potentially dangerous/insecure path is still compiled into the sshd binary, plus it is the responsibility of the ssh subsystem to configure itself properly. This path is required by the ssh daemon so it can find its scp program, it should NOT be up to the sys admin to modify every possible shell config file to fix this potential problem and security hole. Also, editing one config file is much simpler than editing at least two (and maybe more) shell config files. Since sshd makes the requirement that it has to be able to find its scp program, it should be up to the ssh subsystem to solve the problem and not leave it to shell config files. I find your suggested solution totally unacceptable and ask that you think about this problem a little more. About /etc/ssh/environment: I did not see this mentioned in the ssh documentation/man pages, only the $HOME/.ssh/environment file. Will this always be read even if the user has the corresponding file in their home directory and will it override the PATH setting compiled into the sshd binary? ~Jason
> About the shell initialization files: I MUST strongly disagree with this > statement from both a security and system administration point of view. Your > solution does not change the fact that the potentially dangerous/insecure path > is still compiled into the sshd binary [..] from defines.h # define _PATH_STDPATH "/usr/bin:/bin:/usr/sbin:/sbin" My God.. if that is 'potentailly dangerous/insecure' then every UNIX in the world's default path is insecure. I am speaking as an admin. At worse it addes on $PREFIX/bin. To the *END* of the search path. And if you change it via --with-default-path (like what Redhat does to include /usr/local/bin FIRST which is lame) then you should should know what your doing. > [..], plus it is the responsibility of the ssh subsystem to configure > itself properly. This path is required by the ssh daemon so it can find > its scp program, it should NOT be up to the sys admin to modify every Subsystem != scp. Subsystem is a v2 feature that is *NOT* used by scp. If you want to ensure that the subsystem ALWAYS finds the RIGHT file.. FULLY path it out in the sshd_config. (Which is is by default: 'Subsystem sftp /usr/libexec/sftp-server'). Subsystem has *NOTHING* to do with scp. Do you see a 'Subsystem scp ..'? I sure don't. Pretty much what scp is doing is a 'ssh user@site scp [..]'. No subsystems here.. I'm sorry, but if you want to complain that there is is not a 'DefaultPATH' configuration directive do so (Better yet write up a simple patch and provide it). Just leave this dribble about 'security' out of it since it is a load of crap. But in any case I can tell you have not a CLUE as to what the difference between 'remote command exec' and 'subsystems'. You really should do your homework better before ranting.
Obviously you didn't read the beginning of this thread, the original submission was about the problem of making a relocatable package, possibly installing ssh in an unusual path, for example lets say /home/username/bin. That path will get added to _PATH_STDPATH and compiled into the sshd binary. Now install it somewhere else and that useless and potentially dangerous path will still be in the sshd binary, and on the new system, who knows what will be in there. Do you honestly believe that isn't a security problem? What I am complaining about is that I am NOT adding that path by hand, instead ssh's configure script decides all by itself that it MUST include that path to find scp, which is a completely WRONG assumption made by the configure script if the ssh package is relocated! Am I being clear enough now? And don't make assumptions when you start your rant. By subsystem I am being more general and referring to the ssh subsystem of a running computer system, ie. the ssh programs and their config files. The ssh configure script should NOT make assumptions about where it thinks its scp program will always be and compile that into the ssh daemon. And if you don't think having an incorrect and unnecessary path component compiled into a root level daemon is a potential security problem then I think you have more to learn about system administration and security.
Two things. 1. --with-default-path will disable OpenSSH adding in the $PREFIX/bin (we assume that since you are smart enough to set your own default path, you will be smart enough to know where you are putting scp). 2. 'subsystems' vs 'remote exec'. Use the right terms if you are going to argue for including a feature. Otherwise it makes you look like you've not bothered to learn the product. No, I still don't feel this is a security hole unless you are doing stupid things like --with-prefix=/home/user/ while building your package. And if you are then we can not do much stop you from doing stupid things. =) And I have nothing against something called 'DefaultPATH'.. I do have something against people shouting the sky is falling. As I said.. drop the 'It is a security issue', provide a patch, and show that /etc/profile, /etc/ssh/enviroment, etc are not valid generic solutions. Relocatable packages are problematic at best depending on the web of dependancies.
> 1. --with-default-path will disable OpenSSH adding in the $PREFIX/bin (we > assume that since you are smart enough to set your own default path, you will > be smart enough to know where you are putting scp). That will only solve one of the problems, having the incorrect path compiled into the sshd binary, not how sshd will be able to find scp if it has been moved or installed somewhere unusual. > 2. 'subsystems' vs 'remote exec'. Use the right terms if you are going to > argue for including a feature. Otherwise it makes you look like you've not > bothered to learn the product. I am not responsible for your misunderstanding me and going on a rant. Maybe I should have been a little more clear, but you do not have to assume I mean something else by subsystem and imply that I am an idiot. > No, I still don't feel this is a security hole unless you are doing stupid > things like --with-prefix=/home/user/ while building your package. And if > you are then we can not do much stop you from doing stupid things. =) That path was just an example. Just because you can't think if a way to take advantage of a vulnerability doesn't mean the current method is 100% safe. Also try to remember that not everyone installs software in the "standard" places, some sites might have other requirements. Do you agree that a system with the smallest number of vulnerabilities is more secure? Why would you advocate adding a directory to the path just so a daemon can find one file? Is that really being minimal? > And I have nothing against something called 'DefaultPATH'.. I do have > something against people shouting the sky is falling. As I said.. drop the > 'It is a security issue', provide a patch, and show that /etc/profile, > /etc/ssh/enviroment, etc are not valid generic solutions. So I guess no one ever uses ssh to login as root to do remote system administration then? You know for sure that there is absolutely no security risk with the current design then? And root doesn't have to worry about what sshd decides to stick in it's path just because it thinks scp is somewhere? Like I said before, the simplest and correct solution is to have a config option that tells sshd where scp is, instead of adding another directory to the path that the user might not need. This might not be a problem if ssh is being installed in a usual place like /usr or /usr/local, but try to think of the more general case where some site decides to install it somewhere you never thought of. /etc/profile is NOT the appropriate place to put this path, it is only an ugly kludge to fix the real problem, especially when it might only be needed so sshd can find one thing (scp). Why should the sys admin have to add that path to the general system shell config scripts, and have to make sure all possible scripts are correct, just because sshd can't find something without it? It should be the responsibility of sshd to configure this since it needs to know about it. And about patches, tell me why I should waste my time writing a patch when my suggestion has been shot down from the very beginning and negatively criticized over and over. If you want people to contribute patches to an opensource project then you should have an open mind and treat them with respect. Again, try to look at the more general case, not just the "normal" install everything in /usr case. I think you will see that the current design is not the best possible one. > Relocatable packages are problematic at best depending on the web of > dependancies. I know about the problems with relocatable packages, but ssh is fairly simple, just a few executables, some documentation and a few config files. Built correctly, it should be easily relocatable except for one or more of the config files. ~Jason
% grep _PATH_DEFPATH /usr/include/paths.h #define _PATH_DEFPATH "/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin" i don't see why it's insecure to use this path.
"the simplest and correct solution is to have a config option that tells sshd where scp is" that's very wrong. sshd should not know about scp at all. it has nothing to do with scp. if scp is not in the default path, then your setup is broken. if there are dangerous things in the default path, then the default path is wrong or your system is broken.
His issue stems from two things. 1. portable may add a $PREFIX/bin if --with-default-path is not used and $PREFIX != /usr 2. He seems to think that one can magicly detect we are doing a 'scp' and handle it via some magic. What he forgets is that END USERS also need to be able to type 'scp' at the prompt to run the command. So either we add the path to an internal default path or to a 'commonly used' configuration file (/etc/profile, /etc/ssh/enviroment, etc). <shrug> That is my last 0.02c on the issue since it is pointless.
> % grep _PATH_DEFPATH /usr/include/paths.h > #define _PATH_DEFPATH > "/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin" > > i don't see why it's insecure to use this path. Where did I ever mention _PATH_DEFPATH? Your point here is completely irrelevent to what I was talking about. > "the simplest and correct solution is to have a config option > that tells sshd where scp is" > > that's very wrong. sshd should not know about scp at all. > it has nothing to do with scp. If sshd is going to execute scp on behalf of the user because of a remote scp command, then you are wrong, it should know exactly what it is executing and from where. It should NOT rely on the user to have setup their path correctly. If you are talking about an interactive shell then you are correct. But these are two completely different cases!
sshd should not know where 'ls' is stored. sshd should not know where 'pwd' is stored. sshd should not know where 'scp' is stored. sshd must rely in the path, since it does not know that there is a 'ls', a 'pwd' or a 'scp' binary. sshd does not rely on the user setting up the path. sshd relies on the admin to setup the path correctly, and the path set by the admin has to be trusted.
Mass change of RESOLVED bugs to CLOSED