Re: killing setuid programs (user-launched xinit can't kill X server at end of session)

[Samuel Thibault]

This is still an issue, reported again by a user.

Samuel Thibault, le Sun 04 Mar 2007 14:38:31 +0100, a écrit :
> 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?