All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Smalley <sds@tycho.nsa.gov>
To: Yao <yffbrave@163.com>
Cc: SELinux@tycho.nsa.gov
Subject: Re: Re:Re: about ss
Date: Mon, 28 Mar 2011 08:49:29 -0400	[thread overview]
Message-ID: <1301316569.23818.13.camel@moss-pluto> (raw)
In-Reply-To: <20612ede.799c.12ef9f5493c.Coremail.yffbrave@163.com>

On Mon, 2011-03-28 at 08:55 +0800, Yao wrote:
> At 2011-03-25,"Stephen Smalley" <sds@tycho.nsa.gov> wrote:
> 
> >On Fri, 2011-03-25 at 14:11 +0800, Yao wrote:
> >> 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.
> >
> >If I understand correctly, that paper is about co-locating a monitoring
> >service in the same VM as the operating system being monitored.  But the
> >security server is not a monitoring service; it is a policy engine
> >invoked by the kernel.  So I don't think this applies.
> Oh, I thought the security server is an implementation of server monitor. Figure 2 in the paper shows overall design. Kernel hooks invoke entry gates, which in turn invoke handlers. And linux kernel has many hooks too. After selinux registered into the kernel, those hooks will invoke handlers in selinux. Finally, those functions reside in ss will be invoked, for example, "security_compute_av".
> Is that any difference? 
> If I want to put sim into use, how do I tune the selinux to meet the requirements? Should I put all selinux into sim address space?
> If it is impossible, what "service monitor of flask arch" can I use to achieve my goals?

The security server is a policy engine for access control decisions to
be enforced by the kernel over applications.  It is not a monitor for
the kernel itself.  You likely want something more like:
"Linux kernel integrity measurement using contextual
inspection" (STC'07)

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

      reply	other threads:[~2011-03-28 12:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-18  0:43 about ss Yao
2011-03-18 14:02 ` Stephen Smalley
2011-03-21  3:11   ` Yao
2011-03-21  8:31     ` Kohei Kaigai
2011-03-21 12:29     ` Stephen Smalley
2011-03-23  1:10       ` Yao
2011-03-23 13:24         ` Stephen Smalley
2011-03-25  6:11           ` Yao
2011-03-25 12:43             ` Stephen Smalley
2011-03-28  0:55               ` Yao
2011-03-28 12:49                 ` Stephen Smalley [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1301316569.23818.13.camel@moss-pluto \
    --to=sds@tycho.nsa.gov \
    --cc=SELinux@tycho.nsa.gov \
    --cc=yffbrave@163.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.