Re: a design flaw when associating a user to a process?

[olafBuddenhagen]

Hi,

On Tue, Jan 13, 2009 at 12:12:13AM +0000, Da Zheng wrote:
> olafBuddenhagen@gmx.net wrote:

>> Are you saying that if a task fails to register itself with the proc
>> server, it can not be associated with any user, i.e. only root can
>> kill the task? That would be a serious security problem for all I
>> know...
>>   
> As far as I see, yes. The processes in subhurd doesn't belong to the
> user who runs the subhurd  in the eyes of the main Hurd. Therefore,
> the user has to trust subhurd and supposes it can kill all  processes
> in subhurd when subhurd is closed. if the subhurd fails to  boot, the
> normal user might have no way to close it.

Ouch...

> In my understanding, a process inherits the user information from its
> parent, and it has to call auth_makeauth() explicitly to create a new
> auth port. Later, it calls proc_reauthenticate(), and the process
> server  can get the user information of the process. However, neither
> of them can happen to the processes in subhurd. The  process server in
> subhurd can only be aware of the tasks in subhurd when  it calls
> processor_set_tasks() in add_tasks(), but it has no way to get  the
> user information.

I see.

> First, I'm not sure whether we should fix the problem.

Yes, I think we should definitely try to fix it. As I said, I think this
is a very fundamental problem -- subhurd is only one manifestation...

> If we do need to fix it, I think we need the help of the kernel. It
> seems that mach doesn't track the children of a task,

Maybe changing that would be the easiest approach?... I guess it
shouldn't be too hard to add a notion of parent task to Mach.

> so I am thinking  how about sending the notification (it shows which
> task is created from  the parent task) to the task who requests it
> when a new task is created  (it's very much like
> mach_port_request_notification). When the process  server can get the
> notification, it can associate the new task to the  parent task's
> user.

Yeah, I was thinking along these lines as well.

Instead of a special purpose notification, proc might also just
intercept the task kernel ports... Would be a relatively heavy-weight
solution, but that might not be a serious problem in practice -- and it
wouldn't require any kernel changes.

Note that all of these solutions assume the new task is created directly
by the parent process... I'm not sure whether this is indeed the case
with the standard fork() and exec() mechanisms. (Especially for suid
exec.)

BTW, I think this is the sort of things we should definitely try to
discuss with Roland and/or Thomas...

-antrik-