Re: the watchdog of login program

[Thomas Bushnell BSG]

Roland McGrath <roland@frob.com> writes:

> So login only needs to be setuid if you aren't using the password server,
> in theory.  The things that are failing are proc_setowner and chown called
> before the exec.  Those are using the old proc and auth state rather than
> the state that is being passed to file_exec, so they don't have the benefit
> of the auth handle from the password server.

The problem, alas, is that login has to set system things.  Blech.

I once dreamed that with the password server one could do without
setuid entirely, and then golly, we have things like chowning the tty.

This is why Unix sucks.

> The other issue is the chown call on the tty.  This is just not going to
> work on a vanilla tty node without having root.  Probably the thing to do
> here is to have login use file_chown on the reauthenticated fds[0] port
> (perhaps after checking it's a tty) rather than using `chown' per se as it
> does now.  Then we would have change term to permit a nonroot nonowner
> chown'ing the node e.g. if all live ctty protids' pid et al match his.

There are two traditional reasons for restricting chown.

First, chowning a setuid program would create a giant security hole.
That's fixed by just making chown clear the setuid bits.

Second, chown defeats quota systems.  It was this which led to the
restriction of chown in BSD.

Also, even when chown was unrestricted, it still could only be done on
your own file.  

We should be very careful about changing this.  But if we change it
only for the actual term program, it might be harmless.

> Looking at login makes me think that there is a security issue we should
> fix, though.  Once you call proc_setowner, then anyone authenticated with
> that owner uid (or anyone in your login collection if you now have no owner
> uid) gets permission from the proc server to do anything to you.  So, it is
> not safe to call proc_setowner if the process still has access to anything
> that the user being logged in shouldn't.  When login is not setuid, this is
> probably nothing at all, but I'm not positive.  When login is setuid, it
> has lingering ports around authenticated as root.  

Indeed!

> So I think login should be changed to drop all the old ports before calling
> exec.  

More exactly, you mean before calling proc_setowner.

> If you've already dropped the ref in PROC_SERVER, then there should
> be nothing but libc state of init and fd ports.  The simplest thing is to
> just do:
> 
>       close(0); close(1);
>       setauth(ports[INIT_PORT_AUTH]);

We should be more careful here.  There might well be more ports than
this.  For all we know, we have big giant hairy port leaks in the
startup code for the Hurd, and every process in the system is running
as root.  

But the solution to that is I think two fold: making proc and such
programs drop all their Mach state before calling proc_setowner, by
running through the ports that the kernel says we own.  (Perhaps this
hair should all be in a library function, since su and friends need it
too.)  Startup programs should maybe do a similar exercise at
judicious places.

And second, before doing that, see if there are any current
permissions leaks by looking through the table of open ports for an
ordinary user process on the Hurd and making sure every one of them is
appropriate and not leaked.

Thomas