FW: Current/Future Plans to Support Stacking LSM Modules

FW: Current/Future Plans to Support Stacking LSM Modules

[Tom Fortmann]

Can you send me a pointer to the limited stacking that selinux supports?

I will join the LSM list.  I started here because LSM already supports a
basic stacking method.  However, SELinux does not support the
mod_reg_security call necessary to take advantage of this capability.  

The product we are developing adds additional security at the application
data layer.  It is a commercial product so I can't say a lot, other then to
say that SELinux currently does not provide the additional features we are
working on.

Thomas Fortmann
Sr. Software Engineer
Xcape Solutions, Inc.

-----Original Message-----
From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov] On
Behalf Of Casey Schaufler
Sent: Tuesday, January 16, 2007 12:46 PM
To: Tom Fortmann; selinux@tycho.nsa.gov
Cc: linux-security-module@vger.kernel.org
Subject: Re: Current/Future Plans to Support Stacking LSM Modules


--- Tom Fortmann <tfortmann@xcapesolutions.net> wrote:

> Are their any current or future plans to support
> stacking additional
> security modules on the LSM interface?

It has certainly been considered from
time to time. David Wheeler's early work
came pretty close.

> Alternatively, are there any current or future plans
> to allow the SELinux
> framework to be expanded with third party loadable
> modules?

SELinux does currently, although somewhat
begrudgingly, allow limited stacking in
support of a particular set of modules. 

It wasn't but a year ago that the SELinux
community was arguing that LSM ought to be
dispensed with, as they argued that:
  - No one else was using LSM
  - SELinux does everything that a rational
    being might want done anyway.

> We are working on some enhanced security solutions
> that require access to
> the LSM interface, but we do not want to preclude
> the use of SELinux by our
> customers.

You might take this onto the LSM list (I've
added it to the CC here) as there are a (very)
few people who follow LSM that do not subscribe
here.

Just out of curiosity, what's your module
going to do?


Casey Schaufler
casey@schaufler-ca.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.


--
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: FW: Current/Future Plans to Support Stacking LSM Modules

[Stephen Smalley]

On Tue, 2007-01-16 at 13:41 -0600, Tom Fortmann wrote:
> Can you send me a pointer to the limited stacking that selinux supports?

http://www.nsa.gov/selinux/papers/module/x341.html

> I will join the LSM list.  I started here because LSM already supports a
> basic stacking method.  However, SELinux does not support the
> mod_reg_security call necessary to take advantage of this capability.  

No, SELinux does support trivial stacking by implementing a
register_security hook, which is what mod_reg_security() calls.  That is
used to combine SELinux with the Linux capabilities module.

> The product we are developing adds additional security at the application
> data layer.  It is a commercial product so I can't say a lot, other then to
> say that SELinux currently does not provide the additional features we are
> working on.

If you are adding additional security at the application data layer,
then you can do that in userspace, and use SELinux Type Enforcement to
make it unbypassable and tamperproof.  You don't need to change 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: FW: Current/Future Plans to Support Stacking LSM Modules

[Tom Fortmann]

Stephen,

Thank you for the links.  I obviously have a lot more research to do, first
and foremost is the selinux_register_security function.  I will also dig in
to the SELinux Type Enforcement capabilities.  We are not averse to doing
this in either space, but user space does offer some benefits from a
maintenance point of view.

Thomas Fortmann
Sr. Software Engineer

-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Tuesday, January 16, 2007 1:52 PM
To: Tom Fortmann
Cc: selinux@tycho.nsa.gov
Subject: Re: FW: Current/Future Plans to Support Stacking LSM Modules

On Tue, 2007-01-16 at 13:41 -0600, Tom Fortmann wrote:
> Can you send me a pointer to the limited stacking that selinux supports?

http://www.nsa.gov/selinux/papers/module/x341.html

> I will join the LSM list.  I started here because LSM already supports a
> basic stacking method.  However, SELinux does not support the
> mod_reg_security call necessary to take advantage of this capability.  

No, SELinux does support trivial stacking by implementing a
register_security hook, which is what mod_reg_security() calls.  That is
used to combine SELinux with the Linux capabilities module.

> The product we are developing adds additional security at the application
> data layer.  It is a commercial product so I can't say a lot, other then
to
> say that SELinux currently does not provide the additional features we are
> working on.

If you are adding additional security at the application data layer,
then you can do that in userspace, and use to
make it unbypassable and tamperproof.  You don't need to change 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: FW: Current/Future Plans to Support Stacking LSM Modules

[Casey Schaufler]

--- Stephen Smalley <sds@tycho.nsa.gov> wrote:


> If you are adding additional security at the
> application data layer,
> then you can do that in userspace, and use SELinux
> Type Enforcement to
> make it unbypassable and tamperproof.  You don't
> need to change the
> kernel.

Stephen, you can't possibly know that kernel
changes aren't required from the information
provided. The information provided appears
to be intentionally imprecise. (not a good
idea in the community, BTW) You may prove
correct in the end (you often are) but you're
jumping the SELinux Uber Alas gun.


Casey Schaufler
casey@schaufler-ca.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: FW: Current/Future Plans to Support Stacking LSM Modules

[Tom Fortmann]

Stephen,

The security measures we are trying to implement require us to actually
inspect, and in some case modify, the application data flowing over a socket
connection.  Our goal is to secure legacy server applications at the socket
layer.  We have done some proof of concept work at the netfilter layer, but
the ultimate solution is better suited above the TCP/IP packet layer.

Does SELinux provide a mechanism for us to do this, and or does it call the
secondary LSM hooks that provide this type of access.  Specifically the
socket_xxxx hooks?

Thanks again for all of your help,
Tom

Thomas Fortmann
Sr. Software Engineer
Xcape Solutions, Inc.
-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Tuesday, January 16, 2007 1:52 PM
To: Tom Fortmann
Cc: selinux@tycho.nsa.gov
Subject: Re: FW: Current/Future Plans to Support Stacking LSM Modules

On Tue, 2007-01-16 at 13:41 -0600, Tom Fortmann wrote:
> Can you send me a pointer to the limited stacking that selinux supports?

http://www.nsa.gov/selinux/papers/module/x341.html

> I will join the LSM list.  I started here because LSM already supports a
> basic stacking method.  However, SELinux does not support the
> mod_reg_security call necessary to take advantage of this capability.  

No, SELinux does support trivial stacking by implementing a
register_security hook, which is what mod_reg_security() calls.  That is
used to combine SELinux with the Linux capabilities module.

> The product we are developing adds additional security at the application
> data layer.  It is a commercial product so I can't say a lot, other then
to
> say that SELinux currently does not provide the additional features we are
> working on.

If you are adding additional security at the application data layer,
then you can do that in userspace, and use SELinux Type Enforcement to
make it unbypassable and tamperproof.  You don't need to change 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: FW: Current/Future Plans to Support Stacking LSM Modules

[Stephen Smalley]

On Wed, 2007-01-17 at 14:09 -0600, Tom Fortmann wrote:
> Stephen,
> 
> The security measures we are trying to implement require us to actually
> inspect, and in some case modify, the application data flowing over a socket
> connection.  Our goal is to secure legacy server applications at the socket
> layer.  We have done some proof of concept work at the netfilter layer, but
> the ultimate solution is better suited above the TCP/IP packet layer.
> 
> Does SELinux provide a mechanism for us to do this, and or does it call the
> secondary LSM hooks that provide this type of access.  Specifically the
> socket_xxxx hooks?

I'm not clear as to why you can't use a netfilter module.  SELinux
provides socket and network access controls through a combination of LSM
hooks and netfilter, and the SELinux SECMARK mechanism lets you label
packets using iptables and control them using policy.   See
selinux_socket_sock_rcv_skb() (registered via LSM) and
selinux_ip_postroute_last() (registered via netfilter).

-- 
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: FW: Current/Future Plans to Support Stacking LSM Modules

[Tom Fortmann]

Stephen,

We are currently working at the netfilter level.  We have a working
netfilter module that examines packets in a NF_IP_LOCAL_IN and
NF_IP_LOCAL_OUT hook.  The problem with working at this level is the
additional complexity involved with altering the data.  Any change in the
application data value or length causes changes in the IP and TCP headers.
Moving up above layer 3 would eliminate these issues and simplify our
design.

It looks like the selinux_socket_sock_rcv_skb() hook may give me what I need
on the receive side - access to received data after the layers 3 processing
is complete.  Can you point me to more detailed information on how this hook
works and what can and can't be done to the skb at this time?  Also, is
there a similar hook on the transmit side?

Thanks again for helping me work through the learning curve of SELinux.

Thomas Fortmann
Sr. Software Engineer
Xcape Solutions, Inc.

-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Thursday, January 18, 2007 6:48 AM
To: Tom Fortmann
Cc: selinux@tycho.nsa.gov; James Morris
Subject: RE: FW: Current/Future Plans to Support Stacking LSM Modules

On Wed, 2007-01-17 at 14:09 -0600, Tom Fortmann wrote:
> Stephen,
> 
> The security measures we are trying to implement require us to actually
> inspect, and in some case modify, the application data flowing over a
socket
> connection.  Our goal is to secure legacy server applications at the
socket
> layer.  We have done some proof of concept work at the netfilter layer,
but
> the ultimate solution is better suited above the TCP/IP packet layer.
> 
> Does SELinux provide a mechanism for us to do this, and or does it call
the
> secondary LSM hooks that provide this type of access.  Specifically the
> socket_xxxx hooks?

I'm not clear as to why you can't use a netfilter module.  SELinux
provides socket and network access controls through a combination of LSM
hooks and netfilter, and the SELinux SECMARK mechanism lets you label
packets using iptables and control them using policy.   See
selinux_socket_sock_rcv_skb() (registered via LSM) and
selinux_ip_postroute_last() (registered via netfilter).

-- 
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: FW: Current/Future Plans to Support Stacking LSM Modules

[Stephen Smalley]

On Thu, 2007-01-18 at 11:13 -0600, Tom Fortmann wrote:
> Stephen,
> 
> We are currently working at the netfilter level.  We have a working
> netfilter module that examines packets in a NF_IP_LOCAL_IN and
> NF_IP_LOCAL_OUT hook.  The problem with working at this level is the
> additional complexity involved with altering the data.  Any change in the
> application data value or length causes changes in the IP and TCP headers.
> Moving up above layer 3 would eliminate these issues and simplify our
> design.

Possible options to consider:
- socket filters (Documentation/networking/filter.txt),
- application proxies, or
- LD_PRELOAD of a library that overrides the socket calls.

The first option requires action by the application to set up the filter
on the socket, so you'd have to modify or wrap the application (e.g.
using LD_PRELOAD as in the last option), and only filters incoming data.
Both the first and last options naturally assume that the application is
benign and well-behaved, vs. mandatory enforcement by something like an
application proxy or netfilter.

> It looks like the selinux_socket_sock_rcv_skb() hook may give me what I need
> on the receive side - access to received data after the layers 3 processing
> is complete.  Can you point me to more detailed information on how this hook
> works and what can and can't be done to the skb at this time?  Also, is
> there a similar hook on the transmit side?

The hook was added to check permissions on incoming packets before they
are queued on the receiving socket.  It was needed because netfilter
didn't include a hook at the point where the skb is associated with the
receiving socket, and we needed both to perform a permission check.  It
is called by sk_filter(), which is also where socket filters are
applied; see include/net/sock.h.  I suppose one could mutate the data
there as with socket filters, although that is not the intent of the LSM
hook.  On the transmit side, we just use netfilter for permission
checking, as we have all the necessary information available there.

You may want to ask on a mailing list that is more suited to general
network filtering questions, like netdev or netfilter, as what you are
trying to do isn't really a good fit for LSM or SELinux.

-- 
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: FW: Current/Future Plans to Support Stacking LSM Modules

[Tom Fortmann]

Stephen,

Thank you.  You have been great.  I will move over to the netdev and
netfilter lists.  I know our application sits on the border between security
and networking - with the problem at hand being more networking.

Thanks again,
Tom

Thomas Fortmann
Sr. Software Engineer
Xcape Solutions, Inc.
-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Friday, January 19, 2007 9:31 AM
To: Tom Fortmann
Cc: selinux@tycho.nsa.gov; 'James Morris'
Subject: RE: FW: Current/Future Plans to Support Stacking LSM Modules

On Thu, 2007-01-18 at 11:13 -0600, Tom Fortmann wrote:
> Stephen,
> 
> We are currently working at the netfilter level.  We have a working
> netfilter module that examines packets in a NF_IP_LOCAL_IN and
> NF_IP_LOCAL_OUT hook.  The problem with working at this level is the
> additional complexity involved with altering the data.  Any change in the
> application data value or length causes changes in the IP and TCP headers.
> Moving up above layer 3 would eliminate these issues and simplify our
> design.

Possible options to consider:
- socket filters (Documentation/networking/filter.txt),
- application proxies, or
- LD_PRELOAD of a library that overrides the socket calls.

The first option requires action by the application to set up the filter
on the socket, so you'd have to modify or wrap the application (e.g.
using LD_PRELOAD as in the last option), and only filters incoming data.
Both the first and last options naturally assume that the application is
benign and well-behaved, vs. mandatory enforcement by something like an
application proxy or netfilter.

> It looks like the selinux_socket_sock_rcv_skb() hook may give me what I
need
> on the receive side - access to received data after the layers 3
processing
> is complete.  Can you point me to more detailed information on how this
hook
> works and what can and can't be done to the skb at this time?  Also, is
> there a similar hook on the transmit side?

The hook was added to check permissions on incoming packets before they
are queued on the receiving socket.  It was needed because netfilter
didn't include a hook at the point where the skb is associated with the
receiving socket, and we needed both to perform a permission check.  It
is called by sk_filter(), which is also where socket filters are
applied; see include/net/sock.h.  I suppose one could mutate the data
there as with socket filters, although that is not the intent of the LSM
hook.  On the transmit side, we just use netfilter for permission
checking, as we have all the necessary information available there.

You may want to ask on a mailing list that is more suited to general
network filtering questions, like netdev or netfilter, as what you are
trying to do isn't really a good fit for LSM or SELinux.

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