A Continuing Look at Windows v. Linux Security

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.