Anyone looked into this?
----------------------------------------------------------------------
Mike A. Harris - Linux advocate - Open source advocate
This message is copyright 2000, all rights reserved.
Views expressed are my own, not necessarily shared by my employer.
----------------------------------------------------------------------
---------- Forwarded message ----------
Date: Fri, 22 Dec 2000 00:14:42 +0100
From: Ralf-Philipp Weinmann <[email protected]>
To: [email protected]
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: The NSA's Security-Enhanced Linux
citing http://www.nsa.gov/selinux/background.html:
"Researchers in the Information Assurance Research
Office of the National Security Agency (NSA) worked
with Secure Computing Corporation (SCC) to develop a
strong, flexible mandatory access control architecture
based on Type Enforcement, a mechanism first
developed for the LOCK system. The NSA and SCC
developed two Mach-based prototypes of the
architecture: DTMach and DTOS. The NSA and SCC
then worked with the University of Utah's Flux research
group to transfer the architecture to the Fluke research
operating system. During this transfer, the architecture
was enhanced to provide better support for dynamic
security policies. This enhanced architecture was named
Flask. The NSA is now integrating the Flask architecture
into the Linux operating system to transfer the
technology to a larger developer and user community."
[...]
The result is available for download at the above URL
as well. Has anyone here toyed with it already ?
Cheers,
-Ralf
--
Ralf-P. Weinmann <[email protected]>
PGP fingerprint: 2048/46C772078ACB58DEF6EBF8030CBF1724
Emacs is my operating system, and Linux its device driver.
-- Bake Timmons
On Fri, 22 Dec 2000, Mike A. Harris wrote:
> The result is available for download at the above URL as well. Has
> anyone here toyed with it already ?
<paranaoia>
I'd eyeball the sources for backdoors, if I were you.
</paranaoia>
Cheers,
Alex
--
Here, have some homemade chocolate biscuits.
http://www.tahallah.clara.co.uk
On Fri, Dec 22, 2000 at 10:39:03AM +0000, Alex Buell wrote:
> On Fri, 22 Dec 2000, Mike A. Harris wrote:
> > The result is available for download at the above URL as well. Has
> > anyone here toyed with it already ?
> <paranaoia>
> I'd eyeball the sources for backdoors, if I were you.
> </paranaoia>
Hey, this is open source here. We'll "many eyeball the source".
That's a given... :-)
> Cheers,
> Alex
> --
> Here, have some homemade chocolate biscuits.
> http://www.tahallah.clara.co.uk
Mike
--
Michael H. Warfield | (770) 985-6132 | [email protected]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
"Mike A. Harris" wrote:
>
> Anyone looked into this?
It's an implementation of Domain Enforcement, ported
from the flask project. It is a prototype.
Persons looking for backdoors, tricks, traps, snares,
or ice are going to be disappointed. It's just code
like everone else produces. Much of the work was done
by employees of the NSA. They should be applauded for
the effort they put in just to be allowed to make this
available.
--
Casey Schaufler Manager, Trust Technology, SGI
[email protected] voice: 650.933.1634
[email protected] Pager: 888.220.0607
Casey Schaufler wrote:
>
> "Mike A. Harris" wrote:
> >
> > Anyone looked into this?
>
> It's an implementation of Domain Enforcement, ported
> from the flask project. It is a prototype.
These folks are good at what they do and the code is GPL.
It is worth starting to consider whether this code, or code
from one of the other security-enhancement projects, should
be included in the standard kernel for 2.6 or 3.0.
A more secure Linux would be great for a lot of people, but
we need to look at the trade-offs. Does the approach damage
usability? Are there better ways? ... ?
> Persons looking for backdoors, tricks, traps, snares,
> or ice are going to be disappointed.
That won't, and shouldn't, stop anyone having a good look.
> It's just code like everone else produces.
So people looking at it may find bugs and vulnerabilities the
implementers hadn't considered. Great.
> Much of the work was done
> by employees of the NSA. They should be applauded for
> the effort they put in just to be allowed to make this
> available.
<applause intensity=loud>
Bravo!
>/applause>
> These folks are good at what they do and the code is GPL.
> It is worth starting to consider whether this code, or code
> from one of the other security-enhancement projects, should
> be included in the standard kernel for 2.6 or 3.0.
I think this is a good point. Its actually a nice testimonial for free
software that its finally got the NSA contributing code in a way that everyone
benefits from and which may help cut down computer crime beyond government.
(and which of course actually is part of the NSA's real job)
> > It's just code like everone else produces.
>
> So people looking at it may find bugs and vulnerabilities the
> implementers hadn't considered. Great.
Yep. Im sure all sorts of people will be finding bugs in it because they are
looking for secret NSA backdoors so why discourage them 8)
On Fri, Dec 22, 2000 at 06:39:49PM +0000, Alan Cox wrote:
> > These folks are good at what they do and the code is GPL.
> > It is worth starting to consider whether this code, or code
> > from one of the other security-enhancement projects, should
> > be included in the standard kernel for 2.6 or 3.0.
> I think this is a good point. Its actually a nice testimonial for free
> software that its finally got the NSA contributing code in a way that everyone
> benefits from and which may help cut down computer crime beyond government.
> (and which of course actually is part of the NSA's real job)
> > > It's just code like everone else produces.
> > So people looking at it may find bugs and vulnerabilities the
> > implementers hadn't considered. Great.
> Yep. Im sure all sorts of people will be finding bugs in it because they are
> looking for secret NSA backdoors so why discourage them 8)
Now that's a real damn good point that I hadn't thought of.
With everyone so paranoid about what backdoors they may have left (like
they would be that crazy to put them in and put it out in plain view
for everyone) that the code should end up getting a real good review
for bugs as well. :-) Such a deal. :-)
Mike
--
Michael H. Warfield | (770) 985-6132 | [email protected]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
On Fri, Dec 22, 2000 at 06:39:49PM +0000, Alan Cox wrote:
>
> I think this is a good point. Its actually a nice testimonial for free
> software that its finally got the NSA contributing code in a way that everyone
> benefits from and which may help cut down computer crime beyond government.
> (and which of course actually is part of the NSA's real job)
I often wonder how many people know that a whole bunch of the Linux
networking code is Copyrighted by the NSA. I'm always waiting to
hear someone come up with a conspiracy theory about it on slashdot,
but I have never heard anyone mention it.
Jim
On Fri, 22 Dec 2000, James Lewis Nance wrote:
> > benefits from and which may help cut down computer crime beyond government.
> > (and which of course actually is part of the NSA's real job)
>
> I often wonder how many people know that a whole bunch of the Linux
> networking code is Copyrighted by the NSA.
Not exactly by NSA itself. A bunch of files have in copyright comment:
---8<---
Written 1992-94 by Donald Becker.
Copyright 1993 United States Government as represented by the
Director, National Security Agency.
This software may be used and distributed according to the terms
of the GNU Public License, incorporated herein by reference.
The author may be reached as [email protected], or C/O
Center of Excellence in Space Data and Information Sciences
Code 930.5, Goddard Space Flight Center, Greenbelt MD 20771
--->8---
...so this is the result of Becker's employment at NASA and government's
legal weirdness (no, I have no idea, why of all possible choices
"Director, National Security Agency" must represent US government for
copyright purpose).
> I'm always waiting to
> hear someone come up with a conspiracy theory about it on slashdot,
> but I have never heard anyone mention it.
Actually I have seen it mentioned there today -- maybe conspiracy
theory is being developed right now ;-)
--
Alex
Hi,
On Fri, Dec 22, 2000 at 06:39:49PM +0000, Alan Cox wrote:
> > These folks are good at what they do and the code is GPL.
> > It is worth starting to consider whether this code, or code
> > from one of the other security-enhancement projects, should
> > be included in the standard kernel for 2.6 or 3.0.
>
> I think this is a good point. Its actually a nice testimonial for free
> software that its finally got the NSA contributing code in a way that everyone
> benefits from and which may help cut down computer crime beyond government.
> (and which of course actually is part of the NSA's real job)
I wonder how their approach compares to the RSBAC stuff, though.
The RSBAC (by Amon Ott) has all the infrastructure available to have
policy based access control; whenever an access decision has to be
taken, a call via some interface is made to a module, which then
takes the decision ... Just like PAM in userspace.
http://www.rsbac.org/
I think it's a good approach and I think, it has gone much further
than the NSA stuff. I'd prefer to have RSBAC merged in 2.5.
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
On Fri, 22 Dec 2000, Alex Belits wrote:
> ...so this is the result of Becker's employment at NASA and government's
> legal weirdness (no, I have no idea, why of all possible choices
> "Director, National Security Agency" must represent US government for
> copyright purpose).
Director is just under "The Office Inspector General of NSA".
Basically a division head that reports only to the OIG.
Trust that I know what I am talking about. ;-)
Cheers,
Andre Hedrick
CTO Timpanogas Research Group
EVP Linux Development, TRG
Linux ATA Development
On Sat, 23 Dec 2000, Kurt Garloff wrote:
> I wonder how their approach compares to the RSBAC stuff, though.
> The RSBAC (by Amon Ott) has all the infrastructure available to have
> policy based access control; whenever an access decision has to be
> taken, a call via some interface is made to a module, which then
> takes the decision ... Just like PAM in userspace.
> http://www.rsbac.org/
The Security-Enhanced Linux has a well-defined architecture (named Flask)
for flexible mandatory access controls that has been experimentally
validated through several prototype systems (DTMach, DTOS, and Flask).
The architecture provides clean separation of policy from enforcement,
well-defined policy decision interfaces, flexibility in labeling
and access decisions, support for policy changes, and fine-grained
controls over the kernel abstractions. Detailed studies have been
performed of the ability of the architecture to support a wide variety of
security policies and are available on the DTOS and Flask web pages
accessible via the Background page
(http://www.nsa.gov/selinux/background.html). A published paper about
the Flask architecture is also available on the Background page. The
architecture and its implementation in Linux are described in detail in
the documentation (http://www.nsa.gov/selinux/docs.html).
RSBAC appears to have similar goals to the Security-Enhanced Linux.
Like the Security-Enhanced Linux, it separates policy from enforcement
and supports a variety of security policies. RSBAC uses a different
architecture (the Generalized Framework for Access Control or GFAC) than
the Security-Enhanced Linux, although the Flask paper notes that at the
highest level of abstraction, the the Flask architecture is consistent
with the GFAC. However, the GFAC does not seem to fully address the issue
of policy changes and revocation, as discussed in the Flask paper. RSBAC
also differs in the specifics of its policy interfaces and its controls,
but a careful evaluation of the significance of these differences has
not been performed.
--
Stephen D. Smalley, NAI Labs
[email protected]