At 2011-03-23，"Stephen Smalley" <sds@xxxxxxxxxxxxx> wrote:
>On Wed, 2011-03-23 at 09:10 +0800, Yao wrote:
>> Maybe I should explain. We think kernel is untrusted, ss is trusted.
>> we protect the security server through gerenating a separate address
>> space. When we need to use ss, we switch to this space. If untrusted
>> kernel code can be executed, what we do became meaningless. That's why
>> we want the ss self-contained. And our work should apply to flask
>> architecture, that's why we chose selinux.
>> Is it possible to fulill my goal without modifying ss excessively?
>
>The kernel has to be trusted - it runs in ring 0.
>And the security server is just a policy engine - it just provides
>policy decisions to the kernel upon request. The kernel performs the
>policy enforcement of those decisions.
>
>In Fluke/Flask, the security server ran in userspace, but that was a
>microkernel-based OS. And even there, we weren't trying to protect the
>security server from the (micro)kernel.
>
>It doesn't make sense to try to protect the security server apart from
>the rest of the kernel.
Well, my idea is based on a paper "Secure In-VM Monitoring Using Hardware Virtualization"(CCS'09). I will appreciate if you spend some time to look through the content & check if what I did is right.
>--
>Stephen Smalley
>National Security Agency
>
>
>--
>This message was distributed to subscribers of the selinux mailing list.
>If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
>the words "unsubscribe selinux" without quotes as the message.
