Re: killing setuid programs

[Samuel Thibault]

retitle 413326 user-launched xinit can't kill X server at end of session
thanks

Hi,

The following issue is still not resolved, resulting to X session not
properly killing the X server at its end of its life.

Samuel Thibault, le Tue 29 Aug 2006 21:10:14 +0200, a écrit :
> Thomas Bushnell BSG, le Tue 29 Aug 2006 11:58:43 -0700, a écrit :
> > Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> > 
> > > Roland McGrath, le Mon 28 Aug 2006 17:34:24 -0700, a écrit :
> > >> It sounds like you are describing the intended behavior.
> > >> You can't send a signal to a setuid program with kill.
> > >
> > >   For a process to have permission to send a signal to a process 
> > > designated
> > >   by pid, unless the sending process has appropriate privileges, the real 
> > > or
> > >   effective user ID of the sending process shall match the real or saved
> > >   set-user-ID of the receiving process.
> > >
> > > And setuid programs keep the real user ID set to Joe user's, so that Joe
> > > user can kill the program he launches.
> > 
> > This is not quite correct.
> > 
> > Most setuid programs do *not* keep the real user ID alone; instead,
> > the explicitly change it to match the effective user ID.  This is
> > important.
> 
> Setuid programs themselves might, yes.  But the system mustn't change
> it itself (Hurd's proc correctly doesn't).  Because some programs other
> than passwd (an X server for instance) need to be killable by the very
> user that started it (via xinit).
> 
> > If the "passwd" program could be interrupted at will be
> > its caller, for example, then it might leave an incompletely written
> > and locked password file around.
> 
> Agreed.  But posix says (and some setuid programs rely on this) that by
> default, a setuid program can be killed by the user who launched it.

You didn't comment any more on this, so I guess you agree on this?

Now, the original question is still:

``There's an issue with Joe user being able to kill setuid programs that
he launches: on the sending side, glibc does:

        err = HURD_MSGPORT_RPC (__proc_getmsgport (proc, pid, &msgport),
                                  (taskerr = __proc_pid2task (proc, pid,
                                                              &refport)) ?
                                  __proc_getsidport (proc, &refport) : 0, 1,
                                  kill_port (msgport, refport));
        }

I.e. asks proc for the task port, and if that fails, asks proc for the
session port, then it sends the signal.

It happens that since the target got setuid'ed, the proc server had set
it owned by root, and hence pid2task fails.  I don't know exactly what
having a port on a task means, but I guess that's on purpose that even
if the real uid is Joe user, Joe user shouldn't have a task port on the
setuid-ed program.

As a result only proc_getsidport() works.

And on the receiving side, the ref port needs to be the task port for
letting any signal come in...''

So how should this be fixed for letting Joe kill his X server at the end
of his session?  Shouldn't Joe be allowed to have a task port on the
setuid-ed program?  Or do we need to implement another port which would
just let him do the few operations he can do as the real owner of the X
server?

Samuel