Slashdot Mirror

While they can make "under-the-hood" changes legally with Linux, they are limited to suggestions on how to configure Microsoft products. More flexibility.

Besides, every software solution Uncle Sam doesn't have to pay for saves taxpayer dollars, and no Congressman can be against that. Even NASA takes lowest bidder, and they do do rocket science!

Asking a lot? Hey, I'm a taxpayer, I PAID for this thing. Besides, the National Security Agency (NSA) offers a course to anybody on just this subject here....

Nor does the NSA, according to http://www.nsa.gov/about_nsa/faqs_internet.html#cu rrent; moreover, if they did, they would have to be non-US citizens not on US soil (note that it was not the NSA intercepting the message of this USAF individual, as most USAF folk are US citizens or permanent residents). See http://www.nsa.gov/about_nsa/faqs_internet.html#ri ghts

Nor does the NSA, according to http://www.nsa.gov/about_nsa/faqs_internet.html#cu rrent; moreover, if they did, they would have to be non-US citizens not on US soil (note that it was not the NSA intercepting the message of this USAF individual, as most USAF folk are US citizens or permanent residents). See http://www.nsa.gov/about_nsa/faqs_internet.html#ri ghts

A more appropriate symbol would be a penguin using the NSA Key to bash in the head of the commie penguin who symbolizes Red Flag Linux.

This version of Linux is NOT, REPEAT NOT any more secure than any other distro as far as most of us have a sense of the word. What is does do is a couple of things.

1) It shuts off almost all services and ports by default. Unless you specify it, it does not enable it.

2) It includes (rather clever and robust) methods for autheticating a user and his/her permissions and/or clearance levels on-the-fly in a secure manner called Flask. If you read this document, it explains it in very precise terms (if somewhat dryly).

The articles linked from the last time NSALinux was covered were better, but ./ is screwy today and I can't get it to come up.

From the brief summary, it looks like this would be very useful to protect a Linux system against malicious code, worms, and many other forms of attacks. For example, rather than trying to find and fix every buffer overrun in sendmail, you could keep sendmail from becoming destructive even if it is compromised. And you don't have to blindly trust every RPM and Debian package you install anymore, you can instead define policies for what the executables in that package may and may not do (e.g., an audio player probably has not business accessing /dev/hda).

"There is even a system called TEMPEST that detects electromagnetic emanations from a computer monitor." ?

Really ?! And here I thought it was a code word, perhaps even an acronymn, that that identifies a classified set of standards and endorsements for LIMITING electromagnetic emissions radiated from electronic equipment.

So for all you confused members of the press:

• The Complete, Unofficial TEMPEST Information Page
• TEMPEST in a teapot
• NSA/ISSO TEMPEST Endorsement Program

Still, I'm a bit bemused by the fact a mobster was smart enough to use PGP. I can only imagine what a savvy cartoonist would do with the Mafia's idea of TEMPTEST hardware !

Add-on v0.01:I missed NSA on the members list. Their knowledge from their Security-Enhanced Linux could be valuable.

Add-on v0.02: Good idea as more and more computers are hooked up to DSL, Cable, Ethernet a.s.o. (At least far from every body is hooked up here in Norway.) These are just sitting ducks for wannabe/newbee crackers.

Information about the contributors to SELinux is here. Briefly, the NSA seems to be doing the bulk of the kernel work, while NAI, Secure Computing Corporation, and MITRE are working on utilities, MACs, and policy configurations.

Something's wrong with your eyesight if you can't see it right in the dang middle of the http://www.nsa.gov website. Not to mention a link was posted up by timothy in the article above.

Kinda like the Allchin, Balmer and Gates rants: All we want is for publically funded development to not be released under the GPL - not like that *ever* happens - but now we'll use that as a segue into a reant on the evils of the GPL.

Of course it happens. This government created code is GPL'd

If you try to access their reccomendation guides you get redirected to http://www.nsa.gov/winsecnote.htm which says:

Because of the amount of interest in the Windows 2000 Security Recommendation Guides, we are updating our Web site to better handle the demands placed on downloading the files. We expect to make the guides available once again during the week of June 18, 2001.

Because of the amount of interest in the Windows 2000 Security Recommendation Guides, we are updating our Web site to better handle the demands placed on downloading the files. We expect to make the guides available once again during the week of June 18, 2001.

Windows 2000 Security Recommendation Guides

Maintain a questioning attitude

They say: "Because of the amount of interest in the Windows 2000 Security Recommendation Guides, we are updating our Web site to better handle the demands placed on downloading the files. We expect to make the guides available once again during the week of June 18, 2001."

It makes you wonder, if it's all because of the /. readers or if their security releases are indeed so popular.

As another point of interest... they also have "security-enhanced Linux modules" at http://www.nsa.gov/selinux/download.html

I started reading the Guide to Securing Microsoft Windows 2000 File and Disk Resources and one of the first things they recommend is to "Apply the latest Windows 2000 service pack and security-related hotfixes." I'm not MS bashing here, but isn't that a (cough) BAD IDEA?? I don't care if it's W2K, Linux, Solaris, etc. -- that's just not the way you run a production server, let alone a workstation that you are trying to make as secure as possible for sensitive info. You should always test out any patches/fixes/service packs. I would think the wording would be, "Apply the latest **NSA APPROVED** Windows 2000 service pack and security-related hotfixes."

Quoteth the raven:
The site www.nsa.gov is running Apache/1.3.11 (Unix) on Solaris

Um. May I suggest you read this document which explains the philosophy behind the kernel modifications.

Securing Windows 2000 and 'forking' (actually patching) the Kernel were both done with different goals.

In a nutshell, the modifications done to the kernel were done to impliment the 'Flask' security architecture, which (mainly) is about separation between setting and enforcing security policies, and how this is applied to the various types of resources. In addition, SELinux was the by-product of a research project, and is not used operationally by the NSA.

The suggested configurations for Windows 2000 have different goals, and is not a handbook for implimenting the Flask architecture on Windows 2000.

on the NSA homepage, just below the link to the article mentioned in this post is a link Security-enhanced Linux.

If you did'nt find that on their wabpage you surely did not look very herd.

For some reason you have to go to http://www.nsa.gov/winsecurity and then proceed from there.

Interesting, there are about 18 comments as I post this and over half are jokes about unplugging the computer to make it safe. The truth of the matter is that by NSA guidelines no popular operating system is secure enough out of the box and has to be extremely looked down.

What is perhaps even more interesting is that at least Win2K can be secured to a level that is suitable for the NSA, they actually had to fork the Linux kernel to get the same functionality out of Linux.

--

Don't worry about the government making GPLd software illegal. It would only affect you if you lived in a stupid country that made encryption illegal. People who live in free countries would still be able to write and use free software.

I thought that was weird too. Just a guess, but could it be that he was referring to the security-enhanced version of linux the NSA released? I mean despite all of what Microsquish has been saying about Linux being a security threat because of its open-source nature, that has to make Linux somewhat more appealing to suits who are interested in keeping secrets.

• Operating System: Although OpenBSD is generally regarded as the best Freenix in terms of security, GNU/Linux is under more active development, faster, more user friendly and supports far more software packages and types of hardware than OpenBSD (sorry Theo, much respect...). I, along with most of the other admins and users are more familiar with a GNU environment. The distribution we use is Debian. I chose Debian for several reasons: free (libre and gratis), strong package system and reliability. It hasn't let me down. I do prefer Slackware on my personal box, since the -current tree is more stable than Debian's unstable. However, Debian's package system is nicer and provides many things that Slackware lacks (I may abandon Slackware as soon as Debian supports XF4 and kernel 2.4 by default in stable). Debian also keeps up to date on security issues.
• Kernel: We now run a Linux 2.4 kernel. Although most security tools/patches are 2.2 only, the mature (READ: usable) ones have been ported to kernel 2.4. I'm confident that more will follow. 2.2 is dead. We have disabled modules entirely in our kernel to prevent hax0ring and to avoid using modules (does anyone else hate them?). We only have a few drivers enabled. Besides helping performance, this protects against hostile code injection into the kernel. It is possible for a clever coder to inject code into a non-modular kernel, but most rootkits use kernel modules. Not allowing kernel modules and using 2.4, prevents us from using some really cool security tools like LOMAC. However, I found that LOMAC did not play nicely with OpenWall's Secure Linux patch (or cron, or init or getty ...). When Lomac behaves nicer, it will be added (I'd also like to see it as a patch rather than a module). Currently, we are using the GetRewted.net patch which provides lots of security enhancements. We may be adding more secure kernel additions such as the NSA's Security Enhanced Linux. However, at this time, we feel that the current kernel security model is both secure and usable. If you have any neat kernel goodies we might like, tell us.
• Firewall: Note that we are NOT running any sort of real firewall. We feel that the extra kernel overhead of the firewall hurts performance and adds needless complexity to the server. Since we are NOT trusting local (ie: users with shell access) anyway, we feel that a firewall is basically useless since Linux's TCP/IP stack is already fault-tolerant, mature and robust. We augmented the TCP/IP stack with this shell script to limit our vulnerability to DoS attacks. Firewalling services should not be needed if your services are secure (run with minimal priviliges and SECURE by design and condiguration). Eventually we may drop an OpenBSD or Linux 2.4 firewall in front of the server as a measure for restricting local users ability to portscan, DoS and exploit remote hosts.
• Authentication / Login: Remote interactive sessions are only supported over ssh (and we run OpenSSH). Telnet is not allowed. Rhosts authentication is not allowed. I've looked at forcing people to use S/Keys, but it is a real pain in the ass on both ends. We are currently allowing FTP in. When I'm confident that all the users can get a good graphical scp/sftp client for their platform, I'll kill FTP. Since I'm not relying on trusting local users anyway, this is more a security concern for individual users. I'm considering locking some users who don't use their shells out of real shell access.
• Users: I only make accounts for people I know personally. I also monitor user login s and their activity using whowatch and process accounting. I'm suspicious of logins from weird hosts. I also use PAM to set resource limits.
• Monitoring: We watch out for network nastiness with Snort which is an AWESOME IDS. We monitor its logs and other system activity with Psionic's LogCheck. Occasionally, I'll audit the machines for weird ports using nmap and Nessus, both of which are REALLY nice. I'll also routinely verify system integrity using a combination of Tripwire and chkrootkit, on a system booted from a known CLEAN floppy containing the tools.

• Operating System: Although OpenBSD is generally regarded as the best Freenix in terms of security, GNU/Linux is under more active development, faster, more user friendly and supports far more software packages and types of hardware than OpenBSD (sorry Theo, much respect...). I, along with most of the other admins and users are more familiar with a GNU environment. The distribution we use is Debian. I chose Debian for several reasons: free (libre and gratis), strong package system and reliability. It hasn't let me down. I do prefer Slackware on my personal box, since the -current tree is more stable than Debian's unstable. However, Debian's package system is nicer and provides many things that Slackware lacks (I may abandon Slackware as soon as Debian supports XF4 and kernel 2.4 by default in stable). Debian also keeps up to date on security issues.
• Kernel: We now run a Linux 2.4 kernel. Although most security tools/patches are 2.2 only, the mature (READ: usable) ones have been ported to kernel 2.4. I'm confident that more will follow. 2.2 is dead. We have disabled modules entirely in our kernel to prevent hax0ring and to avoid using modules (does anyone else hate them?). We only have a few drivers enabled. Besides helping performance, this protects against hostile code injection into the kernel. It is possible for a clever coder to inject code into a non-modular kernel, but most rootkits use kernel modules. Not allowing kernel modules and using 2.4, prevents us from using some really cool security tools like LOMAC. However, I found that LOMAC did not play nicely with OpenWall's Secure Linux patch (or cron, or init or getty ...). When Lomac behaves nicer, it will be added (I'd also like to see it as a patch rather than a module). Currently, we are using the GetRewted.net patch which provides lots of security enhancements. We may be adding more secure kernel additions such as the NSA's Security Enhanced Linux. However, at this time, we feel that the current kernel security model is both secure and usable. If you have any neat kernel goodies we might like, tell us.
• Firewall: Note that we are NOT running any sort of real firewall. We feel that the extra kernel overhead of the firewall hurts performance and adds needless complexity to the server. Since we are NOT trusting local (ie: users with shell access) anyway, we feel that a firewall is basically useless since Linux's TCP/IP stack is already fault-tolerant, mature and robust. We augmented the TCP/IP stack with this shell script to limit our vulnerability to DoS attacks. Firewalling services should not be needed if your services are secure (run with minimal priviliges and SECURE by design and condiguration). Eventually we may drop an OpenBSD or Linux 2.4 firewall in front of the server as a measure for restricting local users ability to portscan, DoS and exploit remote hosts.
• Authentication / Login: Remote interactive sessions are only supported over ssh (and we run OpenSSH). Telnet is not allowed. Rhosts authentication is not allowed. I've looked at forcing people to use S/Keys, but it is a real pain in the ass on both ends. We are currently allowing FTP in. When I'm confident that all the users can get a good graphical scp/sftp client for their platform, I'll kill FTP. Since I'm not relying on trusting local users anyway, this is more a security concern for individual users. I'm considering locking some users who don't use their shells out of real shell access.
• Users: I only make accounts for people I know personally. I also monitor user login s and their activity using whowatch and process accounting. I'm suspicious of logins from weird hosts. I also use PAM to set resource limits.
• Monitoring: We watch out for network nastiness with Snort which is an AWESOME IDS. We monitor its logs and other system activity with Psionic's LogCheck. Occasionally, I'll audit the machines for weird ports using nmap and Nessus, both of which are REALLY nice. I'll also routinely verify system integrity using a combination of Tripwire and chkrootkit, on a system booted from a known CLEAN floppy containing the tools.

• At last week's IEEE Symposium on Security and Privacy Bill Arbaugh presented a very interesting paper on trend analysis of exploitation, as represented by CERT incident reports. Summary: most attacks exploit known security vulnerabilites that a site admin did not patch.
• Jim Reavis at Securityportal.com did this great study examining the "days of recess" for each of Red Hat, Solaris, and Windows NT. "Days of recess" is the total number of days that an exploit was known but no patch available, summed over all vulnerabilities for that platform.
• At WireX, we are working on a related concept that we call "Relative Invulnerability". Here, the idea is to consider the number of vulnerabilities for a "base" system (e.g. unpatched Red Hat 7.0) that appear over a period of months, and then consider how many of those unpatched vulnerabilities are successfully mediated by some protective technology such as SELinux or Immunix. The fraction of vulnerabilities stopped is the "relative invulnerability" of the defensive technology. This is written up in a paper that is currently being reviewed.

The NSA's SE Linux has been covered here many times.

Also mentioned in the past is PitBull from Argus Systems (I work across the street from their offices) which stood up to the OpenHack III challenge a few moths back. PitBull gives Trusted OS extentions to Solaris, AIX and Linux. (There's free non-com licenses at Argus Revolution.)

And Sun also already has a Trusted Solaris.

There's others as well.

It occurs to me that you might have meant is it a first to provide ACL support via Samba, in which case I appologize. This was of course already answered by someone else.

--

Um, actually SE Linux is totally open source you can read about it here be warned, this is pretty heady stuff view the NSA licence here if yer brave enough to follow the link hehhehheh Z1 --

It's interesting to note that NAI have been involved for months with the project - see an NSA Press Release from January here.

An interesting techy overview is available from IBM here. I'm a serious NSA-paranoid (in 98 I wrote the rhyme: "Mary had a crypto key, she kept it in escrow, and everything that Mary said, the Feds were sure to know."), but I for one think that NSA 'hardened' Linux is a VERY good thing....Don't forget that, as well as being dirty spying bastards , the NSA (and the rest of the USG) are the largest consumers of secure computing.

At the moment they pay through the nose for 'hardened' versions of AIX, Solaris, HP-UX etc. They see that Linux is a 'free' alternative and would like to cut costs. They see that Linux isn't secure enough (e.g. would struggle to get c2 rating, let along B*), so they decide to start coding themselves, adding functionality such as MAC.

Rather than keep the changes themselves, the NSA decide to share the source code back with the community - this really embraces the Free Software / Linux philosophy. Any code released will be scrutinized no end - a peer review of the initial code for example uncovered a potential buffer overflow vulnerability.

I appreciate that my comments may not be popular with the ultra-paranoid, but if you can objectively view the facts this development really is a good thing for Linux. Hell, if you don't want to use the changes, then don't apply the diffs.

The bottom line: I strongly support NAI in their efforts to further develop Linux.

Funny!

But for reference: it's licenced under the GPL - that's the normal GPL.

Stupid me: should have checked the NSA web site for the information.

[NSA] coordinates, directs, and performs highly specialized activities to protect U.S. information systems and produce foreign intelligence information.

A security enhanced kernel is a good fit with their overall mission. A kernel with a backdoor does not fit well with this mission at all.

I'm not suggesting that these changes not be scrutizined, they should be looked at very carefully. Let's look and see what they have to offer before we make up our minds either way.

However, if the intention was to allow these ideas, and research based on them, to be used in the overwhelming majority of operating systems which are not licensed under the GPL, the NSA made the wrong choice. Based on the comments, it sounds like this was indeed the intention, so it is likely the people who approved the use of Linux didnt understand the GPL. Maybe this is was spurred Jim Allchins well-known comment about `educating legislators.

From the NSA web site:

"Then came the Holy One, blessed be He, and slew the angel of death, that killed the shohet that slaughtered the ox that drank the water that quenched the fire that burned the stick that beat the dog that bit the cat that ate the goat my father bought for two zuzim."

One type of free-space transmitter, a type that has no battery, is the so-called "resonant cavity" transmitter. The Great Seal of the United States in the Moscow Embassy concealed such a device. As has been reported extensively in the media, a wooden wall plaque was presented as a gift along with the suggestion of mounting it on the wall behind the Ambassador's desk. Many may recall the photograph of Ambassador Lodge pointing to a "bug" concealed in the back of the plaque. The embarrassment caused by the detection of this transmitter motivated the intelligence community to spring into action and devices similar to it soon evolved.

Yes, the roles of the NSA are diverse and growing. From the About the NSA

The National Security Agency is the Nation's cryptologic organization. It coordinates, directs, and performs highly specialized activities to protect U.S. information systems and produce foreign intelligence information. [...]

From The Evolution of the U.S. Intelligence community

The 1950s Acting on the recommendations of a commission of senior officials headed by George Brownell, President Truman, by classified memorandum , established the National Security Agency (NSA) in October 1952 in recognition of the need for a single entity to be responsible for the signals intelligence mission of the United States. Placed within the Department of Defense, NSA assumed the responsibilities of the former Armed Forces Security Agency as well as the signals intelligence responsibilities of the CIA and other military elements. In 1958, the National Security Council issued directives that detailed NSA's mission and authority under the Secretary of Defense.

The secrecy was probably the only way to combine the groups handling sensitive material which were competing for the same job.

Keeping sensitive information from wandering off is necessary if espionage exists. Even after 50 years captured information is useful. See the now declassified (well mostly) VENONA project.

Finally, have a look at NSA via slashdot's past in

• Interviews: Crypto Guru Bruce Schneier Answers
• Ask Slashdot: What's the Real NSA Like?

One type of free-space transmitter, a type that has no battery, is the so-called "resonant cavity" transmitter. The Great Seal of the United States in the Moscow Embassy concealed such a device. As has been reported extensively in the media, a wooden wall plaque was presented as a gift along with the suggestion of mounting it on the wall behind the Ambassador's desk. Many may recall the photograph of Ambassador Lodge pointing to a "bug" concealed in the back of the plaque. The embarrassment caused by the detection of this transmitter motivated the intelligence community to spring into action and devices similar to it soon evolved.

Yes, the roles of the NSA are diverse and growing. From the About the NSA

The National Security Agency is the Nation's cryptologic organization. It coordinates, directs, and performs highly specialized activities to protect U.S. information systems and produce foreign intelligence information. [...]

From The Evolution of the U.S. Intelligence community

The 1950s Acting on the recommendations of a commission of senior officials headed by George Brownell, President Truman, by classified memorandum , established the National Security Agency (NSA) in October 1952 in recognition of the need for a single entity to be responsible for the signals intelligence mission of the United States. Placed within the Department of Defense, NSA assumed the responsibilities of the former Armed Forces Security Agency as well as the signals intelligence responsibilities of the CIA and other military elements. In 1958, the National Security Council issued directives that detailed NSA's mission and authority under the Secretary of Defense.

The secrecy was probably the only way to combine the groups handling sensitive material which were competing for the same job.

Keeping sensitive information from wandering off is necessary if espionage exists. Even after 50 years captured information is useful. See the now declassified (well mostly) VENONA project.

Finally, have a look at NSA via slashdot's past in

• Interviews: Crypto Guru Bruce Schneier Answers
• Ask Slashdot: What's the Real NSA Like?

One type of free-space transmitter, a type that has no battery, is the so-called "resonant cavity" transmitter. The Great Seal of the United States in the Moscow Embassy concealed such a device. As has been reported extensively in the media, a wooden wall plaque was presented as a gift along with the suggestion of mounting it on the wall behind the Ambassador's desk. Many may recall the photograph of Ambassador Lodge pointing to a "bug" concealed in the back of the plaque. The embarrassment caused by the detection of this transmitter motivated the intelligence community to spring into action and devices similar to it soon evolved.

Yes, the roles of the NSA are diverse and growing. From the About the NSA

The National Security Agency is the Nation's cryptologic organization. It coordinates, directs, and performs highly specialized activities to protect U.S. information systems and produce foreign intelligence information. [...]

From The Evolution of the U.S. Intelligence community

The 1950s Acting on the recommendations of a commission of senior officials headed by George Brownell, President Truman, by classified memorandum , established the National Security Agency (NSA) in October 1952 in recognition of the need for a single entity to be responsible for the signals intelligence mission of the United States. Placed within the Department of Defense, NSA assumed the responsibilities of the former Armed Forces Security Agency as well as the signals intelligence responsibilities of the CIA and other military elements. In 1958, the National Security Council issued directives that detailed NSA's mission and authority under the Secretary of Defense.

The secrecy was probably the only way to combine the groups handling sensitive material which were competing for the same job.

Keeping sensitive information from wandering off is necessary if espionage exists. Even after 50 years captured information is useful. See the now declassified (well mostly) VENONA project.

Finally, have a look at NSA via slashdot's past in

• Interviews: Crypto Guru Bruce Schneier Answers
• Ask Slashdot: What's the Real NSA Like?

One type of free-space transmitter, a type that has no battery, is the so-called "resonant cavity" transmitter. The Great Seal of the United States in the Moscow Embassy concealed such a device. As has been reported extensively in the media, a wooden wall plaque was presented as a gift along with the suggestion of mounting it on the wall behind the Ambassador's desk. Many may recall the photograph of Ambassador Lodge pointing to a "bug" concealed in the back of the plaque. The embarrassment caused by the detection of this transmitter motivated the intelligence community to spring into action and devices similar to it soon evolved.

Yes, the roles of the NSA are diverse and growing. From the About the NSA

The National Security Agency is the Nation's cryptologic organization. It coordinates, directs, and performs highly specialized activities to protect U.S. information systems and produce foreign intelligence information. [...]

From The Evolution of the U.S. Intelligence community

The 1950s Acting on the recommendations of a commission of senior officials headed by George Brownell, President Truman, by classified memorandum , established the National Security Agency (NSA) in October 1952 in recognition of the need for a single entity to be responsible for the signals intelligence mission of the United States. Placed within the Department of Defense, NSA assumed the responsibilities of the former Armed Forces Security Agency as well as the signals intelligence responsibilities of the CIA and other military elements. In 1958, the National Security Council issued directives that detailed NSA's mission and authority under the Secretary of Defense.

The secrecy was probably the only way to combine the groups handling sensitive material which were competing for the same job.

Keeping sensitive information from wandering off is necessary if espionage exists. Even after 50 years captured information is useful. See the now declassified (well mostly) VENONA project.

Finally, have a look at NSA via slashdot's past in

• Interviews: Crypto Guru Bruce Schneier Answers
• Ask Slashdot: What's the Real NSA Like?

There really is a National Puzzle Center run by the NSA. Typical question: Which of the following palettes represents a possible PNG palette?

Another problem with many crypto offerings is that they can leave you vulnerable to forensic-grade tools that can pull data from supposedly deleted files, including the temporary files that your e-mail application uses as a placeholder for the message before it's encrypted. It seems to me that the only way to get a truly secure solution is to write a mail application that has the encryption built in at the most fundamental level, so that even if temporary files are recovered, they may be rendered useless.

At the same time, I don't want to think about how many people are using weak passphrases -- a sequence that is hashed with random numbers to produce the encipherment key -- which might be easy to remember, but won't stand up under a brute-force attack.

Hello? 1/4 of the article talks about how it has nothing to do with crypto. It's a security *model*, concerned with access control. You don't even need their code to implement the design.

In fact, it looks like some good grist for the eternal acls vs. crufty old unix security argument. They seem to have solved a lot of nagging issues by just moving the SIDs out of the object definition and maintaining mapping externally (to the file, not the system!). From the diagrams, it looks like security info is just stored in regular files on whatever filesystem you're securing. This scheme could even be used to secure FAT! Unless I'm misreading everything...

This seems like a perfect match for linux, with its goal of filesystem interoperability. I hope the fact that it comes from the NSA and looks (to the user) a lot like the w2k model doesn't keep people from taking a closer look. In particular, I'd like to hear from the "linux/acls don't mix" crowd, to see if any of their objections are answered by this architecture.

Those interested should probably check out the nsa itself. Turn off those cookies!

While I do use GNU/Linux on my workstation, I think OpenBSD is by far the most secure OS on the planet

Well, that just shows that there's more to security than you realize. OpenBSD may be more secure than other typical Unix-type systems because of its code auditing, it still has all of the architectural problems that Unix suffers from in general- basically that a single broken SUID program compromises the whole system. OpenBSD has had fewer exploits turn up over the years, but when one is discovered the system is just as open to crackers as other Unices.

The goal of SE Linux is to add on mandatory access controls. Mandatory access controls are very powerful, but tend to add a lot of complexity. They add a whole different layer of compartmentalization, so that users and programs simply aren't allowed to do many operations, even if they somehow get root privileges. That's the route to true security, becuase it means that you can maintain substantial system security even if some of your programs are broken or contain Trojan Horses. Try reading some of the documentation about why the NSA sees this as important, and you might learn a bit out making really secure systems.

http://www.nsa.gov/korea/papers/sigint_background_ korean_war.htm

Integrating Security-Enhanced Linux, the set of kernel and tool extensions to Linux (it is an NSA implementation of the University of Utah Flask secure system architecture) would be a much better Linux enhancement in the long run.

The architecture provides a single mechanism for enforcing security and seperates it from the security policy which can be modified to suit different needs (e.g., you could use it to implement ACLs, RBAC, Chinese Wall, MLS, or other types of security policies).

I seriously doubt Linus would consider integration of the extensions anytime soon because they touch so much of the code base. Plus, it's still on the researchy side of things (you *have* to use RedHat 6.1 or 7.0 to make it work at this point, for example). But once you get it working, it's amazing what kind of potential you can see in the system for enhancing security.

But the mechanism it provides makes it possible to restrict access on a very fine-grained level in a fashion similar to what this article talks about. And it could make the security features of Linux lightyears ahead of what NT provides. It would also be the first free software operating system to provide mandatory access control mechanisms.

BTW, SE Linux is a good example of why the claim that "open source" is never innovative is completely untrue; how proprietary code is and how innovative it is are orthogonal issues.

So this "change", is really just rewriting Rijndael to fit the NIST's proposal. Check the original 1997 request for candiates.

I don't know what it is about cryptography that causes people to widly speculate about it, but unless you have any evidence, I claim that there is no known backdoors in DES, or AES. Period.

If you read Steven Levy's Crypto, chapter 2, you'll see that DES was quite strong in its day. Its structure now makes sense, once the T-attack was rediscovered by Biham and Shamir as differential cryptanalysis. The only just criticism of DES was that even then 56-bit was conceiviable weak in the future, not in the 1970s when it was first made standard.

The NSA has two responsibilities , to gather national intelligences, and to preserve the US Government's own security. The AES will be used as the standard encryption for non-classified (basicilly non-military) security, and willing likely be adopted by X9 as a sucessor to TripleDES for banking and international financial security. Using a weak algorithm for AES is would not make the NSA's responsibility of protecting the US Government's security easier, so I do not see the benefit of trying to do such a thing.

Try Security Enhanced Linux.

DARPA is trying to advance what's already available - and advances in security would be great. I suspect they will be able to make advances, since they're planning to spend $10 million on the winning proposals. As has been noted, OpenBSD is not a perfect solution - its packages are often quite old and it has many functionality limits (e.g., no support for SMP). It also doesn't meet the principle of "least privilege" - root is still all-powerful, programs can do anything their owners can, etc.

The deadline is soon for those interested in submitting a proposal. The full proposal (all copies) must be submitted in time to reach DARPA by 4:00 PM (U.S. Eastern Time) Monday, March 5, 2001, in order to be considered; it CANNOT be sent by email or fax (they REQUIRE PHYSICAL COPIES).

People interested in submitting a proposal should also read the Proposer Information Pamphlet (PIP), which isn't easy to find unless you know where it is.