Paranoid Penguin - Linux Filesystem Security, Part II
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.
Listing 3. Checking My Default Permissions Mask
mick@localhost:/home/mick> umask 0022
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.
Listing 4. File and Directory with Mask of 0022
-rwxr-xr-x 2 mick users 48 2004-08-13 08:31 default_dir -rw-r--r-- 1 mick users 4 2004-08-13 08:31 default_file
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.
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:
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
|The True Internet of Things||Sep 02, 2015|
|September 2015 Issue of Linux Journal: HOW-TOs||Sep 01, 2015|
|September 2015 Video Preview||Sep 01, 2015|
|Using tshark to Watch and Inspect Network Traffic||Aug 31, 2015|
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
- Using tshark to Watch and Inspect Network Traffic
- The True Internet of Things
- September 2015 Issue of Linux Journal: HOW-TOs
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Concerning Containers' Connections: on Docker Networking
- Firefox Security Exploit Targets Linux Users and Web Developers
- Where's That Pesky Hidden Word?
- A Project to Guarantee Better Security for Open-Source Projects
- Build a “Virtual SuperComputer” with Process Virtualization
- My Network Go-Bag