Re: looking for the solution of rootless subhurd

[olafBuddenhagen]

Hi,

On Sat, Dec 13, 2008 at 03:55:26PM +0000, Da Zheng wrote:
> olafBuddenhagen@gmx.net wrote:
>> On Tue, Dec 09, 2008 at 12:30:08AM +0000, Da Zheng wrote:

>>> The function add_tasks (proc/mgt.c) gets all tasks in the host by
>>> calling host_processor_sets(), host_processor_set_priv() and
>>> processor_set_tasks() because the process server needs to check if
>>> the port is a task port or not.
>>>     
>>
>> I don't understand.
>>   
> Actually, I wanted you to read the code in add_tasks() yourself
> because  I didn't think I could explain it well:-).

Well, saying so explicitely tends to work better :-)

It seems to me that the code is actually easy to explain... But you are
right: It's even easier to read up myself :-) It's the RPC names that
confused me -- they are not really self-explaning...

> The point here is that the  process server needs to get all tasks in
> the host,

Yes, obviously it needs to. I understand your concern now, but I still
don't see an actual problem...

Note that the implementation of the pseudo master host port does not
need to forward the RPCs directly to Mach. (In fact, it can't even do
that, as it lacks the necessary privileges...) It can simply ask the
main Hurd's proc server instead.

I would hope that the proc server also has the necessary information to
find out which tasks belong to the subhurd -- though I don't know for
sure...

> I believe it can cause a serious security problem if the subhurd can
> see  all tasks in the host and every user can create his own subhurd.
> If a  subhurd can see a task, it means it can also destroy the task.
> As a  result, any user (suppose the user have the root permission in a
> subhurd) can destroy any tasks in the host.

Not at all. The subhurd's processes, from the main Hurd's point of view,
all run with the rights of the user who started the subhurd. They do not
have permission to manipulate other users' processes.

Depending on some details of the implementation which I don't know, it
could be possible to manipulate processes belonging to the user who
started the subhurd, from within the subhurd. Depending on the
individual use case, that might or might not be desirable...

I'm more and more convinced that filtering tasks visible in the subhurd
should be made an option.

> I guess the reason mach_task_self() is designed as a system trap
> instead  of RPC is that the kernel can recognize tasks with their
> address spaces,  so there is no point to use a RPC to the kernel and a
> system trap is  very enough.

I don't think it has anything to do with being "enough" -- if that was
so, many more kernel RPCs could be implemented as direct system traps
instead.

I think it's the other way around: There are certain advantages of using
RPCs (like easy virtualization), and only where this is problematic,
traps are used instead.

> However, even if mach_task_self() was implemented with RPC, it would
> still be very difficult to virtualize it. Let's suppose the RPC
> version  of mach_task_self() is mach_task_self(mach_port_t host_port).
> Now we  want to virtualize it in subhurd. Suppose that the server side
> of this  RPC is implemented in boot. When boot gets the request, it
> has no idea  who sends the request, whether the request is from the
> same task or not.

I see it now: It really boils down to a simple bootstrap problem. To
invoke any RPCs, we first need to obtain *some* port to send RPCs to...
So we need an entry point, to get the first RPC port. This is what
mach_*_self() do.

I guess there would be other ways to solve the bootstrap problem, but it
seems the Mach creators considered this the best approach...

> One way I think of is to use a different RPC. Suppose it is called
> mach_task_to_subhurd_task(mach_port_t subhurd_port, task_t task).
> Therefore, the task in subhurd gets its task port with
> mach_task_self()  and translate it to subhurd task port with this RPC.

Well, if we really need to modify the client-side code for obtaining the
task port, I guess a simpler and more efficient approch would be to
inject a send right for the pseudo task port into the process address
space at process creation time, and simply read that when
mach_task_self() is attempted. (Pseudo thread port is more tricky,
though.)

However, I browsed the Mach documentation a bit, and found
task_set_emulation(). It is not documented properly, so I don't know
what it can do exactly -- whether it's for UNIX system call emulation,
or Mach trap emulation, or both... It *might* be a way to provide pseudo
task/thread ports without client-side changes.

I agree though that proxying thread/task ports -- with client-side
modifications or without -- is a very heavyweight solution, and we
should try to avoid it if at all possible.

As I don't see a need to do this kind of proxying when obtaining the
process list (see above), the thread_max_priority() in proc still seems
the only really problematic place.

-antrik-