Paranoid Penguin - Linux Filesystem Security, Part II

 in
We covered the fundamentals of permissions last month. Now it's time to learn some useful bits to make cooperation among users convenient and secure.
umask

I want to cover one last command specific to permissions before closing with a couple of other topics. umask is a command built into the bash shell that prints or sets your default permissions mask. To see yours, simply enter the umask command without any arguments; it returns a four-digit number. On my system, it looks like Listing 3.

Mode 0022 means no special permissions, no user-owner permissions, group and other permissions set to write, right? How can that be?

Actually, umask deals in masks, not in modes per se. 0022 is what is subtracted from the number 0777 to determine the numeric mode of files you create: 0777 – 0022 = 0755.

Aha! So, files I create have user-owner permissions set to read-write-execute (7 = 4 + 2 + 1) and group and other permissions set to read-execute (5 = 4 + 1)? Right? Almost. It also happens that umask sets the execute bit automatically only on directories. Even if your permissions mask includes execute permissions, the execute bit does not set automatically on regular files you create. So, if my permissions mask is 0022, resulting in default permissions of 0755, and I create a file named default_file and a directory named default_dir, long listing output for those two items look like Listing 4.

To change your default permissions mask, simply issue the command umask with the new mask as its argument. For example, if I want all my files to have group-read permissions but no other permissions, this translates to a numeric mode of 0740. If I subtract that from 0777 I get a mask of 0037. Therefore, the umask command I enter is umask 0037. This new mask, however, applies only to my current session and any new shells I start from it. To make it persistent, I can add the line umask 0037 to my .bashrc file.

su and sudo

I should say a few words about the reality of users, groups and permissions. The whole problem with UNIX security is that far too often, permissions and authority on a given system boil down to root can do anything, although users can't do much of anything.

Sadly, it's much easier to do a quick su - to become root for a while than it is to create a granular system of group memberships and permissions that allows administrators and sub-administrators to have exactly the permissions they need. Sure, you can use the su command with the -c option, which allows you to specify a single command to run as root rather than an entire shell session (for example, su -c rm somefile.txt), but this requires you to enter the root password. It's never good for more than a small number of people to know root's password.

Another approach to solving the root-takes-all problem is to use role-based access control (RBAC) systems, such as SELinux, which enforce access controls that reduce root's effective authority. However, this makes things even more complicated than setting up effective groups and group permissions. This is not to say that SELinux and the rest aren't good things—I love RBAC.

A better middle ground is to use the sudo command. sudo is short for superuser do, and it allows users to execute single commands as root, without actually needing to know the root password. sudo is now a standard package on most Linux distributions.

sudo is configured with the file /etc/sudoers, but you shouldn't edit this file directly. Rather, use the visudo command, which opens a editor on the file; vi is the editor by default. You can use a different editor by setting the EDITOR environment variable. For example, to use /usr/bin/gedit, do this:

export EDITOR=/usr/bin/gedit

Space doesn't permit me to explain sudoers' syntax in detail; see the sudoers(5), sudo(8) and visudo(8) man pages for complete information. In the space available here, let's run through a quick example.

Remember the user crash's quest to rid the world of Pineapple-Mushroom Surprise? Although in this case it would be overkill—the permissions techniques I've already illustrated are sufficient—you could use sudo to allow crash to realize his goal, assuming you (biff) have root privileges. First, become root (su -). Next, execute the command visudo. You're now in a vi session, editing the file /etc/sudoers; see the vi(1) man page if you're new to vi. Go down to the bottom of the file and add this line:

crash localhost=/bin/rm /home/biff/extreme_casseroles/pineapple_mushroom_surprise.txt

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Comment

Trupti's picture

Helpful post. Every bit is covered here.Thank you.

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix