From the ACLU: Know Your Rights

Last week you learned the basics of using Access Control Lists (ACLs) and the command associated with them: getfacl, setfacl and chacl. This week you’ll learn that protecting the rights of your users is as important as protecting your users from themselves. You’ll also learn the effects of changes to user’s rights.

Managing users and permissions is a full-time job. That’s why your job as System Administrator (SA) exists. Your job is to keep the system running smoothly for the system’s users. That includes patching, file maintenance, performance measurement, capacity planning and user maintenance.

It might sound dehumanizing to say, user “maintenance” but that’s exactly what you’re doing. You have to create, remove, edit and maintain user accounts. By maintain, you have to enforce corporate policy and balance those with user requests. This is never an easy balance to strike.

Background Basics

Yes, it’s true that your job is to “protect and serve.” Often a dirty job, but you’ve chosen to do it. Fortunately for you, Linux systems set very high user restrictions by default. Users have full rights to their home directories and the /tmp directory but nothing else. This default permissions policy protects them from destroying important files, it protects other system users from accidents, it does a good job of preventing most malicious attacks and perhaps most refreshing of all: It protects you, the SA.

For example, you create a user account for a new hire into the Human Resources and Accounting Department named John Oker, and following corporate account policy, you create his user account in the usual way.

Note: The HR group (444) and the Accounting group (999) already exist on your system.

Now he’s all fixed up, or is he? You forgot to read the second page of the request which clearly states that John Oker also needs special (full) access to the Management HR Files and Management Accounting Files. Everyone else in John’s group has read-only access to those files. These files exist under the HR and the Accounting directories.

John can edit the Managers.txt file but he can’t remove it due to the Accounting directory permissions (r-x) for the Accounting group.

Note: A malicious user can empty the file and save it as a workaround to his inability to remove the file from the filesystem. This is why good backups on critical files takes first priority over the best laid security or ACL scheme. And, in the case of financial or HR files, several snapshots per day, scheduled via cron, should be in place.

Now that you’ve established the background for this lesson, let’s give John and his account a workout.

As stated earlier, every user has a home directory where he may create files and directories at will. There are other directories that a user might have access to as well. For this example, let’s say that user robert has used the system for a while and has 100MB or so in his home directory. He also has access to the Techs document repository, which is a shared directory for all members of the Techs group to create documentation. Robert has created his share of files in this shared directory. He is the owner but the Techs group also has full rights (rwx) to all files.

A new manager has taken over Robert’s area and has decided to promote Robert to a new Tech Lead position within the group. As a Tech Lead, his User ID (UID) must fall in the range of 6000-6999. Currently, his UID is 505. The change to is UID is a simple one to perform but the consequences of such a change carry substantial weight. Let’s take a look at why this is true.

It’s a fairly simple task to change a few files to reflect Robert’s new UID but what if Robert has files on 50 different systems? Home directory files aren’t a problem. Those receive the updated UID automatically. The stray files that Robert owns on 50 systems is a real problem. Why? The answer is that files without a proper owner set off alerts to security scans and the threat of removal of those files is real.

Changing a user’s Group ID doesn’t have the same effect unless that user is the only member of a particular group. Changing a UID has far reaching effects and should only occur when absolutely necessary.

The Cleanup Process

Are you ready to find out what happens when you have to perform some negative user maintenance? That is to say, removing users from the system. This unpleasant task is two-fold: You must remove the user account (which is often associated with negative circumstances) and you have to clean up all files owned by the former user.

Files that have lost their owners will show up in those security scans mentioned earlier and risk removal regardless of their importance. This is what you see in the Techs directory after user john‘s dismissal from the company.

You can handle a situation like this in a couple of different ways. You can remove the dismissed user’s account and face the orphaned files issue or you can simply disable the account by placing a # in front of the account entry in the /etc/passwd file. Disabling the account will have the effect of blocking the user’s access and keeping the files as “owned” until other group members can take ownership of the departed user’s files.

Standard file permissions and ACLs provide you, the System Administrator, with a great deal of power over user’s rights. And, you need to remember that with great power comes great responsibility. Practice ACLs before implementing them for your users. Or, in some cases, subjecting your users to them.

Next week, you’ll add a new tool to your System Administration Toolbox by looking at a new way to extensively query your Ethernet devices.

Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62