Vincent Lefevre <vincent-...@vinc17.net> writes:
> How can this be possible? Do you mean that OpenSSH starts the command
> with bash instead of some exec* function or /bin/sh (which is dash on
> my machines)?
OpenSSH uses the login shell for the user, from session.c:
/*
* Execute the command using the user's shell. This uses the -c
* option to execute the command.
*/
argv[0] = (char *) shell0;
argv[1] = "-c";
argv[2] = (char *) command;
argv[3] = NULL;
execve(shell, argv, env);
perror(shell);
exit(1);
So an svn+ssh installation can be secured by ensuring that the command
"svnserve -t" is forced and the corresponding login shell is not bash.
Subversion cleans the environment before invoking hooks so any hooks
invoked by svnserve are safe even if those hooks use bash.
A patch to add a no-user-shell option to OpenSSH has been suggested:
http://www.openwall.com/lists/oss-security/2014/09/25/41
However if there is no shell then OpenSSH either has to parse the
command itself, which is non-trivial, or there is a restriction that no
parameters are passed to the executable, or there has to be a way of
specifying executable and parameters separately.
There is a similar driver in Subversion: a shell is used when invoking
the arbitrary, used-defined, --editor-cmd/SVN_EDITOR string so that
Subversion does not have to parse it. This is different from hooks
where a direct exec is used.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
