Tobias Hunger <tobias.hunger@???> writes:
> On Sat, Aug 29, 2015 at 3:48 PM, Rainer Weikusat
> <rainerweikusat@???> wrote:
>> 'su' is a somewhat generic setuid-0 program: It changes the uid and the
>> gids associated with itself to the ones for a certain user and then
>> executes a shell. In addition to that, it contains another "random
>> environment munger" with features someone happend to consider useful for
>> the su use cases he envisioned. If this happens to be what enables
>> someone else to achieve something he wanted to achieve, 'su' can
>> obviously be used for that. If not, then not. But the reason why su is
>> only of limited usefulness is not because the hardcoded policy isn't
>> complicated enough to include
>>
>> $random_thing_someone_called_lennart_also_wants
>>
>> for every conceivable value of the variable but because it has a
>> hardcoded policy at all and the solution is not "implement another,
>> random environment munger more to tastes of ..." but split it apart:
>
> That is exactly what systemd implemented:

No, that's not "exactly what systemd implemented", as

> The uid/gid gets changed and then you get exactly the same environment
> that gets set up for you during login.

and I wasn't writing about emulating/ simulating a "login environment"
(BTW, what's that?) for the sake of doing so. Pretty much the opposite,
actually: Instead of a "new and improved" hard-coded policy someone
associated with the 'shadow password suite' happened to dream up, get
rid of the policy altogether.

>> Have a program which changes uids and gids and executes another
>> program. Another program for the become root via setuid and execute
>> ... part. And a third program (or any number of such programs) to
>> perform other modifications of the execution environment.
>
> So you have to worry about users sneaking in a "muncher" (e.g. by
> manipulating PATH, LD_PRELOAD or whatnot) that will be run with the
> new uid/gid and can attack the user and system to its hearts content.

*If* manipulating the environment (here supposed to refer to "what
environ points to") in a certain way is considered necessary, programs
doing that can be employed, eg (I didn't need these two particular tools
so far so this is sort-of a demo):

--- kill-env.c -----
#include <unistd.h>
#include <stdio.h>

extern char **environ;

int main(int argc,  char **argv)
{
    environ = NULL;
    execv(argv[1], argv + 1);

    perror("execv");
    return 1;
}
--------------------

---- set-path.c ----
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(int argc, char **argv)
{
    int rc;

    rc = setenv("PATH", argv[1], 1);
    if (rc == -1) {
    perror("setenv");
    exit(1);
    }

    execvp(argv[2], argv + 2);

    perror("execv");
    return 1;
}
--------------------

Assuming both programs have been compiled into binaries named in the
indicated way and reside in the current directory, they could be used
like this:

[rw@doppelsaurus]/tmp#./kill-env ./set-path /usr/bin env
PATH=/usr/bin

A real 'environment initialization program' should probably support
reading the environment from a file and another which interprets some of
its arguments as name-value pairs could be useful, too. A complete command
could then look like this:

/bin/replace-env /etc/daemon-env set-env USER blafasel TERM vt100 -- env

NB: This approach is not intended to be convenient for interactive use, it
should just also enable that. It's supposed to enable creating complex
'process startup commands' by combining simple parts.

NB^2: I'm also absolutely not concerned with "fork and exec overhead"
unless there's an actual use case I need to handle where it demonstrably
makes a relevant difference.