Research Booth Logo ResearchBooth.com

Helping you make informed decisions on important topics.

Content Navigation

  • Home
  • Browse Articles
  • Search All Articles

Site Information

  • About Us
  • Links
  • Feedback
  • License Agreement
  • Privacy Policy

Submit an Article

We are always looking for original content.

If you are a high quality writer then we may have work for you.

Submission Guidelines

Understanding the Linux security model

You hear the smug cackling from the Linux users; they brag about their system security every chance they get. A virus or Internet worm is going around, hosing systems and causing damage, and in the middle of it all are a handful of yawning Linux geeks, going "Won't affect us! Heh heh heh!" If you use Windows, the hazing you're in for on security matters is almost silly. Expect Linux users to ask you how much you pay for anti-virus software, then roll their eyes and sigh contentedly and lay a loving pat on their Debian or Red Hat system.

What is it about Linux that makes it so secure, anyway? There is a frequent argument bandied about whose gist goes, "If Linux had the desktop share that Windows has, you'd see just as many security problems as Windows." But no, as it turns out, Linux, BSD, and other systems founded on the Unix model actually are built from the ground up to be less vulnerable to attack.

Most of the reason why is in the Linux file system model. Files are handled differently in a Linux system. One way is that each file on the system has the concept of permissions built in. These permissions separate who can use the file and how. They are designated "owner", "group", and "world" to answer the "who" question, and "read", "write", and "execute" answer the "what" question. So, you can set a file so that only the owner may write to it (that includes deleting it), members of the file owner's group can execute it and read it, but the general outside world cannot do anything but read it. Anybody who tries to break these rules gets a "permission denied" error, and only the owner can change these permissions.

Most of the files on a Linux system belong by default to "root", or the system administrator account. Within this category, no non-root user can write to system files, and some programs which are risky security-wise can additionally be restricted so that only root can run them. By default, normal users only have full access to their personal files within their home folder. The user access levels also applies to any program that the user runs! That is, even if a user downloads and runs a malicious program, that program inherits the user's permissions, and so cannot do anything that the user themselves could not do.

The Linux file system comes with even more information embedded in the file system; each file has the system's file type identifier embedded in the file itself instead of relying on an extension. Thus executables do not necessarily have ".exe" at the end, and plain text files do not need ".txt" at the end. File extensions are kept solely for the user's convenience. Thus, one cannot fool the system by making an executable file with a ".pdf" extension, since even if the user naively double-clicks on the PDF file to open it for reading, the system will know that it's really an executable program and refuse to run it.

Processes running from "outside" the system are handled as "public" processes, with similar restrictions placed on them. A web page with a malicious executable program embedded in it cannot affect the user's files, without explicit permission to do so issued by the user.

There are many more security checkpoints inherent in the Linux system; for one thing, the open-source development model ensures that should a vulnerability be found, the problem can be handled immediately by fixing the open code and submitting their fix to the project's developers. Thus, even "0-day" exploits, when they are found, can be handled "0-day" as well, without waiting on a commercial company to get around to releasing the patch.

Linking to this page is permitted. Copying the content is not.

Home | Feedback | License Agreement | Privacy Policy

Copyright © 2006, ResearchBooth.com | Part of the BlueSparks Network