![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Using sugroups allows system administrators to restrict access by group members on who can su to what account. Using the NOT operator, further restriction can be placed on access control. Reporting on who is a member of what sugroup, and what accounts they can su to, needs to be identified for auditing purposes. This involves generating a report on sugroup member access and is generally considered a compliance task.
System administrators who provide su access to a user gives the ability for a user to switch or substitute to another user without logging out from their current account. Typically, su accounts are setup so that a user can temporarily switch to another account, for example the root user or an application owner. However, as application support grows so does the maintenance overhead on administrating the system. Using sugroups makes the management of su permissions more manageable, as you are dealing with groups instead of lots of individual users.
Using sugroups allows system administrators to group certain users and give them the ability to su to different accounts. The actual su access is controlled by being a member of a certain AIX® group. When a user is created, you can specify a sugroup as part of the users attributes; only members of this group are allowed to su to that user. Of course the user su-ing needs to know the password to su successfully. Other users who know the password of the user, but do not belong to the sugroup specified, will not be able to su to the said user, since they do not belong to the correct sugroup.
Having stated the previous, it may not be the security policy of some systems to divulge passwords to other users. In that case, one can use sudo. This is discussed later.
To determine what sugroups are in place, there are a couple of commands that will be useful. They are:
lsuserlsgroup
In the following example, the lsuser command is used to
output all sugroups of all users. This list could be quite long depending on the amount of users configured on the system:
# lsuser -a sugroups ALL |
When a user is created and no sugroup is specified, AIX defaults to ALL. This means any group can su to that user. To filter out the default ALL, use 'grep -v' to list all users with sugroups that do not have the default ALL attribute set. Replace ALL with your default sugroup on your system, located in:
/etc/security/user: # lsuser -a sugroups ALL|grep -v ALL |
To list a single user with its sugroups attributes, in this case user pinky, use the following code:
# lsuser -a sugroups pinky pinky sugroups=wasgrp,websp |
In the above output, we can see that user pinky has sugroups of wasgrp and websp.
To then list the members of the sugroups wasgrp and websp, use the following code:
# lsgroup -a users wasgrp admin users=dxtans,pxcon,jgena # lsgroup -a users websp admin users=dcand, |
So we now know that user pinky has sugroups of wasgrp and websp, and the members of those groups who are allowed to su to user pinky are:
dxtans,pxcon,jgena,dcand |
You can use the grep utility to search the system user
attribute defaults in the file. Depending on the placement of comments in the file, one of the following will extract just the default stanza :
grep -p "default:" /etc/security/user grep -v ^"*" /etc/security/user| grep -p "default:" |
Or better still just grep for the sugroups in the defaults stanza:
# grep -p "default:" /etc/security/user| grep sugroups
sugroups = ALL
|
Let's look at an example of how a sugroup is implemented.
# lsuser -a sugroups dxtans dxtans sugroups=ALL |
We can see from the previous output that the sugroup attributes is set to ALL. That
means any user, or any group member, has the ability to su to the account of dxtans provided they know user dxtans
password. Now let's change the sugroups attribute to only include the group smoke:
# chuser sugroups=smoke dxtans # lsuser -a sugroups dxtans dxtans sugroups=smoke |
Looking at the members of group smoke, we only have one member: papa
# lsgroup -a users smoke smoke users=papa |
If another user who is not a member of group smoke tries to su, this is what happens:
$ whoami bravo $ su – dxtans dxtans's Password: 3004-307 You are not allowed to su to this account. 3004-501 Cannot su to "dxtans" : Account is not accessible. |
Now if user papa tries to su to dxtans account and the password is known, access is granted:
$ whoami papa $ su - dxtans dxtans's Password: $ id uid=203(dxtans) gid=1(staff) |
Attempts of su access are logged to /var/adm/sulog.
Using the previous demonstration of the su attempts, we have two entries. A plus sign
indicates a successful su attempt occurred from user papa
to user dxtans. A minus sign indicates a failed su attempt occurred from user bravo to user dxtans:
$ tail /var/adm/sulog SU 04/17 19:51 + pts/1 papa-dxtans SU 04/17 19:52 - pts/1 bravo-dxtans |
If a user is trying to su to another user and is getting an 'Account is not accessible' message, and you are sure that the authentication via sugroups or su is correct, then check that the destination user does not have unsuccessful login attempts breeched. Perhaps the password has expired, or an initial password has not been set.
A must have sugroup on any system
Hopefully thus far I have convinced you why creating sugroups is more attractive than creating lots of individual su permissions. Even if you do not buy into the use of sugroups, at least create one sugroup to manage the su to the root account. Typically, system administrators login in as themselves then su to root. I will now demonstrate how the following users (who are system administrators) will only be allowed to su to root. The users are:
john,peter,jane |
The first task is to create a group, we'll call it sysadmin, whose members are listed above. Only members of this group are allowed to su to root.
Create the group with members john,peter,jane:
# mkgroup -A users="john,peter,jane" sysadmin |
Confirm group members:
# lsgroup -a users sysadmin sysadmin users=john,peter,jane |
Give user root sugroup of sysadmin:
# chuser sugroups=sysadmin root # lsuser -a sugroups root root sugroups=sysadmin |
Only members of sysadmin can now su to root.
The root user should not be allowed to login directly via telnet. The user root should only be allowed to login via direct console. Having stated this, when using ssh, using root to ssh across systems can be desirable when dealing with updates and file/script roll-out. It is good practice for root to only be allowed to ssh out from deployment servers.
There may be occasions when you create a new user on a system that you want to forbid
access from anyone being able to su to this user. One way to do this is to create a
group that has no members. Then you can use that group (name) as a sugroup attribute
to that user. For example, suppose we had a user called brown. Due to the sensitive nature of the users environment, no one
should be able to su to that account (except root). We could create a group called none with no members:
# mkgroup -A none # lsgroup -a users none none users= |
Then change the users account sugroups attribute to include that group:
# chuser sugroups=none brown # lsuser -a sugroups brown brown sugroups=none |
As no one belongs to the group none, and it is to be used as a sugroup, no normal user can su to the account of user brown.
If you want to make it a more permanent feature, you could edit the /etc/security/user file. Within the default stanza in the sugroups entry, put in that group just created:
sugroups = none |
Now when all new users are created, by default they will have that sugroup set (no one can su to that user). Please note, all users that already have their sugroups set to ALL (the default) will now have 'none' as their sugroups attribute. Then one can gradually lift the security of that user as your security policy demands.
As previously stated, unless you change the default sugroups value, all users will use that default (which is ALL). To further restrict sugroups access AIX provides the NOT operator '!'. The format for the rule is:
!<group_name > |
By enforcing this rule in the sugroups attribute, the group names that have the NOT operator before the group name will be denied access to su to that account. That may beg the question, "Why?" For ordinary users, you can specify by groups who are denied the ability to su to certain users. You can also use this method by temporary restricting certain groups. This provides greater flexibility in su management by not creating many groups to control or satisfy access to different accounts.
Let's look at an example at how sugroups using the NOT operator might be effective.
Suppose we had a group called sun. From the output of the
following lsgroup, we can determine the users of the
group:
# lsgroup -a users sun sun users=alpha,bravo |
So, the members are:
alpha,bravo |
To allow all users the ability to su to user charlie, but deny access to the members of the group sun, we would use the following command:
# chuser sugroups="!sun,ALL" charlie |
Note in the above command the order of the NOT operator, we first deny then allow.
The following commands list the sugroups and group attributes of the users discussed:
alpha, bravo, charlie # lsuser -a sugroups groups alpha alpha sugroups=ALL groups=staff,sun # lsuser -a sugroups groups bravo bravo sugroups=ALL groups=staff,sun # lsuser -a sugroups groups charlie charlie sugroups=!sun,ALL groups=staff |
Now if user delta, who is not a member of the restricted
group sun, attempts to su to user charlie and knows the password, the authentication will succeed:
# lsuser -a sugroups groups delta delta sugroups=ALL groups=staff,water,fire,mobgrp |
As user delta:
$ id uid=220(delta) gid=1(staff) groups=206(water),207(fire),215(mobgrp) $ su - charlie charlie's Password: $ id uid=211(charlie) gid=1(staff) |
If user alpha, who is a member of the restricted group sun, tries to su to the user charlie, he will be denied access.
As user alpha:
$ id uid=209(alpha) gid=1(staff) groups=214(sun) $ su - charlie charlie's Password: 3004-307 You are not allowed to su to this account. 3004-501 Cannot su to "charlie" : Account is not accessible. |
Let's look at another example of why we might use the NOT operator. Suppose we had
an account called ukflag. We do not want users whom
belong to the groups fire and cloud being able to su to user ukflag, only members of earth should be allowed. First change the user ukflag sugroups attributes, and then confirm the change:
# chuser sugroups="!fire,!cloud,earth" ukflag # lsuser -a sugroups ukflag ukflag sugroups=!fire,!cloud,earth |
Members of group earth are going to be allowed su access to user: ukflag
# lsgroup -a users earth earth users=zulu |
Let's now see who belongs to the groups cloud and fire, whom we are going to restrict su access to user ukflag.
# lsgroup -a users fire fire users=plutt,echoa,golf,hotel,india,juliet,kilo # lsgroup -a users cloud cloud users=hotel,india |
From the lsgroup output we now know that the following user
will only be allowed to su to the ukflag account: zulu. Also from the lsgroup output, we
know the following users will be denied access to su to the ukflag account: plutt,echoa,golf,hotel,india,juliet,kilo.
This can now be demonstrated, from the account of user plutt, a member of the fire group:
$ id uid=230(plutt) gid=1(staff) groups=206(water),207(fire) $ su - ukflag ukflag's Password: 3004-307 You are not allowed to su to this account. 3004-501 Cannot su to "ukflag" : Account is not accessible. |
And from user zulu, a member of the earth group:
$ id uid=228(zulu) gid=1(staff) groups=209(earth) $ su - ukflag ukflag's Password: $ |
As demonstrated, using the NOT operator allows fine tuning of access to user accounts via sugroups the ability to su.
When providing su access, it may not be appropriate to allow other users to know the password of an account that they are allowed to su to. This could particularly be the case for application accounts, when support users need to gain access to resolve an issue. Using sudo, one can let these users gain authorized access without knowing the password that are allowed to su to.
Imagine we have support users alpha, bravo,charlie, whom
all belong to the group app_supp. As part of their
responsibility, they need to gain access to the production environment account:
ukflag. Simply edit the /etc/sudoers file and put in the following entry, replacing rs6000 with your hostname:
%app_supp rs6000 = NOPASSWD:/usr/bin/su – ukflag |
Check group members:
# lsgroup -a users app_supp app_supp users=alpha,bravo,charlie |
Check the user can su via sudo to the account ukflag:
$ whoami
alpha
$ sudo -l
User alpha may run the following commands on this host:
(root) NOPASSWD: /usr/bin/su - ukflag
$ sudo -u root su - ukflag
$ whoami
ukflag
|
You can have many su entries in sudo, just be sure to separate each su entry with comma, like so:
%app_supp rs6000 = NOPASSWD:/usr/bin/su – ukflag, /usr/bin/su – ieflag, /usr/bin/su - plflag |
When using sugroups, it can sometimes become time consuming to review all your sugroups access you have in place, especially when dealing with many systems. It could be advantageous to create a script that generates a snapshot of the sugroups and members. In Listing 1, I present a script that will give an overview of the sugroups in place. It was originally two scripts, but I have merged them for this demonstration into one script. The script builds on the commands used in the section "Commands to know."
When the script is executed, it displays all users who do not have ALL as part of their sugroup attribute. Then, it list the user and the sugroups of that user. The second part of the script will display each sugroup and its respective members.
Listing 1. su_rep1
#!/bin/sh
# su_rep1
list=$(cat /etc/passwd| awk -F: '{print $1}' | sort)
echo "user su groups *(Denied su access)
========================================="
#
# display user and sugroups
for loop in $list
do
sugrp=$(lsuser -a sugroups $loop | sed s/ALL//g | awk -F= '{print $2}'|sed 's/,/ /g')
if [ "$sugrp" != "" ]
then
sugrp=$(echo $sugrp|sed 's/!/*/g')
printf "%-10s %-40s\n" "$loop" "$sugrp"
fi
done
#
# list sugroups and members
echo "\nsugroup sugroup members
=========================="
sugrp_list=$(lsuser -a sugroups ALL| sed s/ALL//g | awk -F= '{print $2}'| tr " " "\n" \
|sed 's/,/ /g' | sed 's/!//g'|tr " " "\n" |awk '!array [$0]++')
for loop in $sugrp_list
do
sugrp_list=$(lsgroup -a users $loop | awk -F= '{print $2}')
if [ "$sugrp_list" = "" ]
then
sugrp_list=" -- No Members --"
fi
printf "%-10s %-40s\n" "$loop" "$sugrp_list"
done
|
When su_rep1 contained in Listing 1 is executed, on my system similar output to the following is produced:
user su groups *(Denied su access) ========================================= charlie *sun dxtans smoke papa syb root admin sysadmin ukflag *fire *cloud earth xray water earth *smoke zulu fire sugroup sugroup members ========================== admin dxtans sysadmin john,peter,jane smoke papa sun alpha,bravo water delta,echoa,golf,plutt earth zulu fire delta,echoa,golf,hotel,india,juliet,kilo,plutt syb wwpdpga1,wwpdclt2,ukflag cloud hotel,india,spoll |
Using sugroups enables system administrators to control access to individual user accounts by group membership. Sugroups provides one method of implementing and managing the security policy on your systems. When being audited, you will have to prove to the auditor access control between normal and application, system accounts, and how the sugroup policy is being monitored. This article has demonstrated how sugroups can be implemented. A script has also been provided to display sugroup access.
Learn
- For additional information see the su and chuser manpages.
Discuss
- Follow developerWorks on Twitter.
- Get involved in the My developerWorks community.
-
Participate in the AIX and UNIX® forums:
- AIX Forum
- AIX Forum for developers
- Cluster Systems Management
- IBM Support Assistant Forum
- Performance Tools Forum
- Virtualization Forum
- More AIX and UNIX Forums
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
