Sr. Developer, Backend Professional Technical Resources US-OR-Portland Post A Job | Post A Resume

By Brandoch Conner

First--here's my current working definition of "security": it's the process of evaluating threats and reducing their effectiveness.

You will never be 100% "secure" because the upper limit is bound by human stupidity. The best you can do is to reduce the threats to just below that level. Sure, you can protect your system against viruses/worms/trojans and so forth, but you will still lose files/data/time/money because people will accidentally delete them. If the amount of data/time/money/etc lost as a result of viruses/worms/trojans is LESS than the amount of data/time/money/etc lost due to human error, then you're doing a good job.

Ideally, you'll lose no data and spend no time/money in recovery, but you will spend time/money on the security process for those systems. The better designed the base system is, the less of the second part you'll be spending.

My last column covered basic operating system security (viruses/worms) so this one will be a lot shorter. This time it's about trojans.

Most of the "email viruses" you hear about for Windows are really trojans. They don't "infect" other files (except to completely over write the file with their own code) and they require a person to launch them and they run with the permissions of that person.

The reason you see so many of them right now is because of three main reasons:

1. In the past, Microsoft has shipped versions of Outlook that allowed the user to launch executable files from within Outlook.
2. Microsoft has the default settings set to hide the extension of a file (evil.txt.exe appears to be evil.txt) so the uneducated users cannot tell what a file really is.
3. Microsoft has many files that are executable. (exe, bat, chm, mdb, reg, scr, pif, com, vbs, wsf, sct, wsc, jse, vbe, cmd, vb and so forth)

So, the simple way for Linux to remain as free of trojans as it currently is would be to... not build an email app that allows users to launch apps from within it. This should not be too terribly difficult to accomplish as apps under Linux need the "execute bit" set to be able to run. Remember, not doing something because it is a dumb idea and easily exploited is good security practice.

In fact, why not set the home directories to be non-executable? That way you would have to accidentally ...

1. receive a trojan via email
2. save that trojan to a system directory
3. set the execute bit on that trojan
4. run the trojan.

If you're saving unknown code to a system directory and then running it, you've hit the limits of "security" and you're into the realm of "human stupidity."

And finally, here's my ranking of "vulnerabilities" because lately I've been seeing too much crap about "critical" or "severe" vulnerabilities in various systems/apps.

1. Remote--root access that does NOT require human intervention or other app running.
2. Remote non-root access that does NOT require human intervention or other app running.
3. Local root access that does NOT require human intervention or other app running.
4. Local non-root access that does NOT require human intervention or other app running.
5. Remote root access that requires some human interaction or some combination of apps.
6. Remote non-root access that requires some human interaction or some combination of apps.
7. Local root access that requires some human interaction or some combination of apps.
8. Local non-root access that requires some human interaction or some combination of apps.
9. Remote OS crash.
10. Remote app crash.
11. Local OS crash.
12. Local app crash.

Now, look at the number of services listening on open ports in a default Windows installation. Those are the ones at risk at levels 1 and 2. Some Linux distributions have default configurations with apps running and listening on open ports, so this isn't just Microsoft. That is one of the reasons I like Debian and Ubuntu. Ubuntu has nothing open and I can build Debian servers from a minimal installation without any additional services running.

Related Stories:
Where Security "Studies" Go Wrong(Sep 13, 2005)
TCO Studies Miss Basic Incompatiblities(Aug 29, 2005)
Linux on a Fast-Food Diet(Aug 23, 2005)
Breaking Down the Linux Markets(Aug 15, 2005)

Index Mode   |   Flat Mode   |   Thread Mode   |   Thread Flat     Talkback(s) Name  and Date   Security == Risk Analysis    steve Sep 27, 2005, 02:25:01     Re: Security == Risk Analysis    Richard Sep 27, 2005, 07:54:56     re: Security == Risk Analysis    Brandioch Conner Sep 27, 2005, 12:19:41     Some mistakes    phil Sep 27, 2005, 13:28:22     Re: Some mistakes    Toby Haynes Sep 27, 2005, 14:58:43     Re: Re: Security == Risk Analysis    Bob Robertson Sep 27, 2005, 19:45:53     re: Security == Risk Analysis    s Sep 27, 2005, 21:29:12     Re: Some mistakes    SM Sep 27, 2005, 22:12:25     re: re: Security == Risk Analysis    Brandioch Conner Sep 27, 2005, 23:22:22     Re: Some mistakes    Chris Sep 28, 2005, 01:35:05     re: Security == Risk Analysis    s Sep 28, 2005, 05:02:50     email attachments    blackhole Sep 28, 2005, 10:18:26     re: re: Security == Risk Analysis    Brandioch Conner Sep 28, 2005, 13:35:34     re: email attachments    Brandioch Conner Sep 28, 2005, 13:54:19     Home | Search Talkbacks | Customize View    Top of Page   Enter your comments below: * Your Name: * Your Email Address: * Subject: CC: [will also send this talkback to an E-Mail address] * Comments: Tags allowed:<I>,<B> and <U>. See our talkback-policy for more about talkback content. Fields marked with * are required!