Archive for October, 2009

SBDavid

Enabling Password Aging

Enabling Password Aging

The following example shows how password expiration can be setup for individual user accounts.

The following files and parameters in the table are used when a new account is created with the useradd command. These settings are recorded for each user account in the /etc/shadow file.

Therefore, make sure to configure the following parameters before you create any user accounts using the useradd command:

$ cat login.defs |grep PASS_

# PASS_MAX_DAYS Maximum number of days a password may be used.
# PASS_MIN_DAYS Minimum number of days allowed between password changes.
# PASS_WARN_AGE Number of days warning given before a password expires.
PASS_MAX_DAYS 99999
PASS_MIN_DAYS 0
PASS_WARN_AGE 7
#PASS_CHANGE_TRIES
#PASS_ALWAYS_WARN
#PASS_MIN_LEN
#PASS_MAX_LEN

Also check - /etc/default/useradd

# The number of days after a password expires until the account
# is permanently disabled
# INACTIVE=-1
#
# The default expire date
# EXPIRE=

When a user account is created using the useradd command, the parameters listed in the above table are recorded in the /etc/shadow file in the following fields

[username]:[password]:[date]:PASS_MIN_DAYS:PASS_MAX_DAYS:PASS_WARN_AGE:INACTIVE:EXPIRE:

To create a new user account you can execute the following command:

useradd -c “centos” -g users test

To get password expiration information:

$ chage -l centos

Last password change : Aug 31, 2009
Password expires : never
Password inactive : never
Account expires : never
Minimum number of days between password change : 0
Maximum number of days between password change : 99999
Number of days of warning before password expires : 7

SBDavid

Checking for Unlocked Accounts

Checking for Unlocked Accounts

It is important that all system and vendor accounts that are not used for logins are locked.

To get a list of unlocked accounts on your system, you can check for accounts that do NOT have an encrypted password string starting with “!” or “*” in the /etc/shadow file. If you lock an account using passwd -l, it will put a ‘!!’ in front of the encrypted password, effectively disabling the password.

If you lock an account using usermod -L, it will put a ‘!’ in front of the encrypted password. Many system and shared accounts are usually locked by default by having a ‘*’ or ‘!!’ in the password field which renders the encrypted password into an invalid string.

~$ sudo egrep -v ‘.*:\*|:\!’ /etc/shadow | awk -F: ‘{print $1}’
root
buddies
nagios

Also make sure all accounts have a ‘x’ in the password field in /etc/passwd. The following command lists all accounts that do not have a ‘x’ in the password field:

# grep -v ‘:x:’ /etc/passwd

A ‘x’ in the password fields means that the password has been shadowed, i.e. the encrypted password has to be looked up in the /etc/shadow file. If the password field in /etc/passwd is empty, then the system will not lookup the shadow file and it will not prompt the user for a password at the login prompt.

All system or vendor accounts that are not being used by users, applications, by the system or by daemons should be removed from the system. You can use the following command to find out if there are any files owned by a specific account:

# find / -path /proc -prune -o -user [account] -ls

The -prune option in this example is used to skip the /proc filesystem. If you are sure that an account can be deleted, you can remove the account using the following command:

# userdel -r [account]

Locate world-writable files and directories

To locate world-writable files and directories, you can use the following command

find / -path /proc -prune -o -perm -2 ! -type l -ls

World-writable files are a security risk since it allows anyone to modify them. Additionally, world-writable directories allow anyone to add or delete files.

The “! -type l” parameter skips all symbolic links since symbolic links are always world-writable. However, this is not a problem as long as the target of the link is not world-writable, which is checked by the above find command.

World-Writable directories with sticky bit such as the /tmp directory do not allow anyone except the owner of a file to delete or modify it in this directory. The sticky bit makes files stick to the user who created it and it prevents other users from deleting and renaming the files. Therefore, depending on the purpose of the directory world-writable directories with sticky are usually not an issue. An example is the /tmp directory:

~$ ls -ld /tmp

drwxrwxrwt 8 root root 4096 Oct 26 05:19 /tmp

From the find man pages:

-type c

File is of type c:

l symbolic link; this is never true if the -L option or the -follow option is in effect, unless the symbolic link is broken. If you want to search for symbolic links when -L is in effect, use -xtype.

SBDavid

SUID & SGID File Security

SUID/SGID File Security

SUID/SGID bits can be misused when the SUID/SGID executable has a security hole.

SUID stands for set user id. When a SUID file executed, the process which runs it is granted access to system resources based on the user who owns the file and not the user who created the process. When a file is SUID root it allows a program/script to perform functions that regular users are not allowed to do themselves. Many buffer overflow exploits are the result of SUID programs.

SGID stands for set group id. When looking at files SGID they behave much the same as SUID files, and must be executable for it to have any effect. The SGID bit on a directory means files created in that directory will have their group set to the directory’s group.

When the SUID (set user ID) or SGID (set group ID) bits are set on an executable, it executes with the UID or GID of the owner of the executable rather than that of the person executing it. This means that e.g. all executables that have the SUID bit set and are owned by root are executed with the UID of root. A good example is the passwd command that allows ordinary users to update the password field in the /etc/shadow file which is owned by root.

But SUID/SGID bits can be misused when the SUID/SGID executable has a security hole. Therefore, you might want to search the entire system for SUID/SGID executables and document it.

To search the entire system for SUID or SGID files, you can run the following command:

find / -path /proc -prune -o -type f -perm +6000 -ls

The -prune option in this example is used to skip the /proc filesystem.

For example, to skip the directory `src/emacs’ and all files and directories under it, and print the names of the other files found, do something like this:

find . -path ./src/emacs -prune -o -print

-prune True; if the file is a directory, do not descend into it.

Ensure that code developers don’t set SUID/SGID bits on their programs if it’s not an absolute requirement. Very often you can use workarounds like removing just the executable bit for world/others. However, a better approach is to change the design of the software if possible.

SBDavid

Directory Permissions

Directory Permissions

If you want to prevent other users from reading the contents of your files, you have two choices:

You can set the permission of each file to 0600, so only you have read/write access.

You can put the files in a directory and set the permission of that directory to 0700, which prevents other users from accessing the files in the directory (or in any of the directory’s subdirectories) unless there is a link to the file from somewhere else.

Note the following:

You must have execute access for a directory to make it your current directory (via cd or chdir) or to change to any directory beneath (contained in) that directory.

If you do not have execute access to a directory, you cannot access the files within that directory, even if you own them.

0755 / Anybody can view the contents of the directory, but only the owner or superuser can make changes.

1777 /tmp Any user can create a file in the directory, but a user cannot delete another user’s files.

0700 $HOME A user can access the contents of his home directory, but nobody else can.

« Prev - Next »