bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: the watchdog of login program


From: Roland McGrath
Subject: Re: the watchdog of login program
Date: Mon, 30 Aug 2004 21:38:35 -0400 (EDT)

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

Yes, I was only talking about term's virtual node, and not transmitting the
changes to the underlying node on disk so it could be abused.  Even so, I
think the thing to do is restrict it so that essentially login gets to do
it but noone else.  

> More exactly, you mean before calling proc_setowner.

Yes.

> We should be more careful here.  

How?

> There might well be more ports than this.  

Like what?

> 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.

Not if there are EXEC_NEWTASK execs involved.  

Like I said, there might be leaks in login I haven't though of.  Using
EXEC_NEWTASK is the way to be sure none survive, but there will be a window
between proc_setowner and the exec completing where the target owner can
hijack the login process and exploit any leaks.  We can avoid that by using
EXEC_SECURE instead, and just not calling proc_setowner at all.  Then exec
will use proc_setowner on the fresh task's proc port after proc_reassign.

> 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.

That is nuts.  You don't know what you are talking about proc and startup
programs for.  There is no problem with them.  We are talking about login here.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]