Wheel Group on HP-UX 11i

On HP-UX 11i, it appears that setting up the wheel group has been made easier than ever through the use of PAM and the pam_hpsec module.

To enable the wheel group, make sure that the wheel group does, in fact, exist – you’ll probably have to add it. After adding the wheel group, make yourself a member of it (no sense in getting locked out, right?).

Edit the file /etc/default/security and look for the entry:

# SU_ROOT_GROUP=wheel

Uncomment this line (by removing the first two characters) and save:

SU_ROOT_GROUP=wheel

You’re done! Easy, wasn’t it?

Powered by ScribeFire.

The root account (and toor)

Traditionally, the root account (account 0) is not used for daily tasks.  This is widely known; however, this is the reason that root’s home directory was usually / (the root directory) as there was no need for .profile, .login, .Mail, and so forth.  The root account is even created under MacOS X with a locked-down password (that is, there is no valid password for root, making it impossible to log in as root).

However, this is most certainly not the case today – and more and more administrators use the root account for many tasks. One common problem is the problem of someone wanting to change the root shell – and then breaking the startup process since some scripts would assume that the shell is the Bourne shell.  This was more of a problem under BSD since the standard BSD shell was the C shell, and the startup scripts usually assumed the Bourne shell (which is completely incompatible with the C shell).  The toor account (that is, root spelled backwards) was created for this purpose: a person can log in as toor and have the C shell (csh), but not affect the standard startup process.  A toor user would still have the userid zero (0) but would for all intents and purposes be the root user.

This would also lead to the possible creation of a specific home directory for the toor user.

In MacOS X, the root user is locked down and no login is possible as root.  To access root, the sudo utility must be used as the admin user (which should be the user that installed MacOS X).

The wheel group is also part of this process; using the wheel group can expand the capabilities of some users in order to further reduce the need to actually use the root account as a shell account.

Thus, you can see that there is really no reason to use the root account.  But is that going to stop us? Perhaps it should…

Using the Wheel Group in HP-UX (or UNIX in general)

Many versions of UNIX do not support the wheel group at all. Hewlett-Packard’s HP-UX is one of these. The main focus and purpose of a wheel group can be summarized thus: Not everyone should be able to run the su command.

To accomplish this does not require a lot. First, the wheel group must be created. Add the group to the /etc/group file:

wheel:*:0:root,dgd

It is not necessarily required that the wheel group occupies userid 0 – but it is entirely appropriate. Don’t forget to add yourself (your normal userid) to this group. Next step is to check the su command:

# ls -ld `which su`
-r-sr-xr-x 1 root bin 19588 Mar 20 2005 /usr/bin/su

Note that this binary is suid; this must be preserved in order for su to work properly. However, the permissions and group ownership must change in order for the wheel group to work properly. Two things must be changed:

  1. World permissions (“other”) must be revoked
  2. Wheel group members must be able to execute this command

These requirements can be satisfied in this manner:

# chmod 4550 `which su`
# chown root:wheel `which su`

This is only the beginning – but satisfies the initial requirements. The rest is optional, but makes things easier for the administrators in the wheel group. In particular, change the permissions on log files to allow those that are members of the wheel group to read them without having to use switch to root.

The Wheel Group and MacOS X

The setup used here was MacOS X 10.4 (not MacOS X Server) on a PowerPC MacMini.

The wheel group is already set up, but is not called wheel. The group wheel does exist, but the group admin is used by su as the wheel group. The user root belongs to both the wheel group and the admin group.

Another point to remember is that the system uses the NetInfo database, not /etc/group. When NetInfo Manager starts, it presents a list of items (like a list of folders). Select group, then in the next pane, select admin. In the window pane below, look at the property labeled “users” and see that your user id is there as well as root.

If you want to add another user to the “wheel” group (in actuality, the admin group here), add a new value to the users property. First, click the lock at the bottom right and enter your password so you can make changes. Select the users property. Next, in the menu bar, select Directory, and under that, select Insert Value. Put the selected user in the entry box that shows up and press Enter when done.

Don’t forget to save this or no changes will take place. This can be done with the usual Command-S or under the menu Domain, select Save Changes.

Wheel Group and Fedora (Red Hat) Linux

My post on the importance and methods of wheel groups remains popular. I though I would go into various UNIX variants and detail specifically how to activate wheel groups.

Today, the discussion is around Red Hat Linux (speaking generally). The test system was running Fedora Core 5; however, this area of Red Hat has not changed in quite some time, so it is likely to be the same in Fedora 7 and so forth.

First, make sure there is a wheel group in the /etc/group file. On Fedora Core 5, there is:

wheel:x:10:root

If this line does not exist, add it.

Of course, you must put users that you want to be admins into the wheel group. To do this, add the user to the end of the wheel group line. This will make the wheel group a secondary group; I don’t know if that will make a difference today, but it might somewhere.

Second, change into the /etc/pam.d directory, and edit the file su. This file controls the access to the program su and modifies its behaviors during the authentication process. The change will modify the access so that only those in the wheel group have access to the program su.

Find these lines in /etc/pam.d/su:

# Uncomment the following line to require a user to be in the “wheel” group.
#auth required pam_wheel.so use_uid

And change them (as suggested) to this:

# Uncomment the following line to require a user to be in the “wheel” group.
auth required pam_wheel.so use_uid

This access change is not necessarily limited to the su command, but no other command has normally been included in the past. If there are other commands that only those in the wheel group should be able to access, then this line could be put into their PAM configuration (in the right place).

Note that editing PAM files could very easily lock you out of your machine completely; thus do not take editing PAM files (in /etc/pam.d) lightly. The Red Hat authored wheel group modification is simple and easy; other changes you make may not be.

Then, expand the permissions in sudo to account for those with wheel permissions. Edit the configuration file with visudo and change these lines:

# Uncomment to allow people in group wheel to run all commands
# %wheel ALL=(ALL) ALL

To this (as recommended):

# Uncomment to allow people in group wheel to run all commands
%wheel ALL=(ALL) ALL

This will allow anyone in the wheel group to execute commands using sudo (rather than having to add each person one by one). It would also allow anyone this sort of access on any machine that they have wheel group membership.

The wheel Group

The wheel group is, perhaps, not widely used today, or is seen as “archaic” and irrelevant. Nothing could be further from the truth.

The wheel group is a group which limits the number of people who are able to su to root. This usually consists of a group named “wheel” and a set of users that are permitted to use the utility ‘su’ in order to change to root.

Many systems, especially either commercial systems or Linux systems, come without wheel groups configured and implemented. At least one Linux distribution, comes with wheel groups preconfigured but not active. However, all or nearly all BSD based systems will come with the wheel group installed and set up.

However, at its simplest, a wheel group implementation requires no special set up. The basic set up, as it was in the beginning, was to do the following:

  1. Create a “wheel” group in /etc/groups
  2. Change the permissions of the “su” command so that only those in the “wheel” group may run it.

That’s all there is to it. Many su implementations, however, added internal support for the wheel group, perhaps with logs kept and a more informative refusal message explaining why su would not run (for those not in the wheel group).

Perhaps one reason that the wheel group is not widely used may have something to do with the GNU project. The GNU implementation of su has this in its info page:

Why GNU `su' does not support the `wheel' group
===============================================

   (This section is by Richard Stallman.)

   Sometimes a few of the users try to hold total power over all the
rest.  For example, in 1984, a few users at the MIT AI lab decided to
seize power by changing the operator password on the Twenex system and
keeping it secret from everyone else.  (I was able to thwart this coup
and give power back to the users by patching the kernel, but I wouldn't
know how to do that in Unix.)

   However, occasionally the rulers do tell someone.  Under the usual
`su' mechanism, once someone learns the root password who sympathizes
with the ordinary users, he or she can tell the rest.  The "wheel
group" feature would make this impossible, and thus cement the power of
the rulers.

   I'm on the side of the masses, not that of the rulers.  If you are
used to supporting the bosses and sysadmins in whatever they do, you
might find this idea strange at first.

Is it any wonder that GNU/Linux systems don’t enable the wheel group by default? FreeBSD, however, does use the wheel group by default – as does OpenBSD and NetBSD.