From: mike@flyn.org (W. Michael Petullo)
To: kernelnewbies@lists.kernelnewbies.org
Subject: SimpleFlow: simple information-flow-based security module for Linux
Date: Tue, 19 Apr 2016 22:48:30 -0400 [thread overview]
Message-ID: <20160420024830.GA9032@imp.flyn.org> (raw)
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.
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.
Thank you,
--
Mike
:wq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linux-3.10.0-327.el7-simple-flow.patch.gz
Type: application/gzip
Size: 13694 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160419/d3b35377/attachment.bin
next reply other threads:[~2016-04-20 2:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-20 2:48 W. Michael Petullo [this message]
2016-04-20 5:54 ` SimpleFlow: simple information-flow-based security module for Linux Greg KH
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=20160420024830.GA9032@imp.flyn.org \
--to=mike@flyn.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).