You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

Hi. I'm a Unix Administrator, mathematics enthusiast, and amateur philosopher. This is where I rant about that which upsets me, laugh about that which amuses me, and jabber about that which holds my interest most: Unix.

Rate this Entry

It's all about the *right* eyeballs...

If you don't test something yourself, can you trust the information you find about the topic? The biggest difference between blindly trusting something and knowing the answer is having the right eyeballs. In other words, if you setup a test case to cast the data in the right light, you can see the answer plainly. You need the right eyeballs.

The reason ESR's statement "with enough eyeballs, all bugs are shallow" is (somewhat) correct is that no two people look at a problem the same. Each has a slightly different approach, and with enough eyeballs in the pool odds are good that one is going to look at the data in just the right manner to make the bug obvious. Grats to ESR for pointing this out, right? We can all go home and trust our FOSS software vendors now, right?

Not exactly. The statement has one critical flaw.

"with enough ***QUALIFIED*** eyeballs, all bugs are shallow" is a bit more correct. If I take microscope pictures of a cell scrape and show them to millions of people, none of whom are doctors, nurses, or such, odds are pretty low that any one individual would be able to tell me anything significant about the pictures.

Does this image indicate genetic disease?

Who knows? I'm still trying to figure out WTF I'm looking at!

Theo Deraadt made a similar comment during the FBI/OpenBSD controversy a while back...a claim was made that the FBI paid former OpenBSD developers to plant a backdoor in the OpenBSD IPSEC stack, and accordingly a massive code-audit was started and many trivial bugs were fixed, even though no backdoor was found. Who were the code-auditors? General population? OpenBSD users? OpenBSD devs?

The VAST majority of the public auditors were OpenBSD devs. I think there may have been one individual who publicly audited the code who was not a member of the OpenBSD team. The entire world was given an opportunity to find a flaw in OpenBSD and claim fame in security circles worldwide as the individual who found a backdoor placed in the most secure general-purpose operating system in the world...a backdoor that had survived TEN YEARS in an open source project without being discovered...a backdoor that was engineered by a government agency (or, more accurately, operatives of a government agency) that might have the resources to actually pull it off...and yet, only ONE person stepped up publicly? Sure, there were probably quite a few who "stepped up" quietly and reviewed the code (I took a look myself, to be honest), but of all the bugs fixed, how many were from non-OpenBSD devs?

When the topic at hand is highly specialized, as code auditing for security problems is, there tend to be very few qualified "eyeballs" available...tossing ESR's hypothesis out the window.

So how do you go about getting "qualified" eyeballs on a subject when you have a question? Should you ask someone else? Sure, you might find a qualified individual if you are asking simple enough questions (sites like linuxquestions.org thrive because of this)...but then you have to trust that individual's answer.

Nah, it's better to dig in and test. How can I verify that I'm transmitting data in an encrypted fashion to a friend? Wikipedia for the protocol you're using? tcpdump? How about testing if a file is readable by unauthorized users? ls -lh? Login as someone that's not supposed to have access and try to read it?

When I was in college I wrote a rootkit for Windows Server 2003 (for a security course I was taking). I then used that rootkit to demonstrate that the "netstat" command on Windows Server 2003 was untrustworthy (TCPView from sysinternals did see the connection I was hiding =).

Think about who you're trusting when you take information in. Who generated the information? Are they trustworthy?

And then ask yourself the most important questions: How much did I learn by testing it myself? How many times did I have to stop and ask someone for an answer when I was testing it myself?