about ss

about ss

[Yao]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]

Hi, all
I looked at linux-2.6.36/security/selinux/ss/*.c and found most source files include <linux/***.h>
I know security server need to use some of kernel data structures.
But does ss use kernel fuctions?
Is it possible to modify security server and make it self-contained if ss used kernel function?


Regards,
Yao



[-- Attachment #2: Type: text/html, Size: 558 bytes --]

Re: about ss

[Stephen Smalley]

On Fri, 2011-03-18 at 08:43 +0800, Yao wrote:
> Hi, all
> I looked at linux-2.6.36/security/selinux/ss/*.c and found most source
> files include <linux/***.h>
> I know security server need to use some of kernel data structures.
> But does ss use kernel fuctions?
> Is it possible to modify security server and make it self-contained if
> ss used kernel function?

The original security server code was developed for another OS
(Fluke/Flask) and then ported to Linux.  There are a small number of
fundamental dependencies on the runtime environment, like memory
allocation, logging/auditing, locking, etc.  Over time, the security
server code in Linux has become increasingly "nativized" for Linux so
you may find further dependencies in the current code.

You'll find other forms of the security server code that may be more
portable in:
1) The SELinux userspace (http://userspace.selinuxproject.org)
In particular, a copy of the security server code lives in libsepol.
Originally there was a single code base shared between
checkpolicy/libsepol and the kernel, but this was forked when SELinux
went into mainline.

2) The OSKit (http://www.cs.utah.edu/flux/oskit/)
This was used in Fluke/Flask.  Security server is under security/, AVC
is in com/avc.c.

3) Various ports of SELinux to other systems
(http://www.nsa.gov/research/selinux/related.shtml)

-- 
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.

Re:Re: about ss

[Yao]

[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]






At 2011-03-18，"Stephen Smalley" <sds@tycho.nsa.gov> wrote:

>On Fri, 2011-03-18 at 08:43 +0800, Yao wrote:
>> Hi, all
>> I looked at linux-2.6.36/security/selinux/ss/*.c and found most source
>> files include <linux/***.h>
>> I know security server need to use some of kernel data structures.
>> But does ss use kernel fuctions?
>> Is it possible to modify security server and make it self-contained if
>> ss used kernel function?
>
>The original security server code was developed for another OS
>(Fluke/Flask) and then ported to Linux.  There are a small number of
>fundamental dependencies on the runtime environment, like memory
>allocation, logging/auditing, locking, etc.  Over time, the security
>server code in Linux has become increasingly "nativized" for Linux so
>you may find further dependencies in the current code.
>
so, it's hard to modify ss to make it self-contained, right?
I just wonder if there is a security module without invoking kernel function but to support flask, though kernel data is permitted...
Is AppArmor fit to my desire?
>You'll find other forms of the security server code that may be more >portable in: >1) The SELinux userspace (http://userspace.selinuxproject.org) >In particular, a copy of the security server code lives in libsepol. >Originally there was a single code base shared between >checkpolicy/libsepol and the kernel, but this was forked when SELinux >went into mainline. > >2) The OSKit (http://www.cs.utah.edu/flux/oskit/) >This was used in Fluke/Flask.  Security server is under security/, AVC >is in com/avc.c. > >3) Various ports of SELinux to other systems >(http://www.nsa.gov/research/selinux/related.shtml) > >--  >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.

[-- Attachment #2: Type: text/html, Size: 3557 bytes --]

RE: Re:Re: about ss

[Kohei Kaigai]

> At 2011-03-18，"Stephen Smalley" <sds@tycho.nsa.gov> wrote:
> 
> >On Fri, 2011-03-18 at 08:43 +0800, Yao wrote:
> >> Hi, all
> >> I looked at linux-2.6.36/security/selinux/ss/*.c and found most source
> >> files include <linux/***.h>
> >> I know security server need to use some of kernel data structures.
> >> But does ss use kernel fuctions?
> >> Is it possible to modify security server and make it self-contained if
> >> ss used kernel function?
> >
> >The original security server code was developed for another OS
> >(Fluke/Flask) and then ported to Linux.  There are a small number of
> >fundamental dependencies on the runtime environment, like memory
> >allocation, logging/auditing, locking, etc.  Over time, the security
> >server code in Linux has become increasingly "nativized" for Linux so
> >you may find further dependencies in the current code.
> >
> so, it's hard to modify ss to make it self-contained, right?
> I just wonder if there is a security module without invoking kernel function
> but to support flask, though kernel data is permitted...

The libselinux provides a set of interfaces to invoke security server in
kernel space. Please see the manpage of security_compute_av(3).
The security_context_t as these arguments are just an alias of char *,
so all you need to do is call this function with security context of
subject/object with a set permissions to be asked.

> Is AppArmor fit to my desire?

It seems to me you walk away from where you want to go. :-)

Thanks,
--
NEC Europe Ltd, Global Competence Center
KaiGai Kohei <kohei.kaigai@eu.nec.com>


--
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.

Re: Re:Re: about ss

[Stephen Smalley]

On Mon, 2011-03-21 at 11:11 +0800, Yao wrote:
> At 2011-03-18，"Stephen Smalley" <sds@tycho.nsa.gov> wrote:
> >The original security server code was developed for another OS
> >(Fluke/Flask) and then ported to Linux.  There are a small number of
> >fundamental dependencies on the runtime environment, like memory
> >allocation, logging/auditing, locking, etc.  Over time, the security
> >server code in Linux has become increasingly "nativized" for Linux so
> >you may find further dependencies in the current code.
> >
> so, it's hard to modify ss to make it self-contained, right?

No, the ss is already reasonably self-contained (modulo the runtime
environment dependencies that any piece of software would have, like
memory allocation, locking, logging, etc) and I pointed you to alternate
versions of the security server code that are even more self-contained
if you have difficulty leveraging the Linux kernel version.  The OSKit
in particular was carefully designed to explicitly identify all
dependencies on the runtime environment.

> I just wonder if there is a security module without invoking kernel function but to support flask, though kernel data is permitted...
> Is AppArmor fit to my desire?

SELinux is architected in such a manner that its policy engine, the
security server, is well encapsulated behind a general security
interface, and thus the security server is not tightly coupled to the
OS.  AppArmor and other Linux security modules lack such an architecture
and thus are more tightly coupled to Linux.

It is hard to answer your question though without understanding how you
want to use the security server.  If you just want to use it from an
application running on Linux, then KaiGai is correct - you can just use
the libselinux interfaces to invoke the security server.  If you want to
port it to some other OS, then the libsepol or OSKit versions may be a
better starting point.  You may find that there is already a port to the
OS of interest.

-- 
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.

Re:Re: Re:Re: about ss

[Yao]

[-- Attachment #1: Type: text/plain, Size: 2817 bytes --]


At 2011-03-21，"Stephen Smalley" <sds@tycho.nsa.gov> wrote:

>On Mon, 2011-03-21 at 11:11 +0800, Yao wrote:
>> At 2011-03-18，"Stephen Smalley" <sds@tycho.nsa.gov> wrote:
>> >The original security server code was developed for another OS
>> >(Fluke/Flask) and then ported to Linux.  There are a small number of
>> >fundamental dependencies on the runtime environment, like memory
>> >allocation, logging/auditing, locking, etc.  Over time, the security
>> >server code in Linux has become increasingly "nativized" for Linux so
>> >you may find further dependencies in the current code.
>> >
>> so, it's hard to modify ss to make it self-contained, right?
>
>No, the ss is already reasonably self-contained (modulo the runtime
>environment dependencies that any piece of software would have, like
>memory allocation, locking, logging, etc) and I pointed you to alternate
>versions of the security server code that are even more self-contained
>if you have difficulty leveraging the Linux kernel version.  The OSKit
>in particular was carefully designed to explicitly identify all
>dependencies on the runtime environment.
>
>> I just wonder if there is a security module without invoking kernel function but to support flask, though kernel data is permitted...
>> Is AppArmor fit to my desire?
>
>SELinux is architected in such a manner that its policy engine, the
>security server, is well encapsulated behind a general security
>interface, and thus the security server is not tightly coupled to the
>OS.  AppArmor and other Linux security modules lack such an architecture
>and thus are more tightly coupled to Linux.
>
>It is hard to answer your question though without understanding how you
>want to use the security server.  If you just want to use it from an
>application running on Linux, then KaiGai is correct - you can just use
>the libselinux interfaces to invoke the security server.  If you want to
>port it to some other OS, then the libsepol or OSKit versions may be a
>better starting point.  You may find that there is already a port to the
>OS of interest.
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?


Regards,
Yao
>-- 
>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.

[-- Attachment #2: Type: text/html, Size: 4853 bytes --]

Re: Re:Re: Re:Re: about ss

[Stephen Smalley]

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.

-- 
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.

Re:Re: Re:Re: Re:Re: about ss

[Yao]

[-- Attachment #1: Type: text/plain, Size: 1575 bytes --]


At 2011-03-23，"Stephen Smalley" <sds@tycho.nsa.gov> 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@tycho.nsa.gov with
>the words "unsubscribe selinux" without quotes as the message.

[-- Attachment #2: Type: text/html, Size: 2880 bytes --]

Re: about ss

[Stephen Smalley]

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.

-- 
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.

Re:Re: about ss

[Yao]

[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]

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?

Regards,
Yao
>-- 
>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.

[-- Attachment #2: Type: text/html, Size: 2369 bytes --]

Re: Re:Re: about ss

[Stephen Smalley]

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.