Hi, we have an idea that can flow Genode security system, correct me if we are wrong. It also can hack signal service. The ideas of kernel-protected capabilities are interesting, but we think the implementation of Genode capabilities has some features. Although we consider only Genode on Fiasco.OC. The Genode::Native_capability could be considered as two values : the badge(the local_name) and the dst ("the pointer" to the kernel's object). Thus we can use simple structure Native_capability(valid_dst, any_number_as_badge) as Signal_context_capability (using static_cap_cast), where valid_dst could be env()->ram_session_cap().dst(). Then we can pass this obtained capability as parameter to the Signal_session_client::submit() RPC and call any arbitrary signal_contexts. Furthermore as we known the env()->ram_session_cap().dst() points to the Genode main entrypoint then we can create dummy_client of Native_capability(env()->ram_session_cap().dst(), any_number_as_badge) that will call any_rpc. And we think these activities will crush all Genode system.
addr_t genode_ep = env()->ram_session_cap().dst(); for(long badge = 0;; badge++) { Dummy_client client(Native_capability(genode_ep, badge)); client.call_dummy_rpc_1(); ... client.call_dummy_rpc_k(); // say k>10 }
May be we don't understand Genode and Fiasco.OC completely and you can explain this behaviour.
Best, Ivan Bludov.
On 10/02/12 15:49, Norman Feske wrote:
Hello again,
Unfortunately, a real solution for the problem is not as simple as that. You are right that the badge is used as a key for looking up the signal-context within core. But by passing the badge as plain data instead of a capability, the referred signal context could be forged by the client. This way, a malicious client would be able to submit signals to all signal receivers in the system. The use of capabilities prevents that.
replying to myself now... .-)
I just had the following idea for a fix: When unmarshalling a capability (in 'Ipc_istream::_unmarshal_capability') we need to distinguish the case of having got a new capability from the case of getting a reference to an already known capability. We receive the 'unique_id' as hint (it is just plain data - hence untrusted information) about which capability selector the argument refers to. Using this 'unique_id', we could look up the core-local capability selector at the cap-selector allocator. Currently, we do not store the unique ID at this allocator. So we would need to add a way to register the unique IDs that correspond to cap selectors and a way to perform a lookup from cap selector to unique ID.
If the lookup fails, we know that we received a new capability (for the signal service, this should never happen because all signal contexts are allocated at core). If the lookup succeeds, we obtained a capability selector that can now be tested via the kernel's 'l4_task_cap_equal' kernel function. If the just received capability selector refers to the same kernel capability as the looked up selector, we just keep using the one returned by the lookup and do not allocate a new selector.
Of course there is still the other part of the problem: keeping a reference count for each capability selector (similarly to how shared pointers work). But the fix above should actually solve the capability-selector leak in the packet-stream case without introducing a security problem.
Cheers Norman
Virtualization& Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main