Paranoid Penguin - Linux Filesystem Security, Part I
For most of the Paranoid Penguin's illustrious four years with Linux Journal, I've tended to write tools-focused columns. I've described how to secure Sendmail, how to add SSL encryption to things by using Stunnel and how to get any number of other powerful security software tools configured and running.
Over the next couple of columns, however, I am going to address one of the most basic and important, yet often-overlooked aspects of Linux security; filesystem permissions. If used wisely, it will be harder for users and intruders to abuse their system privileges. If you set them carelessly, however, minor vulnerabilities can lead to major system compromises.
These articles should be especially useful to Linux newcomers who wonder what all the drwxr-xr-x gobbledygook in file listings means. But, even if you're an intermediate user—perhaps the kind who doesn't yet understand the precise ramifications of setuid and setgid—these articles, especially Part II, may have something for you too.
Did you know that in UNIX and UNIX-like systems, basically everything is represented by files? Documents, pictures and even executable programs are easy to conceptualize as files on your hard disk. Although we think of a directory as a container of files, a directory actually is a file containing, you guessed it, a list of other files.
Similarly, the CD-ROM drive attached to your system seems tangible enough, but to your Linux kernel, it too is a file—the special device file /dev/cdrom. To send data from it or to write it to the CD-ROM drive, the kernel actually reads to and writes from this special file. Actually, on most systems, /dev/cdrom is a symbolic link to /dev/hdb or some other special file. And wouldn't you know it, a symbolic link is in turn nothing more than a file containing the location of another file.
Other special files, such as named pipes, act as input/output (I/O) conduits, allowing one process or program to pass data to another.
My point here is not to describe each and every type of file that exists in Linux or UNIX. It's to illustrate how nearly everything is represented by a file. Once you understand this, it's much easier to understand why filesystem security is such a big deal and how it works.
Commands and Man Pages
In this article, I focus on filesystem concepts rather than the precise syntax and usage of actual commands. But if you're a beginner, you may be wondering how to execute commands at all and where can you find syntax/usage help.
First, in all of my examples and example scenarios, I'm working in a terminal window. Microsoft Windows users can think of a terminal as like a DOS prompt or command window. A terminal window provides the most direct means of interacting with Linux, that is, by letting you enter all your commands manually rather than by triggering them with mouse clicks.
To start your own shell session from GNOME, click the Main Menu button and select System Tools→Terminal. In KDE, the terminal command is called konsole, and it has its own icon on the taskbar, a clamshell in front of a computer screen. Alternatively, you can start the Run Program dialog and type konsole at the prompt.
For fast help with practically any Linux command from within a terminal/shell session, you can type that command followed by the --help option. For example, if I can't remember all the command-line options for the ls command, which lists files and directories, I enter the command ls --help.
The --help option is quick, but it doesn't work for all commands. Even when it does work, its output can be quite terse. The best way to get command help is by using the man command. Man pages provide complete instructions on how to use most Linux commands and are present on practically all UNIX-like systems. To see the man page for the ls command, for example, type the command man ls. Within the man page listing, press the spacebar to advance forward one page, the B key to go back one page and type /somestring to search the man page for somestring.
But, what if you don't know the name of the command you need? That's what apropos is for. For example, type apropos list to see a variety of commands that list things, and then pull up a man page for whichever of those commands seem to be what you need.
Actually, two things on a Linux system aren't represented by files, user accounts and group accounts, which we call users and groups for short. Various files contain information about a system's users and groups, but none of those files actually represents them. A user account represents someone or something capable of using files. This is to say, both human beings and system processes can use user accounts. For example, a user account named webmaster typically represents a human being who maintains Web sites. But the standard Linux user account lp is used by the line printer dæmon (lpd); the lpd program runs as the user lp. I explain later what it means for a program to run as one user vs. another.
A group account simply is a list of user accounts. Each user account is defined with a main group membership but may in fact belong to as many groups as needed. For example, the user maestro may have a main group membership in conductors and also belong to pianists.
A user's main group membership is specified in the user account's entry in /etc/password. You can add that user to additional groups by editing /etc/group and adding the user name to the end of the entry for each group to which the user should belong. Alternatively, you could use the usermod command; see the usermod(8) man page for more information.
Listing 1 shows maestro's entry in the file /etc/password, and Listing 2 shows part of the corresponding /etc/group file.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!