User Resource Management


In the preceding section, we saw how to define a default shell for local user processes. In doing so, we also introduced scripts that will be executed automatically upon login and logout. These scripts can be used to customize the user environment, provide for common environment variables, and allow for a common system-wide configuration. In the following sections, we examine how to further refine a client's access to system resources.

Authentication Using PAM

Historically, application developers were burdened with developing their own methods for user authentication. This application-by-application approach has led to a multitude of disparate authentication schemes, resulting in individual users having multiple accounts and multiple passwords.

SUSE LINUX uses a system called the Pluggable Authentication Module, or PAM, to standardize the authentication process. With PAM, a programmer can rely on a series of predefined routines to properly identify users. This places the burden of authentication outside the program, resulting in a more portable and flexible architecture for the application.

In SLES, PAM is involved with all aspects of authentication. The main application-specific configuration files for PAM are located in /etc/pam.d. Each one of these files contains the rule sets used by PAM to establish the validity of a user for a specific application.

PAM rules are defined by combining four different module types or families:

  • authentication Uses challenge-response to verify the user.

  • account Determines whether the account is valid or expired.

  • password Verifies passwords and the strength of passwords.

  • session Processes session setup or teardown.

Each module family can contain multiple member modules. Each member module can be used to validate a specific characteristic required by the application being invoked. As an example, a collection of modules could check the group membership of an account, which terminal the account is being used from, as well as time of day. If all conditions are met, control is passed to the next family of modules. If not, the user session can be terminated.

In the simplest of cases, a family of rules can be satisfied by a single check. In most cases, however, applications require the validation of multiple aspects of an authentication request before a user is granted access.

Each module can be further tweaked by passing parameters that modify its behavior. These passed values override preset default characteristics. The configuration files that store the default behaviors are stored in /etc/security. We examine them more closely in the next section.

For each member of each family, it is possible to define a "level of compliance" the rule must satisfy. This metric is called a control flag within PAM. Four different levels of control flags are currently recognized:

  • Required Individual veto for the module family. Unless this test returns a valid result, the family will refuse access.

  • Requisite Immediate veto of access. If this test fails, the authentication request will be immediately denied.

  • Sufficient If this test passes, no other steps need take place. Failure of this rule does not terminate the authentication process. Rule evaluation resumes with the next member or family.

  • Optional This rule is used to trigger events that do not directly affect the authentication process. It is usually used to provide the client with additional status information.

The permutations and combinations of the modules types (family), the control flags (compliance), and the individual modules available make PAM a granular method of authentication. The variations available also make understanding PAM configurations somewhat daunting. To get a better understanding of a typical PAM configuration, let's examine an out-of-the-box configuration. Located in the /etc/pam.d directory is a PAM configuration file for the login process. Listing 5.5 shows the content of this file.

Listing 5.5. Content of /etc/pam.d/login
 #%PAM-1.0 auth requisite  pam_unix2.so  nullok     #set_secrpc auth required   pam_securetty.so auth required   pam_nologin.so #auth required  pam_homecheck.so auth required   pam_env.so auth required   pam_mail.so account required    pam_unix2.so password required   pam_pwcheck.so  nullok password required   pam_unix2.so    nullok use_first_pass use_authtok session required    pam_unix2.so    none     # debug or trace session required    pam_limits.so 

This first family of modules is the group of authentication modules. Within this family, no fewer than five separate tests are done to validate authentication. The auth family calls the following modules:

  • pam_unix2.so verifies that this is a valid username in the /etc/passwd and /etc/shadow files.

  • pam_securetty.so verifies that the user root is allowed to access the system from the current terminal.

  • pam_nologin.so verifies the existence of /etc/nologin. If it is present, the content of the file is displayed to the user, and the authentication is refused.

  • pam_homecheck.so checks to see whether there are dangerous world-writable files/directories in the user's default login tree and issues a warning. (This option is commented out in the example.)

  • pam_env.so sets or forces particular environment variables to specific values.

  • pam_mail.so provides a "New Mail" notification to the user.

The second family of modules is of the account type. In this example, only one rule exists, and it references a module used previously in the auth type. In this instance, the pam_unix2.so rule checks the account to verify that the account is valid: not locked, has not expired.

The third rule type used pertains to the password family. The rules are applied as follows:

  • pam_pwcheck.3so prompts for the user password and verifies it. In the case of an expired password, this rule prompts for a new one and checks it against a series of rules to ensure it is appropriately complex. In the example, NULL passwords are acceptable.

  • pam_unix2.so updates the session authentication token using the password provided from the previous rule.

The final set of rules that are checked during a login are the rules governing the session. They are mostly used for the setup and teardown routines that are invoked at process creation and removal. In the example, we have these two rules:

  • pam_unix2.so is responsible for preparing the session environment for the client.

  • pam_limits.so verifies resource consumption by the account in question against predetermined limits.

The preceding example illustrates how something as simple as a login can look quite complex. It is important to remember, however, that this complexity has been removed from the application level. The benefits of this approach allow for a common and flexible authentication rule set to be applied across multiple applications. In this way, you can ensure that applications such as login, rlogin, and ssh all follow the same methodology when authenticating access. This removes the opportunity for one application, such as POP3, to accidentally present a weaker authentication mechanism to an attacker.

PAM Module Configuration

In the example in Listing 5.5, a number of the modules are passed parameters that affect how they behave. It is possible to preconfigure certain modules to dictate their behavior should a parameter not be passed. These configuration files are stored in /etc/security.

The pam_unix2.so module used in the example has a corresponding pam_unix2.conf file. This file contains default values, and hence specific behavior, for each of the rule families that call it. In the current configuration, because MD5 hashes are used for the account passwords, the password family has a default parameter value of MD5 in pam_unix2.conf. Similarly, the pam_pwcheck.so module's configuration file defines that it should use the cracklib tool and md5 to verify passwords.

If parameters are passed to the module from within the PAM configuration file, the passed values will supersede those in the configuration.

Resource Management

An additional benefit to the PAM approach is that a number of additional layers of system management can be directly tied into process creation. In the previous example, the final required module reference in the session group refers to a module called pam_limits.so.

The limits module allows the system administrator to limit the resources an account can consume on a system. On individual workstations, resource contention affects only the currently logged-on user. On larger servers, individuals can have an impact on performance if they are allowed to consume any and all available resources.

The pam_limits.so module holds its configuration in /etc/security/ limits.conf. An example of this file is shown in Listing 5.6.

Listing 5.6. A Typical PAM limits.conf File
 # /etc/security/limits.conf # #Each line describes a limit for a user in the form: # #<domain>        <type>  <item>  <value> # #Where: #<domain> can be: #        - an user name #        - a group name, with @group syntax #        - the wildcard *, for default entry #        - the wildcard %, can be also used with %group syntax, #                 for maxlogin limit # #<type> can have the two values: #        - "soft" for enforcing the soft limits #        - "hard" for enforcing hard limits # #<item> can be one of the following: #        - core - limits the core file size (KB) #        - data - max data size (KB) #        - fsize - maximum filesize (KB) #        - memlock - max locked-in-memory address space (KB) #        - nofile - max number of open files #        - rss - max resident set size (KB) #        - stack - max stack size (KB) #        - cpu - max CPU time (MIN) #        - nproc - max number of processes #        - as - address space limit #        - maxlogins - max number of logins for this user #        - priority - the priority to run user process with #        - locks - max number of file locks the user can hold # #<domain>      <type>  <item>         <value> # # eric    soft    nproc   12 eric    hard    nproc   20 eric    hard    maxlogins       2 hart    hard    maxlogins       1 # End of file 

In this example, limits have been placed on Eric's account. Though there are many other possibilities for limiting an account, maxlogins and nproc will most certainly be used the most often. With the current configuration, the account eric is limited to two concurrent login sessions. Because each session can spawn a number of child sessions, a process limit has been set significantly higher. Keep in mind that a command that contains a number of pipes creates numerous concurrent children to process the information. The nproc value must therefore be large enough to satisfy the process nesting that will occur.

What happens when the resource has been exhausted depends on how the limit was reached. In the case of a Telnet session to the host, the account eric will receive a simple permission denied message, as shown here:

 Athena login: eric Password: Permission denied Connection to host lost. 

The nproc limit is experienced quite differently. As you can see in the following example, if the number of login sessions is less than the limit, the user is able to log in. If, during the login process, the number of processes exceeds the allowed hard limit, the system is unable to create a session for the user, and the connection is dropped.

 Athena login: eric Password: Last login: Tue Feb 15 07:03:56 from console Connection to host lost. 

We have seen in this section that we are able to control the resources consumed by an end user. Application of such measures is required only in cases of abuse, but it is good to know that this can indeed be achieved. Keep in mind that these limits are on a per-account basis and are not restricted to simple logins. Other applications that use PAM can also make use of the pam_limits.so module.

Access Time Management

In many mission-critical applications, it is important to restrict application and content changes to specific well-controlled change windows. A method for enforcing such an environment is to use the pam_time.so module. This module allows you to control the access to specific services based on where the access is being requested from, the account requesting the access, as well as the time the request is being made.

Because you are now introducing time restrictions into the login process, you must inform PAM that this additional step is required. To do this, you must add a line to the PAM login configuration file /etc/pam.d/login. The new version of this file should now look like Listing 5.7.

Listing 5.7. A Typical PAM pam_time.so Module Configuration File
 #%PAM-1.0 auth requisite  pam_unix2.so    nullok       #set_secrpc auth required   pam_securetty.so auth required   pam_nologin.so #auth    required       pam_homecheck.so auth required   pam_env.so auth required   pam_mail.so account required  pam_time.so account required  pam_unix2.so password required pam_pwcheck.so  nullok password required pam_unix2.so    nullok use_first_pass use_authtok session required  pam_unix2.so    none   session required  pam_limits.so 

Listing 5.8 shows a snippet of a configuration file for the time module /etc/security/time.conf. In this example, the login application is denied to users eric and hart during the evenings.

Listing 5.8. Login Time Restriction Example for time.conf
 #service;ttys;users;times login;*;eric | hart ;!Wk1800-0700 

Connecting using Telnet to Athena yields the following:

 Athena:~> telnet 192.168.1.242 Trying 192.168.1.242... Connected to 192.168.1.242. Escape character is '^]'. Welcome to SUSE LINUX Enterprise Server 9 (i586) - Kernel 2.6.5-7.97-smp (2). Athena login: eric Password: Permission denied Connection closed by foreign host. 

This result is what you would expect. The twist, however, is that it leaves the following back door available during the time window:

 Athena:~> ssh -l eric 192.168.1.242 Password: Last login: Tue Feb 15 18:04:35 2005 from 192.168.1.247 eric@Athena:~> date Tue Feb 15 18:06:48 EST 2005 eric@Athena:~> eric@Athena:~> 

It is important to remember that Telnet uses the login process to gain access to the machine while ssh uses the sshd program. Both use different modules for PAM, and both have their own separate configuration modules. If you want to restrict access using sshd as well, the /etc/security/time.conf file must include

 sshd;*;eric | hart ;!Wk1800-0700 

As well, the /etc/pam.d/sshd PAM module configuration file must include an account verification step for time as well. It would now become

 #%PAM-1.0 auth required   pam_unix2.so # set_secrpc auth required   pam_nologin.so auth required   pam_env.so account required        pam_unix2.so account required        pam_nologin.so account required        pam_time.so password required       pam_pwcheck.so password required       pam_unix2.so    use_first_pass use_authtok session required        pam_unix2.so    none       # trace or debug session required        pam_limits.so # Enable the following line to get resmgr support for # ssh sessions (see /usr/share/doc/packages/resmgr/README.SuSE) #session  optional      pam_resmgr.so fake_ttyname 

This now closes the sshd access method, as shown in the following. As with login and ssh, a user could use a number of other methods to access the system: ftp, xdmcp, and so on. All of them will have to have their own pam.d configuration checked for time restrictions as well.

 Athena:~ # ssh -l eric 192.168.1.242 Password: Password: Password: Permission denied (publickey,keyboard-interactive). Athena:~ # 

We have seen in this section that it is possible to define limits for resource consumption on a system. As a first control, the PAM time module allows you to selectively restrict the times at which certain applications are available to select users or groups. Also, using the PAM limits module, you can control the resources certain users can consume. The application of these limiting tools must be taken into consideration for each and every application that uses PAM. Failure to do so could allow access to the system through alternate means.

Quota Management

Previously, we introduced the concept of managing volatile system resources such as RAM and CPU utilization consumed by end-user processes. By limiting the number of interactive sessions and the number of child processes, you are able to control the resource impact of each user. In this section, we address the other consumable that is often abused by individual users: disk space.

Storage subsystems have become larger and larger. With this increase has come an insatiable appetite for storage from the user community. In a server environment, it is imperative to keep resource consumption down to the level of what is appropriate for the tasking of the machine. This is done to ensure that maintenance tasks such as backups are completed in a timely fashion and that resources are available for new initiatives. Invariably, however, servers are subject to "scope creep" and sometimes abuse. It is not uncommon for a user to store a backup of his or her local system on the corporate file server just because it is a safe place.

SLES is capable of monitoring and limiting disk space. This functionality is not active by default on a server, however. A certain amount of overhead is involved, and in most cases, quotas are not necessary. In this section, we walk you through the necessary steps to invoke quotas on a server.

Quotas are administered on a per mount point basis. On a typical server, user content directories are segregated from the system partition by placing them on separate disk partitions. Dynamic environments such as /home and /srv are typically mount points for such partitions. These locations are prime candidates for quotas.

NOTE

Quota support is a kernel-level function. By default, the SUSE kernel supports disk quotas. If you recompile your kernel to include or remove functionality, you will have to ensure that quota support is included if required.


CAUTION

Before you modify any disk or partition information, it is imperative to ensure that you have a valid recent backup of your system.


The disk configuration for Athena is shown in Figure 5.1. You can reach this YaST screen by starting YaST, selecting the System program group, and then selecting the partitioner icon. Here, you can see that the servers have three main disk areas: /, /swap, and /home. To enable quotas on the /home partition, select the partition and click the Edit button.

Figure 5.1. The YaST Partitioner main menu.


After you click Edit, the edit screen shows up for the /home partition (see Figure 5.2). You engage the quota system by placing an additional option on the partition information within fstab. Select the Fstab Options button to assign the quota parameter.

Figure 5.2. Editing the /home partition fstab options.


Selecting the Fstab Options button activates a window similar to the one in Figure 5.3. At the bottom of the window is a text box labeled Arbitrary Option Value. In this field, type usrquota. This tells the kernel that this partition needs to keep track of disk usage whenever files are written or removed from the disk. You can activate the change by clicking OK and then Apply to return to the main partitioner window.

Figure 5.3. Adding the usrquota option to the /home partition.


NOTE

You also can enable quotas on a partition by manually editing /etc/fstab. It is prudent to make a backup copy of fstab just in case you make a mistake. Editing the file directly is quite safe and will yield the same result. Simply add the usrquota qualifier to the mount options for the partition in question. Of course, changing these options will require the partition in question to be remounted to acquire the new characteristics.


You can now create the initial files for the quota system by invoking the quotacheck command. This command looks at all partitions mounted on the system and creates, or verifies the consistency of, the files required for keeping track of disk usage and limits:

 Athena:~ # quotacheck -auvg quotacheck: Scanning /dev/sdb1 [/home] quotacheck:  Cannot stat old user quota file: No such file or directory quotacheck: Old group file not found. Usage will not be subtracted. done quotacheck: Checked 92 directories and 220 files quotacheck: Old file not found. Athena:~ # 

In this case, quotacheck recognized that on this system only the /home mount point had quotas turned on. It also noticed that there were no previous copies of the quota files and hence created new versions.

The next step is to activate the quota monitoring service. It is important to ensure that this service starts when the system itself restarts. Using the YaST Runlevel Editor, select the quotad service to run on reboot.

At this point, it is prudent to reboot the system. Doing this remounts all the partitions with the appropriate parameters. When the system comes back up, you are ready to enable and set quotas.

You are now ready to assign quotas to individuals. The amount of disk space allowed for an individual will be left up to a corporate policy, a service-level agreement, or simply good judgment. The total amount of quota allocated to the users should not exceed the disk capacity. Doing so allows the disk to be filled even though a number of users are below quota. It also makes monitoring the quota more difficult. Disk space allocation in SUSE is done in 1KB blocks. Quota limits can therefore be directly related to the amount of disk space, in kilobytes. Similarly, there is a one-to-one relationship between inodes and files. Specifying an inode limit fixes the number of files a user can have independently of how large they become.

The command used to set a quota for a user is called setquota. This command takes the following syntax:

 Setquota -u user #blocks_soft #blocks_hard #inodes_soft #inodes_hard mount_point 

In this command, the soft limits generate over-quota warnings, and the hard limits cause the system to prevent the consumption of additional resources. A policy should exist that users on a device receive a fixed quota. Stating the policy up front permits the users to police themselves and not lose important information when their quota is exhausted.

Current disk usage for a user can be determined using the du command:

 Athena:~ # du -s /home/hart 116     /home/hart Athena:~ # du -s /home/eric 548     /home/eric 

In this example, you can see that the user hart has consumed only 116 blocks and eric has consumed 548. When this file system was created, each block was associated with a size of 1KB. The other parameter you need to understand is the inode value you want to use. An inode is a structure that keeps track of file information. In addition to size and access time stamps, an inode points to the string of blocks that make up the content of the file. The inode itself does not contain the data portion of the file. There is a one-to-one relationship between the number of inodes allocated and the number of files a user can generate. To find out how many inodes are available on the partition with quota, use the df command:

 Athena:~ # df -i /home Filesystem            Inodes   IUsed   IFree IUse% Mounted on /dev/sdb1            1835008     322 1834686    1% /home 

You have now collected enough information for setting quotas. Allow your users to consume 10 megabytes of disk space, which is the equivalent of 10,000 1KB blocks, and create 20,000 files. Because you don't want users to hit the wall without any warning, place the soft limits at their target quotas and the fixed limits slightly above. First, check to see what quotas are in force for each user:

 Athena:~ # quota eric Disk quotas for user eric (uid 1001): none Athena:~ # quota hart Disk quotas for user hart (uid 1002): none 

Now set limits:

 Athena:~ # setquota -u eric 10000 11000 20000 21000 /home Athena:~ # quota eric Disk quotas for user eric (uid 1001):      Filesystem  blocks  quota   limit   grace   files    quota   limit   grace       /dev/sdb1     548   10000   11000             130    20000   21000 Athena:~ # setquota -u hart 10000 11000 20000 21000 /home Athena:~ # quota hart Disk quotas for user hart (uid 1002):      Filesystem  blocks   quota   limit   grace   files    quota   limit   grace       /dev/sdb1     116   10000   11000              23    20000   21000 Athena:~ # 

The final step is to configure the system to send out warning messages when users are approaching their limits. The quota subsystem contains a procedure called warnquota. This routine checks all user quotas and dispatches messages to those who are over their quota. The configuration file containing the warnquota message is called /etc/warnquota.conf. A stripped-down version of this file is shown in Listing 5.9.

Listing 5.9. Disk Quota Warning Configuration File
 /etc/warnquota.conf # this is an example warnquota.conf # MAIL_CMD        = "/usr/bin/mail -t" FROM            = "quota_cop@localhost" # but they don't have to be: SUBJECT         = Hey, user, clean up your account! CC_TO           = "root@localhost" SUPPORT         = "HelpDesk@UniversalExport.ca" PHONE           = "Ext. HELP or (4357)" # Text in the beginning of the mail # This way text can be split to more lines # Line breaks are done by '|' character MESSAGE         = Hello, I've noticed you use too much space\  on my disk|Delete your files on following filesystems:| # Text in the end of the mail # is created) SIGNATURE       = See you!|                     Your admin| 

It is important to modify this file for your system configuration. By default, the MAIL_CMD variable does not point to a valid entry.

As an example, user hart has been busy collecting files in his directory. Checking his quota reveals the following:

 Athena:/home/hart # quota hart Disk quotas for user hart (uid 1002):      Filesystem  blocks   quota   limit   grace   files    quota   limit   grace       /dev/sdb1   10828*  10000   11000   6days      99   20000   21000 

Running warnquota generates an email similar to the following:

 From root@Athena.UniversalExport.ca  Wed Feb 16 04:36:14 2005 Date: Wed, 16 Feb 2005 04:36:13 -0500 To: hart@Athena.UniversalExport.ca Cc: root@localhost.UniversalExport.ca Subject: Hey, user, clean up your account! From: root@Athena.UniversalExport.ca (root) Hello, I've noticed you use too much space on my disk Delete your files on following filesystems: /dev/sdb1                         Block limits               File limits Filesystem           used    soft    hard  grace    used  soft   hard  grace /dev/sdb1      +-   10828   10000   11000  6days      99 20000  21000 See you!                         Your admin 

As a system administrator, you have to decide how often to check quotas. Once the policy has been set, you can include the warnquota command in a cron entry so that it is run on a consistent schedule.

User hart can then choose to reduce his consumption, ask for more disk space, or ignore the warning. If he chooses the latter, eventually the grace period will expire, and the user will not be able to create additional files. A sample login session 10 days later will yield this result:

 hart@Athena:~> hart@Athena:~> hart@Athena:~> date Sat Feb 26 08:45:48 EST 2005 hart@Athena:~> hart@Athena:~> quota Disk quotas for user hart (uid 1002):      Filesystem  blocks   quota   limit   grace   files    quota   limit   grace       /dev/sdb1   10828*  10000   11000    none     100    20000   21000 hart@Athena:~> hart@Athena:~> hart@Athena:~> ls -la > files.txt /bin/ls: write error: Disk quota exceeded hart@Athena:~> 

In this section, we have seen that it is possible under SLES to limit the amount of disk space consumed by a user. Though quota management is not a module within YaST at this time, it is fairly simple to configure and police. The warnquota utility should be placed in a cron job to run nightly just before or after the backup procedures. This gives the users ample warning of their noncompliance. Limiting the amount of disk space available to users ensures that resources are available across the board. Monitoring resource consumption allows you to better forecast the need for system upgrades.



    SUSE LINUX Enterprise Server 9 Administrator's Handbook
    SUSE LINUX Enterprise Server 9 Administrators Handbook
    ISBN: 067232735X
    EAN: 2147483647
    Year: 2003
    Pages: 134

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net