bug-hurd
[Top][All Lists]
Advanced

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

Re: looking for the solution of rootless subhurd


From: Da Zheng
Subject: Re: looking for the solution of rootless subhurd
Date: Sat, 13 Dec 2008 15:55:26 +0000
User-agent: Thunderbird 2.0.0.18 (Macintosh/20081105)

olafBuddenhagen@gmx.net wrote:
Hi,

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:-). The point here is that the process server needs to get all tasks in the host, so it can distinguish the task port from other ports. Otherwise, other programs can give the process server any port, and the process server thinks a new task is created and create the Hurd process for it. It would be a big mess.
Obviously, the process server in the subhurd cannot get all tasks in
the  host. Instead, it should only get the tasks that belong to the
subhurd.

Actually, in the current subhurd implementation, the subhurd does see
all host tasks as well... Only it doesn't know much about them, as they
are not registered with the subhurd's proc.

Of course, ideally we would hide them; but it doesn't seem terribly
important, and in most situations probably isn't worth the performance
hit...

Perhaps it could be made optional. But unless it can be implemented with
little effort, I suggest not spending any time on it.
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.
I am thinking of a way to trace tasks in subhurd.

One way I can think of is that boot creates a proxy for the RPC
task_create. As a result, boot needs to create pseudo task ports for
all  tasks in subhurd and run as a proxy for all RPCs on the task
port. Extra  RPCs are needed for the tasks to get the pseudo task
ports, and  mach_task_self() in glibc need to be modified.

This solution should be powerful enough (it can solve all problems I
have got so far) as long as all programs in subhurd uses the modified
mach_task_self() in glibc. But it has two drawback:

1. There isn't an effective way to prevent the programs in subhurd
calling the system trap mach_task_self(). If the program does use the
system trap, it might not have the right behavior, but at least it
doesn't harm the tasks in main Hurd and other subhurds.

2. It seems a bit heavy. Almost all of RPCs to the kernel are
redirected  to the boot.

Anyone has comments for the solution I suggested above? I hope there
is an easier way in Mach/Hurd to trace tasks.

Well, I have a feeling that we are missing something here. If such
fundamental system calls as mach_task_self() can not be virtualized,
what's the point in making any system calls virtualizable? Surely that's
not how the Mach designers intended it...
But I really have no clue what we could be missing.
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.

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.

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.

Because of my limited knowledge of Mach and Hurd, it is all I can think about.

Zheng Da




reply via email to

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