On 29/08/15 17:50, Rainer Weikusat wrote:
> 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.
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Hi Rainer, do you know that you are feeding a troll ?
tobias.hunger@??? appears to be a systemd developer
::
Re: [DNG]
The show goes on: “su” c…
