Allowing users to change execvp’s shell?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Allowing users to change execvp’s shell?

Ludovic Courtès-3
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:


--- a/posix/execvpe.c
+++ b/posix/execvpe.c
@@ -34,7 +34,7 @@ internal_function
 scripts_argv (const char *file, char *const argv[], int argc, char **new_argv)
 {
   /* Construct an argument list for the shell.  */
-  new_argv[0] = (char *) _PATH_BSHELL;
+  new_argv[0] = getenv ("GLIBC_SHELL") ? : (char *) _PATH_BSHELL;
   new_argv[1] = (char *) file;
   while (argc > 1)
     {


I wonder what security implications it may have.

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.

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.

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

WDYT?

Thanks,
Ludo’.
Reply | Threaded
Open this post in threaded view
|

Re: Allowing users to change execvp’s shell?

Rich Felker
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
Reply | Threaded
Open this post in threaded view
|

Re: Allowing users to change execvp’s shell?

Ludovic Courtès-3
Hi,

Thanks for the quick feedback.

Rich Felker <[hidden email]> skribis:

> On Sun, Dec 16, 2012 at 12:41:03PM +0100, Ludovic Courtès wrote:

[...]

>> 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.

Right, I was talking about non-setuid programs.

>> 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.

Well, sure.

>> 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.

Yeah.

To me it sounds like: $GLIBC_SHELL would be a new loophole in addition
to $PATH, but $PATH is a familiar one and people are used to fiddling
with it.

In general, authenticating programs based on their *name* seems highly
suspicious to me.  That’s certainly one of the reasons for depriving
unprivileged users from the right to chroot(2) or mount(2).

(That also raises the issues like: can programs authenticate their
computing environment?  Do they have any choice other than to trust it?)

Thanks,
Ludo’.
Reply | Threaded
Open this post in threaded view
|

Re: Allowing users to change execvp’s shell?

Rich Felker
On Sun, Dec 16, 2012 at 11:14:47PM +0100, Ludovic Courtès wrote:

> >> 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.
>
> Yeah.
>
> To me it sounds like: $GLIBC_SHELL would be a new loophole in addition
> to $PATH, but $PATH is a familiar one and people are used to fiddling
> with it.

Not only new but nonstandard. That's the problem. Do you expect every
program to be aware of the nonstandard security-compromising behavior
of every single system out there? That's why it's not acceptable to
add such security-compromising behavior.

> In general, authenticating programs based on their *name* seems highly
> suspicious to me.  That’s certainly one of the reasons for depriving
> unprivileged users from the right to chroot(2) or mount(2).

Yes, the whole design of setuid binaries is fundamentally a mistake;
they should be replaced with non-suid binaries which operate by
communicating with a daemon that already has the appropriate
privileges. But now we're talking about an imposing policy to change
the (bad) status quo, and nobody has the authority to do that. Maybe
20 years from now when people have abandoned such stupid designs as
suid binaries it would be no problem to add such a feature, but glibc
has no business imposing such a change since the status quo, as
ill-designed as it is, does permit one to build secure systems as long
as the rules are followed.

Rich
Reply | Threaded
Open this post in threaded view
|

Re: Allowing users to change execvp’s shell?

Florian Weimer-5
In reply to this post by Ludovic Courtès-3
On 12/16/2012 12:41 PM, Ludovic Courtès wrote:

> 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>),

Frankly, I don't see how changing glibc fixes your problem.  Could you
elaborate?  It's certainly odd to change libc because the file system
layout is not what is expected.

--
Florian Weimer / Red Hat Product Security Team