On 29/08/15 17:50, Rainer Weikusat wrote:
Tobias Hunger <tobias.hun...@gmail.com> writes:
On Sat, Aug 29, 2015 at 3:48 PM, Rainer Weikusat
<rainerweiku...@virginmedia.com> 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@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Hi Rainer, do you know that you are feeding a troll ?
tobias.hun...@gmail.com appears to be a systemd developer
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
