← Back to context

Comment by cryptonector

7 years ago

That has security considerations when spawning a process to run an executable that gets privilege on exec (think set-uid on Unix).

10 comments

cryptonector

Reply
Dylan16807  7 years ago

Easy to deal with by not applying privileges until the parent is done tinkering and hits start.

  • cryptonector  7 years ago

    I don't see how. The privilege elevation mechanism cannot apply to an already-running process, since then there will be a way to subvert the process.

    Now, the better answer to that is to have nothing like a set-uid mechanism, which would be nice, for sure. But just how much violence are we to do to the Unix model, and when are we expected to finish this? It's not like Linux can be abandoned -- for better or worse, Linux "won".

    • eesmith  7 years ago

      The paper suggests:

      > a new process starts as an empty address space, and an advanced user may manipulate it in a piecemeal fashion, populating its address-space and kernel context prior to execution, without needing to clone the parent nor run code in the context of the child. ExOS [43] implemented fork in user-mode atop such a primitive. Retrofitting cross-process APIs into Unix seems at first glance challenging, but may also be productive for future research.

  • a1369209993  7 years ago

    Specifically, you'd want to do something like:

      pid_t child = pfork();
  for(int fd=0;fd<3;fd++) p_open2(child,fd,pts,O_RDWR);
  char** envp = munge_env(/*parent's*/ environ);
  int err = p_execve(child,file,argv,envp);

    (Y'know, this looks kind of familiar...)