All of lore.kernel.org
 help / color / mirror / Atom feed
From: greg@kroah.com (Greg KH)
To: kernelnewbies@lists.kernelnewbies.org
Subject: SimpleFlow: simple information-flow-based security module for Linux
Date: Wed, 20 Apr 2016 14:54:48 +0900	[thread overview]
Message-ID: <20160420055448.GA6031@kroah.com> (raw)
In-Reply-To: <20160420024830.GA9032@imp.flyn.org>

On Tue, Apr 19, 2016 at 10:48:30PM -0400, W. Michael Petullo wrote:
> Some colleagues and I have been working on SimpleFlow, a simple
> information-flow-based security module for Linux. Our goal is to
> investigate the feasibility of implementing such a security model on
> top of LSM and to produce a prototype which is useful for education and
> certain computer-security competitions.
> 
> We have adopted a very simple view of information flow (we do not claim
> to approach HiStar, etc.). The system administrator designates some
> filesystem objects as "confidential" and some programs as "trusted"
> (both stored using extended attributes). Any process not loaded from
> a trusted program will become "tainted" upon reading a confidential
> object. The kernel transfers this taint status from process to process
> as a result of inter-process communication (i.e., an untainted process
> reads from a tainted process over an IPC channel). If a tainted process
> writes to the network, the packet gets its RFC 3514 evil bit set.
> 
> All of this seems to sort of work. We do our best to handle the forms
> of IPC including shared memory. The grand multi-source transformer X11
> poses a problem; we presently set X11 as trusted, but we have plans to
> deal with X11 in X11 as SELinux has attempted.
> 
> We tried to avoid making changes to the core kernel. One such change is
> an additional LSM call in fs/pipe.c. The other is a #define for the RFC
> 3514 evil bit.
> 
> For practical reasons, we have so far targeted 3.10.0. We intend to
> eventually port to a kernel that supports LSM stacking.

3.10.0 is almost 3 years old and very obsolete, please use a much newer
kernel as lots of stuff has changed in the vfs that you will have to
deal with eventually.

> We are presently preparing a paper that describes some of the things we
> have done with SimpleFlow, and we are interested in hearing any feedback
> on our approach or code. We attached a patch which represents our work
> so far. We realize this is niche work, and perhaps SimpleFlow itself does
> not belong in the mainline kernel. However, we would be keen to discuss
> the concept even with people who are mildly interested.

Try posting this to the linux-security list, they would be interested.

thanks,

greg k-h

      reply	other threads:[~2016-04-20  5:54 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-20  2:48 SimpleFlow: simple information-flow-based security module for Linux W. Michael Petullo
2016-04-20  5:54 ` Greg KH [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=20160420055448.GA6031@kroah.com \
    --to=greg@kroah.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /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.