=================================================================== RCS file: /cvsrepo/anoncvs/cvs/www/security.html,v retrieving revision 1.105 retrieving revision 1.106 diff -u -r1.105 -r1.106 --- www/security.html 1999/09/14 05:44:59 1.105 +++ www/security.html 1999/09/22 05:54:08 1.106 @@ -13,18 +13,34 @@ [OpenBSD] -
-For 2.1 security advisories, please refer here.
-For 2.2 security advisories, please refer here.
-For 2.3 security advisories, please refer here.
-For 2.4 security advisories, please refer here.
-For 2.5 security advisories, please refer here.
-

-

OpenBSD Security Views

+

Security

+Index
+Security goals of the Project.
+Full Disclosure policy.
+Source code auditing process.
+"Secure by Default".
+Use of Cryptography.
+

+For 2.5 security advisories.
+For 2.4 security advisories.
+For 2.3 security advisories.
+For 2.2 security advisories.
+For 2.1 security advisories.
+For 2.0 security advisories.
+

+Watching changes.
+Reporting security issues.
+

+


+ +
+ +
  • Goal

    + OpenBSD believes in strong security. Our aspiration is to be NUMBER ONE in the industry for security (if we are not already there). Our open software development model permits us to take a more @@ -34,34 +50,47 @@ cryptography, we are able to take cryptographic approaches towards fixing security problems.

    + +

  • Full Disclosure

    + Like many readers of the BUGTRAQ mailing list, -we believe in full disclosure of security problems. Security -information moves very fast in cracker circles. On the other hand, -our experience is that coding and releasing of proper security fixes -typically requires about an hour of work -- very fast fix turnaround -is possible. Thus we think that full disclosure helps the people who -really care about security.

    +we believe in full disclosure of security problems. In the +operating system arena, we were probably the first to embrace +the concept. Many vendors, even of free software, still try +to hide issues from their users.

    +Security information moves very fast in cracker circles. On the other +hand, our experience is that coding and releasing of proper security +fixes typically requires about an hour of work -- very fast fix +turnaround is possible. Thus we think that full disclosure helps the +people who really care about security.

    + +

  • Audit Process

    + Our security auditing team typically has between six and twelve members who continue to search for and fix new security holes. We have been auditing since the summer of 1996. The process we follow to increase security is simply a comprehensive file-by-file analysis of -every critical software component. Flaws have been found in just -about every area of the system. Entire new classes of security -problems have been found during our audit, and often source code -which had been audited earlier needs re-auditing with these new flaws -in mind. Code often gets audited multiple times, and by multiple -people with different auditing skills.

    +every critical software component. We are not so much looking for +security holes, as we are looking for basic software bugs, and if +years later someone discovers a the problem used to be a security +issue, and we fixed it because it was just a bug, well, all the +better. Flaws have been found in just about every area of the system. +Entire new classes of security problems have been found during our +audit, and often source code which had been audited earlier needs +re-auditing with these new flaws in mind. Code often gets audited +multiple times, and by multiple people with different auditing +skills.

    Some members of our security auditing team worked for Secure Networks, the company that made the industry's premier network security scanning software package Ballista (Secure Networks got purchased by Network Associates, Ballista got renamed to Cybercop Scanner, and well...) That company did a lot of security research, and thus fit in well -with the OpenBSD stance. OpenBSD passes Ballista's tests with flying -colours.

    +with the OpenBSD stance. OpenBSD passed Ballista's tests with flying +colours since day 1.

    Another facet of our security auditing process is its proactiveness. In most cases we have found that the determination of exploitability @@ -80,6 +109,8 @@ managed such a success is the lpd advisory that Secure Networks put out.

    +

  • The Reward

    + Our proactive auditing process has really paid off. Statements like ``This problem was fixed in OpenBSD about 6 months ago'' have become commonplace in security forums like @@ -105,12 +136,40 @@

  • Finding and fixing subtle flaws in complicated software is a lot of fun. +

    The auditing process is not over yet, and as you can see we continue to find and fix new security flaws.

    + +

  • "Secure by Default"

    + +To ensure that novice users of OpenBSD do not need to become security +experts overnight (a viewpoint which other vendors seem to have), we +ship the operating system in a Secure by Default mode. All non-essential +services are disabled. As the user/administrator becomes more familiar +with the system, he will discover that he has to enable daemons and other +parts of the system. During the process of learning how to enable a new +service, the novice is more likely to learn of security considerations.

    + +This is in stark contrast to the increasing number of systems that +ship with NFS, mountd, web servers, and various other services enabled +by default, creating instantaneous security problems for their users +within minutes after their first install.

    + +

  • Cryptography

    + +And of course, since the OpenBSD project is based in Canada, it is possible +for us to integrate cryptography. For more information, read the page +outlying what we have done with cryptography.

    + +
  • Advisories

    + +

    + +
  • -

    +

    OpenBSD 2.5 Security Advisories

    These are the OpenBSD 2.5 advisories -- all these problems are solved in OpenBSD current. Obviously, all the @@ -142,8 +201,9 @@ with the -S flag, when called by nroff(1) (patch included). -

    +

  • +

    OpenBSD 2.4 Security Advisories

    These are the OpenBSD 2.4 advisories -- all these problems are solved in OpenBSD current. Obviously, all the @@ -185,8 +245,9 @@ bug in the TCP decoding kernel. (patch included). -

    +

  • +

    OpenBSD 2.3 Security Advisories

    These are the OpenBSD 2.3 advisories -- all these problems are solved in OpenBSD current. Obviously, all the @@ -216,8 +277,9 @@ if IPSEC is enabled (patch included). -

    +

  • +

    OpenBSD 2.2 Security Advisories

    These are the OpenBSD 2.2 advisories. All these problems are solved in OpenBSD 2.3. Some of these problems @@ -251,8 +313,9 @@ (patch included). -

    +

  • +

    OpenBSD 2.1 Security Advisories

    These are the OpenBSD 2.1 advisories. All these problems are solved in OpenBSD 2.2. Some of these problems still @@ -271,6 +334,9 @@
  • Jun 24, 1997: Procfs flaws (patch included) +

    +

  • +

    OpenBSD 2.0 Security Advisories

    These are the OpenBSD 2.0 advisories. All these problems are solved in OpenBSD 2.1. Some of these problems still @@ -286,8 +352,12 @@ and we'll put them up here. +
  • -

    Watching our Security Changes

    + + +
  • Watching our Changes

    + Since we take a proactive stance with security, we are continually finding and fixing new security problems. Not all of these problems get widely reported because (as stated earlier) many of them are not @@ -325,7 +395,7 @@

    -

    Other Resources

    +
  • Reporting problems

    If you find a new security problem, you can mail it to deraadt@openbsd.org. @@ -333,11 +403,13 @@ If you wish to PGP encode it (but please only do so if privacy is very urgent, since it is inconvenient) use this pgp key. +

  • +
    OpenBSD www@openbsd.org
    -$OpenBSD: security.html,v 1.105 1999/09/14 05:44:59 deraadt Exp $ +$OpenBSD: security.html,v 1.106 1999/09/22 05:54:08 deraadt Exp $