This is probably one of things that people mess up all the time. They both have to do with permissions on a file, but the SUID/GUID (or SETUID short for set-user-id/SETGID short for set-group-id) bit and the sticky-bit are 2 completely different things.

The SUID/GUID

The letters rwxXst select file mode bits for users:

• read (r)
• write (w)
• execute (or search for directories) (x)
• execute/search only if the file is a directory or already has execute permission for some user (X)
• set user or group ID on execution (s)
• restricted deletion flag or sticky bit (t)

The position that the x bit takes in rwxrwxrwx for the user octet (1st group of rwx) and the group octet (2nd group of rwx) can take an additional state where the x becomes an s. When this file when executed (if it's a program and not just a shell script), it will run with the permissions of the owner or the group of the file. That is called the SUID, when set for the user octet, and GUID, when set for the group octet.

So if the file is owned by root and the SUID bit is turned on, the program will run as root. Even if you execute it. The same thing applies to the GUID bit. You can set or clear the bits with symbolic modes like u+s and g-s, and you can set (but not clear) the bits with a numeric mode.

SUID/GUID examples

No SUID/GUID: Just the bits rwxr-xr-x are set:

# ls -lt test.pl -rwxr-xr-x 1 root root 179 Jan 9 01:01 test.pl

SUID and user's executable bit enabled (lowercase s): The bits rwsr-x-r-x are set.

# chmod u+s test.pl
# ls -lt test.pl
-rwsr-xr-x 1 root root 179 Jan  9 01:01 test.pl

SUID enabled and executable bit disabled (uppercase S): The bits rwSr-xr-x are set.

# chmod u-x test.pl
# ls -lt test.pl 
-rwSr-xr-x 1 root root 179 Jan  9 01:01 test.pl

GUID and group's executable bit enabled (lowercase s): The bits rwxr-sr-x are set.

# chmod g+s test.pl
# ls -lt test.pl 
-rwxr-sr-x 1 root root 179 Jan  9 01:01 test.pl

GUID enabled and executable bit disabled (uppercase S): The bits rwxr-Sr-x are set.

# chmod g-x test.pl
# ls -lt test.pl 
-rwxr-Sr-x 1 root root 179 Jan  9 01:01 test.pl

The sticky bit

The sticky bit on the other hand is denoted as a t, such as with the /tmp or /var/tmp directories:

# ls -ald /tmp
drwxrwxrwt 36 bin bin 8192 Nov 27 08:40 /tmp
# ls -ald /var/tmp
drwxrwxrwt  3 bin bin  256 Nov 27 08:28 /var/tmp

This bit should have always been called the "restricted deletion bit" given that's what it really denotes. When this mode bit is enabled, it makes a directory such that users can only delete files and directories within it that they are the owners of. For regular files the bit was used to save the program in swap device so that the program would load more quickly when run; this is called the sticky bit, but it's not used anymore in AIX.

More information can be found in the manual page of the chmod command or on http://en.wikipedia.org/wiki/Sticky_bit.

When you set up a new user account, and assign a password to that account, you'll want to make sure that it is a password that can not be easily guessed. Setting the initial password to something easy like "changeme", only allows hackers easy access to your system.

So the best way you can do this, is by generating a fully random password. That can easily be achieved by using the /dev/urandom device.

Here's an easy command to generate a random password:

# dd if=/dev/urandom bs=16 count=1 2>/dev/null | openssl base64 | sed "s/[=O/\]//g" | cut -b1-8

This will create passwords like:

ej9yTaaD
Ux9FYusx
QR0TSAZC
...

Security guidelines nowadays can be annoying. Within many companies people have to comply with strict security in regards to password expiration settings, password complexity and system security settings. All these settings and regulations more than often result in people getting locked out from their accounts on AIX systems, and also getting frustrated at the same time.

To help your users, you can't go change default security settings on the AIX systems. Your auditor will make sure you won't do that. But instead, there are some "tricks" you can use, to ensure that a user account is (and stays) available to your end user. We've put all those tricks together in one simple script, that can fix a user account, and we called it fixuser.ksh. It will fix 99% of all user related login issues.

You can run this script as often as you like and for any user that you like. It will help you to ensure that a user account is not locked, that AIX won't bug the user to change their password, that the user doesn't have a failed login count (from typing too many passwords), and a bunch of other stuff that usually will keep your users from logging in and getting pesky "Access Denied" messages.

The script will not alter any default security settings, and it can easily be adjusted to run for several user accounts, or can be run from a crontab so user accounts stay enabled for your users. The script is a win-win situation for everyone: Your auditor is happy, because security settings are strict on your system; Your users are happy for being able to just login without any hassle; And the sys admin will be happy for not having to resolve login issues manually anymore.

The script can be run by entering a specific user account:

# fixuser.ksh username

The script:

#!/usr/bin/ksh

fixit()
{

  myid=${1}

  # Unlock account
  printf "Unlocking account for ${user}..."
  chuser account_locked=false ${user}
  echo " Done."

  # Reset failed login count
  printf "Reset failed login count for ${user}..."
  chuser unsuccessful_login_count=0 ${user}
  echo " Done."

  # Reset expiration date
  printf "Reset expiration date for ${user}..."
  chuser expires=0 ${user}
  echo " Done."

  # Allow the user to login
  printf "Enable login for ${user}..."
  chuser login=true ${user}
  echo " Done."

  # Allow the user to login remotely
  printf "Enable remote login for ${user}..."
  chuser rlogin=true ${user}
  echo " Done."

  # Reset maxage
  printf "Reset the maxage for ${user}..."
  m=`lssec -f /etc/security/user -s default -a maxage | cut -f2 -d=`
  chuser maxage=${m} ${user}
  echo " Done."

  # Clear password change requirement
  printf "Clear password change requirement for ${user}..."
  pwdadm -c ${user}
  echo " Done."

  # Reset password last update
  printf "Reset the password last update for ${user}..."
  let sinceepoch=`perl -e 'printf(time)' | awk '{print $1}'`
  n=`lssec -f /etc/security/user -s default -a minage | cut -f2 -d=`
  let myminsecs="${n}*7*24*60*60"
  let myminsecs="${myminsecs}+1000"
  let newdate="${sinceepoch}-${myminsecs}"
  chsec -f /etc/security/passwd -s ${user} -a lastupdate=${newdate}
  echo " Done."
}

unset user

if [ ! -z "${1}" ] ; then
  user=${1}
fi

# If a username is provided, fix that user account

unset myid
myid=`id ${user} 2>/dev/null`
if [ ! -z "${myid}" ] ; then
  echo "Fixing account ${user}..."
  fixit ${user}
  printf "Remove password history..."
  cp /dev/null /etc/security/pwdhist.pag 2>/dev/null
  cp /dev/null /etc/security/pwdhist.dir 2>/dev/null
  echo " Done."
else
  echo "User ${user} does not exist."
fi

Sometimes when password rules are very strict, a user may have problems creating a new password that is both easy to remember, and still adheres to the password rules. To aid the user, it could be useful to clear the password history for his or her account, so he or she can re-use a certain password that has been used in the past. The password history is stored in /etc/security/pwdhist.pag and /etc/security/pwdhist.dir. The command you can use to disable the password history for a user is:

# chuser histsize=0 username

Actually, this command does not the password history in /etc/security/pwdhist.dir and /etc/security/pwdhist.pag, but only changes the setting of histsize for the account to zero, meaning, that a user is not checked again on re-using old passwords. After the user has changed his or her password, you may want to set it back again to the default value:

# grep -p ^default /etc/security/user | grep histsize
        histsize = 20
# chuser histsize=20 username

In older AIX levels, this functionality (to use chuser histsize=0) would actually have cleared out the password history of the user. In later AIX levels, this functionality has vanished.

So, if you truely wish to delete the password history for a user, here's another way to clear the password history on a system: It is accomplished by zeroing out the pwdhist.pag and pwdhist.dir files. However, this results in the deletion of all password history for all users on the system:

# cp /dev/null /etc/security/pwdhist.pag
# cp /dev/null /etc/security/pwdhist.dir

Please note that his is a temporary measure. Once these files are zeroed out, as soon as a user changes his or her password again, the old password is stored again in these files and it can't be reused (unless the histsize attribute for a user is set to 0).

OpenSSL on AIX can be impacted by the Heartbleed bug. Only OpenSSL 1.0.1e (IBM AIX VRMFs - 1.0.1.500 & 1.0.1.501) is vulnerable to the Heartbleed bug (CVE-2014-010). All OpenSSL v0.9.8.xxxx and v12.9.8.xxxx are NOT vulnerable to this CVE.

IBM released OpenSSL 1.0.1g by the end of April 2014, which is the official fix.

The following is information about an ifix that was made available by IBM. The ifix is just a workaround, and currently IBM recommends upgrading to OpenSSL 1.0.1.511 instead (see below).

• This is a workaround compiled with the feature turned off.
• This is not OS dependent. It only depends on the OpenSSL level.

Below are the download and install/uninstall instructions.

The OpenSSL ifix doesn't require a reboot. However... It's a shared library update, so any daemons that use it will need to be restarted such as sshd. If you aren't sure what applications running on your machine use OpenSSL, it's recommended to reboot.

To download it, go to: https://testcase.software.ibm.com/ and log in as "Anonymous" (no password needed). Click on the "fromibm" folder, and then click on the "aix" folder. Scroll down the list until you find the following file and click on it to download:

0160_ifix.140409.epkg.Z

Once the download is complete, transfer the file to your AIX system. Log on to your AIX system, go to the directory where you put the file, and run the following command as the root user.

To preview the installation of 0160_ifix.140409.epkg.Z, please do the following:

# emgr -p -e 0160_ifix.140409.epkg.Z

To install the ifix, run the following:

# emgr -X -e 0160_ifix.140409.epkg.Z

If you need to uninstall the iFix for some reason, run the following command as root:

# emgr -r -L 0160_ifix.140409.epkg.Z

The following is more information, updated on June 13, 2014:

IBM has released several new levels for OpenSSL that address both the Heartbleed bug, as well as several other security vulnerabilities that have been identified recently.

We currently recommend downloading OpenSSL 1.0.1.511. This level can be used on AIX 5.3, 6.1 and 7.1. You can find OpenSSL in the IBM Web Download Pack at:

http://www-03.ibm.com/systems/power/software/aix/expansionpack/

Click on Downloads (on the right), log in with your IBM user ID (or register for one, if you don't already have an IBM user ID). Select openssl on the next page, and click on Continue at the bottom. Click Submit to accept IBM's privacy statement on the next page, and you'll be forwarded to a list of possible downloads. Here, click on "Download using http", and select the OpenSSL images for openssl-1.0.1.511.tar.Z. You probably also want to review the Readme beneath it as well.

You will download the openssl-1.0.1.511.tar.Z file. Transfer that onto your AIX systems into a separate folder.

Uncompress the file:

# gzip -d openssl-1.0.1.511.tar.Z

Now you will have a tar file.

Un-tar it:

# tar xf openssl-1.0.1.511.tar

That will give you folder openssl-1.0.1.511 within your current folder. Go into that folder:

# cd openssl-1.0.1.511

Here you can find 3 filesets; run inutoc to generate the .toc file:

# ls
openssl.base       openssl.license    openssl.man.en_US
# inutoc .

Then install the filesets:

# update_all -d . -cY

Now, it should be installed. Before logging out, make sure you can access your system through ssh using a separate window.

For more information, see http://heartbleed.com. Please ensure your UNIX Health Check level is up to date. Version 14.04.10 and up includes a check for your AIX systems to see if any are impacted by the Heartbleed bug.

On Linux, you sometimes may run into an issue where you can't change permissions of a file, even though you're root, and you have access. For example:

# ls -asl authorized_keys
8 -rw------- 1 root root 6325 Sep 17 02:48 authorized_keys
# chmod 700 authorized_keys
chmod: changing permissions of `authorized_keys': Operation not 
permitted
# whoami
root

This is usually caused by the Extendef File System Attributes, especially if package e2fsprogs is installed. Two commands that will come in handy here are /usr/bin/chattr and /usr/bin/lsattr.

The most common attributes are:

• A - When the file is accessed the atime record is not modified. This avoids a certain amount of disk I/O.
• a - When this file is opened, it is opened in append only mode for writing.
• i - This file cannot be modified, renamed or deleted.

For example:

# lsattr authorized_keys
----i-------- authorized_keys

This shows that the immutable flag (i) is in place on the file, and thus the reason why the file can't be modified. To remove it, use chattr:

# chattr -i authorized_keys
# lsattr authorized_keys
------------- authorized_keys

Now any commands to modify the file, will work:

# chmod 700 authorized_keys

An interesting open source project is Expect. It's a tool that can be used to automate interactive applications.

You can download the RPM for Expect can be downloaded from http://www.perzl.org/aix/index.php?n=Main.Expect, and the home page for Expect is http://www.nist.gov/el/msid/expect.cfm.

A very interesting tool that is part of the Expect RPM is "mkpasswd". It is a little Tcl script that uses Expect to work with the passwd program to generate a random password and set it immediately. A somewhat adjusted version of "mkpasswd" can be downloaded here. The adjusted version of mkpasswd will generate a random password for a user, with a length of 8 characters (the maximum password length by default for AIX), if you run for example:

# /usr/local/bin/mkpasswd username
sXRk1wd3

To see the interactive work performed by Expect for mkpasswd, use the -v option:

# /usr/local/bin/mkpasswd -v username
spawn /bin/passwd username
Changing password for "username"
username's New password:
Enter the new password again:
password for username is s8qh1qWZ

By using mkpasswd, you'll never have to come up with a random password yourself again, and it will prevent Unix system admins from assigning new passwords to accounts that are easily guessible, such as "changeme", or "abc1234".

Now, what if you would want to let "other" users (non-root users) to run this utility, and at the same time prevent them from resetting the password of user root?

Let's say you want user pete to be able to reset other user's passwords. Add the following entries to the /etc/sudoers file by running visudo:

# visudo

Cmnd_Alias MKPASSWD = /usr/local/bin/mkpasswd, \
                      ! /usr/local/bin/mkpasswd root
pete ALL=(ALL) NOPASSWD:MKPASSWD

This will allow pete to run the /usr/local/bin/mkpasswd utility, which he can use to reset passwords.

First, to check what he can run, use the "sudo -l" command:

# su - pete
$ sudo -l
User pete may run the following commands on this host:
(ALL) NOPASSWD: /usr/local/bin/mkpasswd, !/usr/local/bin/mkpasswd root

Then, an attempt, using pete's account, to reset another user's password (which is successful):

$ sudo /usr/local/bin/mkpasswd mark
oe09'ySMj

Then another attempt, to reset the root password (which fails):

$ sudo /usr/local/bin/mkpasswd root
Sorry, user pete is not allowed to execute 
'/usr/local/bin/mkpasswd root' as root.

Since the files involved in the following procedure are flat ASCII files and their format has not changed from V4 to V5, the users can be migrated between systems running the same or different versions of AIX (for example, from V4 to V5).

Files that can be copied over:

• /etc/group
• /etc/passwd
• /etc/security/group
• /etc/security/limits
• /etc/security/passwd
• /etc/security/.ids
• /etc/security/environ
• /etc/security/.profile

NOTE: Edit the passwd file so the root entry is as follows:

root:!:0:0::/:/usr/bin/ksh

When you copy the /etc/passwd and /etc/group files, make sure they contain at least a minimum set of essential user and group definitions.

Listed specifically as users are the following:
root, daemon, bin, sys, adm, uucp, guest, nobody, lpd

Listed specifically as groups are the following:
system, staff, bin, sys, adm, uucp, mail, security, cron, printq, audit, ecs, nobody, usr

If the bos.compat.links fileset is installed, you can copy the /etc/security/mkuser.defaults file over. If it is not installed, the file is located as mkuser.default in the /usr/lib/security directory. If you copy over mkuser.defaults, changes must be made to the stanzas. Replace group with pgrp, and program with shell. A proper stanza should look like the following:

    user: 
            pgrp = staff 
            groups = staff 
            shell = /usr/bin/ksh 
            home = /home/$USER 

The following files may also be copied over, as long as the AIX version in the new machine is the same:

• /etc/security/login.cfg
• /etc/security/user

NOTE: If you decide to copy these two files, open the /etc/security/user file and make sure that variables such as tty, registry, auth1 and so forth are set properly with the new machine. Otherwise, do not copy these two files, and just add all the user stanzas to the new created files in the new machine.

Once the files are moved over, execute the following:

# usrck -t ALL 
# pwdck -t ALL 
# grpck -t ALL 

This will clear up any discrepancies (such as uucp not having an entry in /etc/security/passwd). Ideally this should be run on the source system before copying over the files as well as after porting these files to the new system.

NOTE: It is possible to find user ID conflicts when migrating users from older versions of AIX to newer versions. AIX has added new user IDs in different release cycles. These are reserved IDs and should not be deleted. If your old user IDs conflict with the newer AIX system user IDs, it is advised that you assign new user IDs to these older IDs.

From: http://www-01.ibm.com/support/docview.wss?uid=isg3T1000231

If you try to estabilish a dsh session with a remote node sometimes you may get an error message like this:

# dsh -n server date
server.domain.com: Host key verification failed.
dsh:  2617-009 server.domain.com remote shell had exit code 255

Connecting with ssh works well with key authentication:

# ssh server

The difference between the two connections is that the dsh uses the FQDN, and the FQDN needs to be added to the known_hosts file for SSH. Therefore you must make an ssh connection first with FQDN to the host:

# ssh server.domain.com date
The authenticity of host server.domain.com can't be established.
RSA key fingerprint is 1b:b1:89:c0:63:d5:f1:f1:41:fa:38:14:d8:60:ce.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added server.domain.com (RSA) 
to the list of known hosts.
Tue Sep  6 11:56:34 EDT 2011

Now try to use dsh again, and you'll see it will work:

# dsh -n server date
server.domain.com: Tue Sep  6 11:56:38 EDT 2011

You can restrict a certain user account to only access a single folder. This is handled by file /etc/ftpaccess.ctl. There's a manual page available within AIX on file ftpaccess.ctl:

# man ftpaccess.ctl

In general, file /etc/ftpusers controls which accounts are allowed to FTP to a server. So, if this file exists, you will have to add the account to this file.

Here's an example of what you would set in the ftpaccess.ctl if you wanted user ftp to have login to /home/ftp. The user will be able to change directory forward, but not outside this directory. Also, when user ftp logs in and runs pwd it will show only "/" and not "/home/ftp".

# cat /etc/ftpaccess.ctl
useronly: ftp

If the user is required to write files to the server with specific access, for example, read and write access for user, group and others, then this can be accomplished by the user itself by running the FTP command:

ftp> site umask 111
200 UMASK set to 111 (was 027)
ftp> site umask
200 Current UMASK is 111

To further restrict the FTP account to a server, especially for accounts that are only used for FTP purposes, make sure to disable login and remote login for the account via smitty user.