ServerBuddies Support Blog

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.

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:

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:

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:

Locate world-writable files and directories

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

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:

From the find man pages:

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:

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:

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.

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.

Checking File Permissions and Ownership for Security

A simple way to calculate umask values is to remember that the number 2 in the umask turns off write permission, while 7 turns off read, write, and execute permission.

The umask (UNIX shorthand for “user file-creation mode mask”) is a four-digit octal number that UNIX uses to determine the file permission for newly created files. Every process has its own umask, inherited from its parent process.

The umask specifies the permissions you do not want given by default to newly created files and directories. umask works by doing a bitwise AND with the bitwise complement of the umask. Bits that are set in the umask correspond to permissions that are not automatically assigned to newly created files.

The most common umask values are 022, 027, and 077. A umask value of 022 lets the owner both read and write all newly created files, but everybody else can only read them:

A umask value of 077 lets only the file’s owner read all newly created files:

A recent trend among computing centers has been to set up new accounts with a umask of 077, so a user’s files will, by default, be unreadable by anyone else on the system unless the user makes a conscious choice to make them readable.