This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Allowing users to change execvpâs shell?


On Sun, Dec 16, 2012 at 12:41:03PM +0100, Ludovic CourtÃs wrote:
> Hi,
> 
> In the context of GNU Guix, Iâm pondering a change that would allow
> users to change the shell used by âexecvpâ (more details about the
> rationale at <http://thread.gmane.org/gmane.linux.distributions.nixos/9748>),
> along these lines:

This sounds like a purely harmful "feature". Normally, the shell won't
even be invoked directly by execvp; the #! at the beginning of the
script will be processed by the kernel. The shell is only relevant if
this fails, which is unlikely to happen in the real world at all.

> I wonder what security implications it may have.

Very bad.

> On GNU/Hurd, relying on a hard-coded /bin/sh doesnât provide any
> guarantee because users are free to choose the file system root of every
> process they launch.  So checking for an environment variable is no worse.

Presumably changing the fs root is forbidden if it's suid or
equivalent. Otherwise Hurd has a massive inherent vuln.

> On GNU/Linux, only root (or a user with CAP_SYS_CHROOT or CAP_SYS_ADMIN)
> can use chroot(2) and mount(2), so /bin/sh is likely to be what the
> adminâs want it to be.  OTOH, tweaking $GLIBC_SHELL doesnât seem worse
> than tweaking $PATH.

It is much worse, because programs can unset or replace $PATH before
calling execvp and thus make it secure. Many shell scripts actually do
this. They have no way of knowing that they would also need to unset
or change your proposed nonstandard environment variable.

> Thereâs the issue of setuid-root binaries.  Then again, I wonder if
> these should be using execvp at all in the first place.

They can use it securely as long as they set $PATH first.

Beyond the specific situation here, adding environment variables that
change libc behavior is almost certainly a source of security
problems. They definitely should not be added on a whim, and I would
go so far as to say they should not be added at all.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]