-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 15 Aug 2003, Peter Busser wrote: > > The only way to sleep quietly is still to audit the code at the first place. > > The only way to sleep quietly in fact is to feed your computer to a shredder. > > Auditing code alone will not provide much security. In fact, it will lead to a > false sense of security. The problem is that a modern UNIX system is that it > contains millions of lines of code. Auditing this amount of code is simply > impossible. Furthermore, auditors are humans. Humans make mistakes, not only > when they are programmers, but also when they are auditors. So audited code > will still contain security bugs. > > In fact, the amount of security in OpenBSD is only slightly less horrible than > that of most *NIX operating systems (which includes Adamantix for that matter). Thank you for bringing up this point. ISTM that expecting all security-critical userspace code to be audited to perfection as a prerequisite to system security is foolish. No one, not even the most intelligent and knowledgeable security guru can write every program to be perfectly secure all the time without fail. I don't know how many times I've heard "You should write secure programs, the only solution for system security is to write programs that are not susceptible to (buffer overflows, heap overflows, format string, etc) attacks." This is an impossibility and a bit of self-abuse to keep repeating this mantra. Repetition won't make it true. Again, ISTM that the only way to get close to a reasonably secure system is to only rely on the smallest, most audited codebase possible to enforce security policy. To me this means something enforced by the kernel itself, like standard POSIX permissions and capabilities, NSA Flask, Systrace, SubDomain, LIDS, GRSecurity, etc. (note that this is not a particularly accurate list). For example one thing that could be done is to automatically build bare-bones systrace profiles at compile time so that any attempt to use a syscall not specified in the source causes the program to immediately abort. Not a catch-all, but something that raises the bar. In any event, implementing the above is a far more complicated affair than can be accomplished by even an intelligent, knowledgeable and dedicated sysadmin. The only way that there will be significant uptake of more comprehensive access control/policy enforcement systems such as the above is if they are correctly configured and included by the OS manufacturer. OpenBSD seems to be taking the right approach here by developing systrace and including systrace profiles for the base system, which is much better than the previous approach of trying to perfect the crufty and inadequate UNIX "security" model. I'd like to see the other major OS distributors, Microsoft, RedHat, SuSE, Sun, IBM, Novell, etc. take an active part in this and not only provide systems with advanced security controls, but also ship them fully configured rather than relying on the system administrator who can't possibly understand the system well enough to fully configure them. - -- Mark Tinberg <MTinberg@securepipe.com> Network Security Engineer, SecurePipe Inc. New Key fingerprint = FAEF 15E4 FEB3 08E8 66D5 A1A1 16EE C5E4 E523 6C67 Your daily fortune . . . Watson's Law: The reliability of machinery is inversely proportional to the number and significance of any persons watching it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQE/PYqrFu7F5OUjbGcRArfFAJsEbws18Ngj78ZfPpwaT+c0PGSjVgCePcES agepSknw833x7altZ7VFLYc= =tjsu -----END PGP SIGNATURE-----
