Re: Allowing users to change execvpâs shell?

[ludo at gnu dot org (Ludovic CourtÃs)]

Hi,

Thanks for the quick feedback.

Rich Felker <dalias@aerifal.cx> 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â.