Brian Smith's AIX / UNIX / Linux / Open Source blog
Matching: security X
|Modified on by brian_s|
I had a new article published on IBM developerWorks today: Getting started with Nmap for system administrators
AIX stores password hashes under /etc/security/passwd. Each user with a password defined will have a stanza in this file that specifies what the hashed password is.
Here is an example for the root user:
If you would like to transfer a users password from one server to another, you can simply copy the users stanza out of /etc/security/passwd and put it in this same file on the other server (replacing their existing stanza). The user will now be able to login to the other server with whatever their password was set to on the original server.
However, editing /etc/security/passwd directly should make you nervous. If you make a mistake with this file you might prevent anyone from being able to login to the server.
Another option is to get the users password hash out of /etc/security/passwd and then use the "chpasswd" command to change the password on the other server. The chpasswd has a "-e" option that specifies the password is hashed/encrypted rather than cleartext. So with the example given above for the root user, if we were to run this command on the other server it would update the root accounts password to be the same as on the original server:
The "-c" option on chpasswd clears any password flags and prevents the user from being forced to change their password at next login.
WARNING: Don't run the chpasswd command line above (or the others in this article) on your server or you'll change your root password. The password hashes used in this posting are just examples and the password for them all is just the letter "a".
To make this process easier, here is a short script to automate this process:
The script will generate the "chpasswd" command line needed to duplicate the users password on other servers. The script doesn't do anything other than generating the chpasswd command line - you must then take this command line and run it on whatever server(s) you want to copy the users password hash to. If you run this script with a specific user as a argument only that user will have the command line generated. If you don't specify a user, it will generate command lines for all users on the server that have a password stanza.
Here is an example of running it and specifying a user (root in this case). As you can see it just generates a command line - you must then copy and paste this on to each server you want to duplicate the users password on to. When you run the generated command on another server it will change the users password to match whatever password was set on the original server.
If you run the script without any arguments, chpasswd command lines are generated for all users that have a password stanza:
If you would like to learn more about password hashes and how they work, check out this article over at IBM System Magazine: Improve AIX Security With Password Hashes
Check permissions for intermediate directories on Linux/UNIX when troubleshooting permission problems
I've seen several Linux/UNIX system administrators struggle with a scenario like this one:
A user reports to the administrator they are trying to "cd" in to a directory but keep getting permission denied:
$ cd /tmp/level1/level2/level3/level4/level5/level6
As the root user, the administartor checks the permissions on the directory:
# ls -ald /tmp/level1/level2/level3/level4/level5/level6
The administrator see's the permissions are rwxrwxrwx (777) and can't figure out why the user is getting a permission denied message when they try to CD in to the directory.
What is going on here? In order for a user to CD in to any directory on the system, they must also have at least read and execute permissions on EVERY parent directory all the way down to the root of the filesystem (/).
So in the example above the user can't access the directory because they don't have read and execute permissions on one of the parent directories.
An easy way to quickly see all the parent directory permissions is to run this one-liner as root (change the dir= to the directory you would like to check)
When I run this in this example scenario, I get this output:
And I can quickly see the reason the user can't access /tmp/level1/level2/level3/level4/level5/level6 is because the permissions on /tmp/level1/level2/level3 are too restrictive.
brian_s 270002K5X3 Tags:  umask unix aix linux security script scripting 2 Comments 37,287 ViewsModified on by brian_s
The generic read/write/execute UNIX/Linux file permissions are fairly easy to understand. But when you start getting in to the SUID, SGID, and Sticky bits things get more complicated and harder to understand.
For example, if you came across a file with "--S--S--T" permissions would you know what this means? By reading this short posting and referring to the table linked below, you would be able to quickly and easily decipher any possible file permission you might run in to and translate it in to english :)
Here is a little information on how SUID, SGID, and Sticky bits show up when looking at file permissions:
SUID permissions show up as a "s" in the 3rd column of the user permission set (i.e. rwsr-xr-x)
SGID permissions show up as a "s" in the 3rd column of the group permission set (i.e. rwxr-sr-x)
The Sticky bit shows up as a "t" in the 3rd column of the other permission set (i.e. rwxrwxrwt)
If you see a capital "T" in the 3rd column of the other permission set (i.e. rwxrwxrwT), this means that the sticky bit is set, but that there is no execute ("x") permission for others.
If you see a capital "S" in the 3rd column of the user or group permission sets (i.e. rwSr-xr-x or rwxr-Sr-x), it means that the SUID/SGID permission is set, but that the execute bit isn't set (which would kind of defeat the purpose... but it is still possible to set the permissions to this).
There are a total of 4,096 possible ways to set the permissions on a file. I created a table that shows each possible permission with its numeric mode, what the permissions would look like, and then a plain english explanation.
developerWorks wouldn't let me post the permissions table here in the blog because it would put my posting over the size limit, so here is the link: http://ixbrian.com/unixpermissions.html
If you need to edit the sudoers file from a script, you might be tempted to directly edit the file. But like it says at the top of /etc/sudoers - the file must only be edited with the visudo command. This is because visudo validates the syntax before putting the new file in place. Without this syntax validation it is very easy to make a mistake in the file after which sudo no longer works (hopefully at that point you have the root password so you can still access root without sudo :) )
Here is an example of how a line can be added to the /etc/sudoers file from a script while still using the visudo command to ensure the syntax is valid:
The way the script works is when it is run it detects it was run with no parameters, and therefor goes to the "else" part of the code. It sets the EDITOR variable to the name of the script itself ($0), and then calls visudo. visudo runs the "EDITOR" program (in our case this script) with the temporary sudoers file name as a parameter. When the script is run by visudo, it has a parameter so it runs the first section of the "if" statement which echo's a line in to "$1" which is the name of the temporary sudoers file that visudo passed. The script then ends, and visudo validates the syntax and puts the sudoers file in place if no errors were found.
The previous example shows how to add a line, if you want to modify or delete lines you could use the ed editor (for more details on editing files with ed from a script see Script file edits with the "ed" editor. )
Here is an example to change a line in /etc/sudores. In this example, the "root ALL=(ALL) ALL" line is commented out:
Here is an example of deleting a line in /etc/sudoers. In this example, the "root ALL=(ALL) ALL" line is deleted:
|Modified on by brian_s|