 |
|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
|
|
|
"Just as in the private sector, many federal agencies are reluctant to make the investments required in this area [of computer security] because of limited budgets, lack of direction and prioritization from senior officials, and general ignorance of the threat."
|
As of today the quote above stands the test of the time. Limited budgets are not longer the case in government. But "lack of direction and prioritization from senior officials" as well as "ignorance" (not so much "ignorance of the threat" but general ignorance ;-) are still here.
Businesses are more conservative and more realistic. Even as mass media fret over everything from hacker threats to cyber terrorism, the majority of companies is reluctant to spend money on security. And probably rightly so, because the return on investment is questionable and in the current economic climate the money are tight. A full 40% of IT managers recently surveyed by IDC cite IT security as their No. 1 priority. But less than 10% want to increase their security budgets ;-) How can this be?
The answer is that despite the risks at the end of the day additional security measures does not save money or generate revenue. Moreover often they are useless or even harmful. 80% of the enterprise security is actually a byproduct of a sound architecture and other technical decisions. It looks like security is better dealt with on this level than increasing security staff or by paying top bucks to some Fortune 100 company for sending a couple of clueless or semi-clueless consultants who supposedly are able to fix the problems that the latest attack revealed in the infrastructure they do not understand :-).
In case of consultant it also can lead to the decision to buy and install YAPUST ("yet another pretty useless security tool"). For example network IDS are fashionable now, but in most cases they produce so many false positives that after a while all warnings they are safely ignored or most useful (but noisy) rules are simply disabled ;-). Network IPS are mostly harmful and better be avoided unless the organization has top guns in networking group (in this case the question arise why they are needed ?). And senior administration still believes that IDS/IPS is in place and "the company is protected" ... See also "Softpanorama laws of security"
Actually semi-forgotten network IDS sensor is pretty benign example.
"Security Uber Alles" types can do a lot of damage to productivity without any real
improvements in security. IPS is only one of many way to harm the company.
In some companies hidden sadists somehow became firewall administrators :-(.
Still, there are a few bright spots. The first one is
open source security tools. They are free
and some of them are as good or even better/more flexible than their commercial
counterparts. Not to deploy them in some cases is as close to negligence as one
can get. Second is security training with some useful WEB resources both government
(CERT, NIST
National Checklist Program,
NSA) and
non-government (SANS,
SecurityFocus (hosts
BugTrack list),
searchSecurity, etc).
Security certification also might be useful if you consider it not an end in itself but as a first step. For additional references see also other pages on this site including my Solaris Security page and Security certification page. IS-security training for system and network administrators can substantially boost the level of security of IS without or with very little additional spending. That's why it's surprising to see that relatively few companies are making investments to ensure that their IT teams know how to secure their network and technology infrastructures, despite all the attention surrounding security since Sept 11. That's why I created this page. Not that I have any illusions about any particular Security certification ;-).
According to the InformationWeek Global Information Security Survey, fielded by Pricewaterhouse Coopers, only 27% of U.S. companies have conducted security training for system and network administrators. That statistic is only slightly better than the one in four companies around the globe (the study reached 8,100 people in 50 countries) that have conducted such training. That's why self-education is so important.
Dr. Nikolai Bezroukov
|
|||||||
"A lot of activity [in various security camps] stems from public-relations posturing." "What does the whole security labeling give you? Except for more fodder for either of the PR camps that I obviously think are both idiots pushing for their own agenda?" Torvalds says. "It just perpetrates that whole false mind-set" and is a waste of resources, he says.
Creator of the Linux kernel explains why he finds security people to be so anathema 08/14/2008 , Network World Linus Torvalds, creator of the Linux kernel, says he's fed up with what he sees as a "security circus" surrounding software vulnerabilities and how they're hyped by security people.Torvalds explained his position in an e-mail exchange with Network World this week. He also expanded on critical comments he made last month that caused a stir in the IT industry.
Last month Torvalds stated in an online posting that "one reason I refuse to bother with the whole security circus is that I think it glorifies -- and thus encourages -- the wrong behavior. It makes 'heroes' out of security people, as if the people who don't just fix normal bugs aren't as important. In fact, all the boring normal bugs are way more important, just because there's a lot more of them."
Never one to mince words, Torvalds also lobbed a verbal charge at the OpenBSD community: "I think the OpenBSD crowd is a bunch of masturbating monkeys, in that they make such a big deal about concentrating on security to the point where they pretty much admit that nothing else matters to them."
This week Torvalds -- who says the only person involved in the OpenBSD community with whom he talked to about the "monkeys" barb found it funny -- acknowledges others probably found it offensive.
Via e-mail, he also explains why he finds security people to be so anathema.
Too often, so-called "security" is split into two camps: one that believes in nondisclosure of problems by hiding knowledge until a bug is fixed, and one that "revels in exposing vendor security holes because they see that as just another proof that the vendors are corrupt and crap, which admittedly mostly are," Torvalds states.
Torvalds went on to say he views both camps as "crazy."
"Both camps are whoring themselves out for their own reasons, and both camps point fingers at each other as a way to cement their own reason for existence," Torvalds asserts. He says a lot of activity in both camps stems from public-relations posturing.
He says neither camp is absolutely right in any event, and that a middle course, based on fixing things as early as possible without a lot of hype, is preferable.
"You need to fix things early, and that requires a certain level of disclosure for the developers," Torvalds states, adding, "You also don't need to make a big production out of it."
Torvalds also says he doesn't care for labeling updates and changes to Linux as a security fix in a security advisory.
"What does the whole security labeling give you? Except for more fodder for either of the PR camps that I obviously think are both idiots pushing for their own agenda?" Torvalds says. "It just perpetrates that whole false mind-set" and is a waste of resources, he says.
It's better to avoid sticking solely to either "full and immediate disclosure" or ignoring bugs that might embarrass vendors, he points out. "Any situation that allows the vendor to sit on the bug for weeks or months is unacceptable, as is any situation that makes it harder for people who find problems to talk to technical people."
Torvalds says he's skeptical about the value of synchronized releases among vendors that favor the idea of an embargo of software vulnerability information until a fix from a vendor is ready.
That process discourages thinking about design changes to make it harder to have security bugs, Torvalds says. "So, the whole 'embargoes are good' mentality is just corruption from the vendors," he states. "But on the other hand, disclosure should not be the goal."
"I don’t believe in either camp," Torvalds concludes. What he does favor is to "have a model where security is easier to do in the first place -- that is, the Unix model -- but make it easy for people to report bugs with no embargo, but privately."
He says the Linux kernel security list "is private" in the sense that "we don't need to leak things out further" to get some software issue fixed. He says the process allows, though doesn't encourage, a five-day embargo, and "even then, I will forward it to technical people on an 'as needed' basis, because even that embargo secrecy is not some insane absolute thing."
Comments
I can't believe the genius behind Linux referred to proactively fixing all bugs, regardless of security implications as "masturbating", since that's quite obviously...
May 16, 2008
As has been widely reported, the maintainers of Debian's OpenSSL packages made some errors recently that have potentially compromised the security of any sshd-equipped system used remotely by Debian users. System administrators may wish to purge authorized_key files of public keys generated since 2006 by affected client machines.
Simply using a Debian-based machine to access a remote server via SSH would not be enough to put the machine at risk. However, if the user copied a public key generated on a Debian-based system to the remote server, for example to take advantage of the higher security offered by password-free logins, then the weak key could make the server susceptible to brute-force attacks, especially if the user's name is easily guessable.
Administrators of servers that run SSH may wish to go through users' authorized key files (typically ~/.ssh/authorized_keys), deleting any that may have been affected. A "detector" script, available here, appears to compare public key signatures against a list of just 262,800 entries. That in turn suggests that if the user's name is known, a brute force attack progressing at one guess per second could succeed within 73 hours (262,800 seconds).
A full explanation of the problem can be found here. In a nutshell, Debian's OpenSSL maintainers made some Debian-specific patches that, according to subscriber-only content at LWN.net, were aimed at fixing a memory mapping error that surfaced during testing with the valgrind utility. The unintended consequence was a crippling of the randomness of keys, making them predictable, and thus possible to guess using "brute-force" attacks. And unfortunately, the Debian maintainers failed to submit their patches upstream, and thus the problem did not surface until very recently (there's certainly a lesson to be learned, there). Not surprisingly, brute force attacks are way up this week, LWN.net also reported.
Users of Debian and Debian-based distributions such as Ubuntu should immediately upgrade the SSH software on their systems. The new ssh-client package will contain an "ssh-vulnkey" utility that, when run, checks the user's keys for the problem. Users should re-generate any affected keys as soon as possible.
Also possibly affected are "OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections," though not apparently Keys generated with GnuPG or GNUTLS. More details can be found here (Debian resource page), as well as on this webpage, which also links to lists of common keys and brute-force scripts that boast of 20-minute typical break-in times.
-- Henry Kingman
Sometimes, people do such stupid things that words almost fail me. That’s the case with a Debian ‘improvement’ to OpenSSL that rendered this network security program next to useless in Debian, Ubuntu and other related Linux distributions.OpenSSL is used to enable SSL (Secure Socket Layer) and TLS (Transport Layer Security) in Linux, Unix, Windows and many other operating systems. It also includes a general purpose cryptography library. OpenSSL is used not only in operating systems, but in numerous vital applications such as security for Apache Web servers, OpenVPN for virtual private networks, and in security appliances from companies like Check Point and Cisco.
Get the picture? OpenSSL isn’t just important, it’s vital, in network security. It’s quite possible that you’re running OpenSSL even if you don’t have a single Linux server within a mile of your company. It’s that widely used.
Now, OpenSSL itself is still fine. What’s anything but fine is any Linux, or Linux-powered device, that’s based on Debian Linux OpenSSL code from September 17th, 2006 until May 13, 2008.
What happened? This is where the idiot part comes in. Some so-called Debian developer decided to ‘fix’ OpenSSL because it was causing the Valgrind code analysis tool and IBM’s Rational Purify runtime debugging tool to produce warnings about uninitialized data in any code that was linked to OpenSSL. This ‘problem’ and its fix have been known for years. That didn’t stop our moronic developer from fixing it on his own by removing the code that enabled OpenSSL to generate truly random numbers..
After this ‘fix,’ OpenSSL on Debian systems could only use one of a range from 1 to 32,768—the number of possible Linux process identification numbers—as the ‘random’ number for its PRNG (Pseudo Random Number Generator). For cryptography purposes, a range of number like that is a bad joke. Anyone who knows anything about cracking can work up a routine to automatically bust it within a few hours.
Why didn’t the OpenSSL team catch this problem? They didn’t spot it because they didn’t see it. You see Debian developers have this cute habit of keeping their changes to themselves rather than passing them upstream to any program’s actual maintainers. Essentially, what Debian ends up doing is forking programs. There’s the Debian version and then there’s the real version.
Usually, it’s a difference that makes no difference. Sometimes, it just shows how pig-headed Debian developers can be. My favorite case of this is when they decided that rather than allow Mozilla to have control of the logo in the Firefox browser, because that wasn’t open enough according to the Debian Social Contract, they forked Firefox into their own version: Iceweasel.
That was just stupid. This is stupid and it’s put untold numbers of users at risk for security attacks.
First, the mistake itself was something that only a programming newbie would have made and I have no idea how this ever got passed by the Debian code maintainers. This is first-year programming assignment. “What is a random number generator and how do you make one?”
Then, insult to injury, because Debian never passed its ‘fix’ on to OpenSSL, the people who would have caught the problem at a glance, this sloppy, insecure mess has now been used on hundreds of thousands, if not millions, of servers, PCs, and appliances.
This isn’t just bad. This is Microsoft security bad.
Now, there’s a fix for Debian 4.0 Etch and its development builds. Ubuntu, which is based on Debian,, also have fixes for it. In Ubuntu, the versions that need patches are Ubuntu 7.04, Feisty; Ubuntu 7.10, Gutsy; the just released Ubuntu 8.04 LTS Hardy, and the developer builds of Ubuntu Intrepid Ibex.
Debian has also opened a site on how to rollover your insecure security keys to the better ones once you’ve installed the corrected software.. For more on how to fix your system, see Fixing Debian OpenSSL on my ComputerWorld blog, Cyber Cynic.
30814 CVE Vulnerabilities 160 Checklists 141 US-CERT Alerts 2192 US-CERT Vuln Notes 3259 OVAL Queries
Draft SP 800-123, Guide to General Server Security, is available for public comment.
This document is intended to assist organizations in installing, configuring, and maintaining secure servers. SP 800-123 makes recommendations for securing a server's operating system and server software, as well as maintaining the server's secure configuration through application of appropriate patches and upgrades, security testing, log monitoring, and backups of data and operating system files.
The document addresses common servers that use general operating systems and are deployed in both outward-facing and inward-facing locations.
Comments need to be received by June 13, 2008.
Posted by kdawson on Wednesday April 23, @08:03AM
from the stand-and-identify dept. captcha_fun writes"Researchers at Penn State have developed a patent-pending image-based CAPTCHA technology for next-generation computer authentication. A user is asked to pass two tests: (1) click the geometric center of an image within a composite image, and (2) annotate an image using a word selected from a list. These images shown to the users have fake colors, textures, and edges, based on a sequence of randomly-generated parameters. Computer vision and recognition algorithms, such as alipr, rely on original colors, textures, and shapes in order to interpret the semantic content of an image. Because of the endowed power of imagination, even without the correct color, texture, and shape information, humans can still pass the tests with ease. Until computers can 'imagine' what is missing from an image, robotic programs will be unable to pass these tests. The system is called IMAGINATION and you can try it out."
This sounds promising given how broken current CAPTCHA technology is.
December 28, 2007 | NIST
NIST announces the release of Special Publication 800-53, Revision 2, Recommended Security Controls for Federal Information Systems. This special update incorporates guidance on appropriate safeguards and countermeasures for federal industrial control systems.
NIST’s Computer Security Division (Information Technology Laboratory) and Intelligent Systems Division (Manufacturing Engineering Laboratory), in collaboration with the Department of Homeland Security and organizations within the federal government that own, operate, and maintain industrial control systems, developed the necessary industrial control system augmentations and interpretations for the security controls, control enhancements, and supplemental guidance in Special Publication 800-53.
The industrial control system augmentations and interpretations for Special Publication 800-53 will facilitate the employment of appropriate safeguards and countermeasures for these specialized information systems that are part of the critical infrastructure of the United States.
The changes to Special Publication 800-53, Revision 1 in updating to Revision 2, include:
- a new Appendix I, Industrial Control Systems;
- an updated low security control baseline with the addition of security control CP-4, Contingency Plan Testing and Exercises; and
- an updated Appendix A, References Section.
The regular two-year update to Special Publication 800-53 will occur, as previously scheduled, in December 2008.
Draft SP 800-115, Technical Guide to Information Security Testing, is available for public comment. It seeks to assist organizations in planning and conducting technical information security testing, analyzing findings, and developing mitigation strategies. The publication provides practical recommendations for designing, implementing, and maintaining technical information security testing processes and procedures. SP 800-115 provides an overview of key elements of security testing, with an emphasis on technical testing techniques, the benefits and limitations of each technique, and recommendations for their use. Draft SP 800-115 is intended to replace SP 800-42, Guideline on Network Security Testing, which was released in 2003. Please visit the drafts page to learn how to submit comments to this draft document.
Adobe PDF (762 KB)
NIST's Computer Security Division has completed the initial public draft of Special Publication 800-80, Guide for Developing Performance Metrics for Information Security.
This guide is intended to assist organizations in developing metrics for an information security program. The methodology links information security program performance to agency performance. It leverages agency-level strategic planning processes and uses security controls from NIST SP 800-53, Recommended Security Controls for Federal Information Systems, to characterize security performance. To facilitate the development and implementation of information security performance metrics, the guide provides templates, including at least one candidate metric for each of the security control families described in NIST SP 800-53.
Adobe pdf (1,153 KB)
The NIST Computer Security Division is pleased to announce for your review and comment draft NIST Special Publication 800-26 Revision 1, Guide for Information Security Program Assessments and System Reporting Form. This draft document brings the assessment process up to date with key standards and guidelines developed by NIST.
Please provide comments by October 17, 2005 to sec-report@nist.gov. Comment period has been closed.
Computer Security: Art and Science. Matt Bishop, University of California - Davis ISBN: 0-201-44099-7 Addison Wesley: 2003 Cloth; 1136 pp. Published: 12/02/2002 US: $74.99
Expensive and dull book that can be used for torturing CS students :-). Attempt of broad coverage that definitely might help to killing any interest to computer security for most students...
Description Table of Contents Appropriate Courses Preface Sample Chapter About the Author(s)
... Updated Open Source Security Testing Manual Available By Paul Desmond. Version 2
of the Open Source Security Testing Methodology Manual (OSSTMM) was posted on ...
Recently, notifications started going out regarding a number of critical vulnerabilities in BIND, the software that powers the majority of the name servers on the Internet. In an attempt to convey the importance of these holes, many computer security experts were referring to this as the next major Internet bug -- drawing near-panicked comparisons to the massive, widespread BIND attacks of 1998. Many even went to the point of proclaiming that this incident will be the next great Internet-crippling bug.
To an extent, the concern over the announcement of the BIND vulnerabilities is valid. The Internet works as we know it because when we type a site into our browsers or email clients, name servers translate that site's name into numbers that can be routed. Without functioning name servers, the Internet becomes a much different world. Imagine having to identify friends by their telephone numbers rather than by their names. The vulnerabilities that were released at the end of January could allow attackers to take down or take control of the majority of name servers on the Internet. It was imperative that server administrators be notified as soon as possible and alerted as to the crucial nature of this problem. They were notified promptly.
However, by the time the advisories reached many security experts and members of the press, the discussions had taken on a tone of hysteria. Before the advisory was made public, the root name servers -- those that disseminate name information to the rest of the Internet's name servers -- had already been patched. It remains for system administrators on the rest of the Internet to upgrade their servers ... and many large providers and corporations reacted quickly and appropriately. At this point, the majority of Internet backbone providers have upgraded their servers.
The possibility that these vulnerabilities will take down the entire Internet is an unlikely one at best. To prove how drastic a bug this is, many experts pointed to the 1998 BIND hole, which was indeed one of the most persistently exploited vulnerabilities on the Net for a long, long time. What the experts fail to mention, however, is that at the time, the Red Hat distribution of Linux set up BIND without prompting at installation. Many Linux users didn't know they were running BIND, so they didn't think they needed to apply the patch when it became available. It's no longer the case that Red Hat installs BIND automatically; there will be fewer servers running BIND unnecessarily or unknowingly, so this vulnerability will be less prevalent. Despite their widespread effect, the great BIND attacks of 1998 didn't cause the Internet to shut down. The Internet continued along just fine, except for a few hundred compromised servers and defaced Web pages, which hardly affect the functionality of the Internet as a whole.
Another incident that experts and journalists have used to display how overwhelming this set of vulnerabilities could be occurred in late January when Microsoft's Web pages were unavailable for several hours due to a DNS problem (http://abcnews.go.com/sections/scitech/DailyNews/microsoft010125.html). While it's true that this is an example of a Website being inaccessible due to a problem with name servers, the instance is otherwise unrelated to the BIND problem. Microsoft's name servers don't run BIND, and by all indications the troubles they suffered two weeks ago were in no way similar to those caused by the holes in BIND. The constant comparison, clearly intended to heighten concern about the destruction of the entire Internet if name servers go down, smacks of sensationalism.
IBM DeveloperWorks/Linux Security: Improving the security of open UNIX platforms -- simple MD5 checking shell script(bash) by Igor Maximov (uniug@cris.net). Nothing special.
[Dec 28, 2000] NSA Security-Enhanced Linux
The 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.
SecurityPortal - Ask Buffy Apache Security
I am trying to implement security on the Apache Server 1.3.12 running on a Linux Red Hat 6.2. Are there any good docs or how-tos on this subject?
Aejaz Sheriff
Very few security problems exist with the Apache server itself. Having said that, however, I suggest that you upgrade to Apache 1.3.14, which solves some security issues. For online documentation of the Apache server the following URLs are excellent:
http://httpd.apache.org/docs/misc/security_tips.html
http://httpd.apache.org/docs/The majority of Web-based security problems come from poorly written CGI programs, online databases, and the like. Razvan Peteanu has written the following article:
http://securityportal.com/cover/coverstory20001030.html - Best Practices for Secure Web Development
And I highly recommend reading it.
Buffy (buffy@securityportal.com)
Who should own Apache? I have nobody as the owner and the group, but I'm not sure if this is safe or not.
Brad
The usual default for "owning" Apache is user and group root:
-rwxr-xr-x 1 root root 301820 Aug 23 13:45 /usr/sbin/httpdAs for who Apache runs as, this is usually the user and group "nobody" or "apache." In both cases, these groups are heavily restricted from accessing anything important, from the httpd.conf file:
#
# If you wish httpd to run as a different user or group, you must run
# httpd as root initially and it will switch.
#
# User/Group: The name (or #number) of the user/group to run httpd as.
# . On SCO (ODT 3) use "User nouser" and "Group nogroup".
# . On HPUX you may not be able to use shared memory as nobody, and the
# suggested workaround is to create a user www and use that user.
# NOTE that some kernels refuse to setgid(Group) or semctl(IPC_SET)
# when the value of (unsigned)Group is above 60000;
# don't use Group nobody on these systems!
#
User apache
Group apacheMost Linux distributions now have a special user and group called "apache" for running the Apache Web server. This user is locked out (no password), the home directory is usually the www root, and no command shell is available. This is slightly safer than using nobody because the "nobody" account may be used by other services. If an attacker manages to get privileges of "nobody" on the system, she may be able to elevate privileges using some other software. Segmenting "apache" with different users is a better strategy.
Buffy (buffy@securityportal.com)
Slashdot Theo de Raadt Respond
Q: Would you and/or other members of the OpenBSD coders consider writing a book on secure, bug-free coding and auditing? Most programming books feature sample code that is written for pedagogical purposes. Quite often this runs contrary to how secure code should be written, leaving a gap in many a programmers knowledge. A book on audinting and how to avoid security pitfalls when coding would also make your life easier - less code to audit for OpenBSD, and more time top concentrate on nifty new features!!!
Theo:
There is perhaps a split between the two issues you bring up. On the one side is secure coding, as in code written to be secure by the original author(s). On the other side, auditing, which is where an outsider (or an insider) later on goes and tries to clean up the mess which remains. And there is always a mess. Perhaps part of the problem is that a huge gap lies between these two. In the end though, I think that a book on such a topic would probably have to repeat the same thing every second paragraph, throughout the book: Understand the interfaces which you are coding to! Understand the interfaces which you are coding to! Most of the security (or simply bug) issues we audited out of our source tree are just that. The programmer in question was a careless slob, not paying attention to the interface he was using. The repeated nature of the same classes of bugs throughout the source tree, also showed us that most programmers learn to code by (bad) examples. A solid systems's approach should not be based on "but it works". Yet, time and time again, we see that for most people this is the case. They don't care about good software, only about "good enough" software. So the programmers can continue to make such mistakes. Thus, I do not feel all that excited about writing a book which would simply teach people that the devil is in the details. If they haven't figured it out by now, perhaps they should consider another occupation (one where they will cause less damage).
OpenBSD has a well deserved reputation for security "out of the box" and for the fact the inbuilt tools are as secure as they're ever likely to be. However, the Ports system is, perhaps, an example of where the secure approach currently has limitations - an installation of OpenBSD running popular third-party systems like INN can only be so secure because the auditing of INN, and other such software, is outside the scope of the BSD audit.
My question is, has the OpenBSD team ever proposed looking into how to create a 'secured ports' tree, or some other similar system, that would ensure that many of the applications people specifically want secure platforms like OpenBSD to run could be as trusted as the platforms themselves?
Theo:
We have our hands already pretty full, just researching new ideas in our main source tree, which is roughly 300MB in size. We also lightly involved ourselves in working with the XFree86 people a while back for some components there. Auditing the components outside of this becomes rather unwieldy. The difficulty lies not only in the volume of such code, but also in other issues. Sometimes communication with the maintainers of these other packages is difficult, for various reasons. Sometimes they are immediately turned off because we don't use the word Linux. Some of these portable software packages are by their nature never really going to approach the quality of regular system software, because they are so bulky.
But most importantly, please remember that we are also human beings, trying to live our lives in a pleasant way, and don't usually get all that excited about suddenly burning 800 hours in some disgusting piece of badly programmer trash which we can just avoid running. I suppose that quite often some of our auditors look at a piece of code and go "oh, wow, this is really bad", and then just avoid using it. I know that doesn't make you guys feel better, but what can we say...
With the release of SGI's B1 code, and the attempts by many U*ixen to secure their contents via capabilities, ACL's, etc, ad nausium, how is OpenBSD approaching the issue of resource control?
... ...
Theo:
On the first question, I think there is great confusion in
the land of Orange Book. Many people think that is about security. It is not.
Largely, those standards are about accountability in the face of threat. Which
really isn't about making systems secure. It's about knowing when your system's
security breaks down. Not quite the same thing. Please count the commercially
deployed C, B, or even A systems which are actually being used by real people
for real work, before foaming at the mouth about it all being "so great". On
the other hand, I think we wil see if some parts of that picture actually start
to show up in real systems, over time. By the way, I am surprised to see you
list ACLs, which don't really have anything to do with B1 systems.
Did the drive to audit code come from the need or
the design of BSD? Or was it initially a whim? More imporantly, where did you
learn it from? Is their some "mentor" you looked too for ridge design? I have
to admire your team's daunting code reviewing...I wonder if I'll ever have that
kind of meticulous coding nature.
Theo:
The auditing process developed out of a desire to improve the quality of our operating system. Once we started on it, it becomes fascinating, fun, and very nearly fanatical. About ten people worked together on it, basically teaching ourselves as things went along. We searched for basic source-code programmer mistakes and sloppiness, rather than "holes" or "bugs". We just kept recursing through the source tree everytime we found a sloppiness. Everytime we found a mistake a programmer made (such as using mktemp(3) in such a way that a filesystem race occurred), we would go throughout the source tree and fix ALL of them. Then when we fix that one, we would find some other basic mistake, and then fix ALL of them. Yes, it's a lot of work. But it has a serious payback. Can you imagine if a Boeing engineer didn't fix ALL of the occurrences of a wiring flaw? Why not at least try to engineer software in the same way?
Older news were moved to a separate file due to volume -- see OSS Security Chronicle
Top dozen
Non-government
SANS,
SecurityFocus (hosts BugTrack list),
Vendors:
Government:
***** CERT
***** NSA
**** CIAC United States Department of Energy's Computer Incident Advisory Capability.
*** NIH Unix Security -- NIH Security Resources -- links from National Institutes of Health. One of the best collection of security-related links. A vast collection of computer security resources, including documents, links to other web pages, and tools. Outdated...
Information about major open source security tools can be found at Softpanorama University Classic Open Source Unix Security Tools. Here are some archives that one might find useful:
**** BugTraq -- full-disclosure UNIX security mailing list.
www.eds.org -- The Security-Audit Mailing list FAQ
Improving the Security of Your UNIX System by David A. Curry.The "SRI Paper" that has been widely distributed around the Internet. It was written in 1990 and was a predecessor to the UNIX System Security book. David A. Curry is the author of UNIX Systems Programming for SVR4 and is also active tool developer (see his home page for the complete list). Among them are (description are borrowed from the author's page):
How to improve security on SunOS.4.1.3 -- outdated, but some information can be useful
Improving the Security of Your Site by Breaking Into it -- famous (now outdated) SATAN-related paper. Not that SATAN was better than other, but the name provoke a media craziness that gave the authors a lot of exposure...
1993: An Architectural Overview of UNIX Network Security February 18, 1993 Robert B. Reinhardt breinhar@access.digex.com
See also CIAC advisories below. Shorter tutorials are listed in Articles. There is also a useful list at http://secinf.net/unix_security/
King & Spalding Law -- discussion of the standard of "reasonable care".
Open Source Code And Information Security: A Legal Perspective
Reprinted from E-Commerce Law Journal, Volume 1, Number 7, pp. 20-21 (July, 2001) and Volume 1, Number 8, pp. 17-19 (August, 2001).
By: Brad Slutsky
There are many reasons why companies need to protect their information assets. These reasons include maintaining competitive advantages, ensuring the integrity, authenticity, and availability of information, adhering to confidentiality commitments or other legal requirements, complying with duties to shareholders, and complying with duties to third parties. Typically, companies' obligations to secure their information assets are measured against a standard of "reasonable care". This article addresses the question of whether companies exercise "reasonable care" when they use open source code software to implement business functions
This version and its subsequent outputs whether be it HTML, PDF or any other derivatives can be distributed under the same licensing terms and conditions as the orginal Securing and Optimizing Linux i.e. as set forth in the Open Publication License; V1.0 or later, the latest version is presently available at www.opencontent.org/openpub/.
Please note even if i madhusudan (Madhu "Maddy"),<needaguru@yahoo.com> hold the copyright for the XML source(Markup), you still need to get permission from Gerhard Mourani<gmourani@openna.com> the orginal author of Securing and Optmising Linux, to make any changes to the content of this book. Please do read the licensing terms and conditions detailed below for additional information
This material may be distributed only subject to the terms and conditions set forth in the Open Publication License; V1.0 or later, the latest version is presently available at www.opencontent.org/openpub/.
Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder.
Distribution of the work or derivative of the work in any standard (paper) book form for commercial purposes is prohibited unless prior permission is obtained from the copyright holder.
Please note even if I, Gerhard Mourani have the copyright, I don't control commercial printing of the book. Please contact OpenDocs @www.opendocspublishing.com/ if you have questions concerning such matters.
The logos, trademarks, symbols used in this book are properties of their respective compan(y)ies.
NIST
CERT:
See also: SecurityPortal -- recent security news. Good...
Red Hat
Caldera's security page.
See also metalinks:
Security FAQs - the list of security-related FAQs maintained by Internet Security Systems, Inc.
Shadow Password HOWTO Note. caldera 1.3 and later install shadow password file by default. RedHat 6.0 and later also instell shadow password file.
[Nov.7,1998] www.eds.org -- The Security-Audit Mailing list FAQ
Frequently Asked Questions (FAQ)
Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: August 18, 2008