Security

QNX provides mechanisms to control access to resources and critical system functions. These mechanisms are based on the ability of the system to identify a particular user.

When the system boots for the first time (right after the initial installation), you're automatically logged in as the superuser (root). This username allows access to every part of the system and doesn't require a password.

To prevent unauthorized users from accessing the system, you should give root a password. You can create a new user account for yourself that you can use afterwards for your daily work. The passwd utility allows a login password to be changed; you can use the utility to create new usernames for yourself and others.

Access control utilities

The QNX access control utilities are:

• login — sign on to the system
• su — temporarily become another user
• passwd — create and maintain user accounts/change passwords

The login utility

The login utility should be started by tinit on all tty devices. The utility demands a username and password, and verifies them against the user database /etc/passwd before granting access to the system. If the username/password combination is incorrect, login displays a message to that effect and terminates. If the user enters the correct combination, login starts the login Shell and loads that user's environment.

The su utility

The su utility lets you temporarily have the privileges of another user. If a user ID isn't entered on the command line when you start su, the utility prompts for a password that must match the superuser's password. Entering a valid access combination causes su to access the user database /etc/passwd and create a shell that has all the rights and privileges of the assumed user ID. Exiting from the shell returns you to your regular user ID.

The passwd utility

The passwd utility can be used to change passwords or to add a new user account to the system. Anyone can change their own password, but the superuser (root) is the only user who has the right to create new user accounts. In both cases, the passwd utility locks access to the user password file /etc/passwd to prevent any other attempts to access the file while it's being modified.

Before you start creating user IDs, you might want to modify passwd's behavior. The settings in the file /etc/default/passwd determine which local policies will be enforced by passwd, such as the stringency of passwords, user ID ranges, and so on. For more information about the options you can set, see the passwd utility in the Utilities Reference.

A user invokes passwd with his or her own user ID to change the corresponding password. The passwd utility will prompt the user for the required information. When the user is the superuser, the old password isn't requested.

The superuser can add a new account by invoking passwd with a unique user ID. The utility prompts for information that will control the new user's environment, including access privileges. The account permissions to include comprise the user's group ID assignment and file permissions.

For example, to create a new account with the username carol, the superuser would enter:

passwd carol

By default, passwd will then prompt for the following information:

• user ID number
• group ID assignment
• user's real name
• user's home directory
• initial command
• initial password

User ID number

Group ID assignment

docs::124:johno, chrish, eric, stever, rachel

docs::0:
techies::1:
support::2:
marketing::3:
finance::4:

Home directory, initial command, and initial password

Deleting a user account

QNX doesn't provide a direct mechanism for deleting accounts. To delete an account, you must remove the user database entry from the /etc/passwd file, the username from the corresponding group ID assignment entry in the /etc/group file, and the corresponding encoded login password entry from /etc/shadow file.

More about user and group IDs

Upon logging in, a user is assigned two pieces of information:

• a user ID
• a group ID

These are known as the user's real user ID and real group ID.

The user ID should be unique — no two users should share the same user ID. This rule can be enforced by the passwd utility, but the superuser can override the rule by editing the password file directly.

The group ID allows several users to be associated with a group. This group mechanism lets a team of users share resources without making those resources available to the rest of the world. For more information about the /etc/group file and its contents, see the newgrp utility in the Utilities Reference.

Effective user and group IDs

Processes have two classes of user and group IDs: real and effective. When a process is created, it automatically inherits these four IDs from its parent (which is typically the login Shell):

• real user ID
• real group ID
• effective user ID
• effective group ID

The effective user and group IDs are used for permission checking. A process can change its effective user or group ID, or both, so that they differ from their real counterparts. Typically, this is done to gain access to resources that aren't available to the real user and group IDs.

For more information on setuid and setgid, see the “File permissions” section.

The newgrp utility

The newgrp utility starts a new Shell with different real and effective group IDs. When invoked without arguments, newgrp switches the group ID to the one identified in the password database for the current user. The password database controls the groups that a particular user may switch to.

File permissions

In QNX, each file has an associated set of permissions called mode bits. These mode bits, in conjunction with the file's owner and group, control access to the file.

When a process creates a file, the process's effective user ID and effective group ID become the file's owner and group. A set of mode bits is also assigned to the file (this is described in the “How mode bits are assigned” section).

There are three classes of mode bits:

• owner
• group
• other

When a process attempts to access the file, the Filesystem Manager honors the appropriate class of mode bits. The Filesystem Manager determines which mode bits to honor by performing a few comparisons in a specific order:

1. The effective user ID of the requesting process is compared to the owner of the file. If they match, the owner mode bits are honored.
2. If the owner comparison fails, the requesting process's effective group ID is compared to the file's group ID. If these group IDs match, the group mode bits are honored.
3. If both the owner and group comparisons fail, the other mode bits are honored.

The file mode bits are stored in the 16-bit st_mode field of the directory entry for the file; access is granted if a mode bit is set.

As the following table shows, permissions affect regular files and directories differently:

Viewing permissions

You can use the ls -l (“el”) command to see a file's permissions, owner, and group. The following ls -l output for the file alpha.c shows that the owner and anyone in the techies group may read and write to the file, while other users may only read it:

-rw-rw-r--  1 rachel   techies   8475 Apr 8  1996 alpha.c

In the following example, the ls -ld output for the directory /bin shows that the owner and group members may read, write, and search the directory, while other users don't have write permissions and therefore can't add any new files to the directory:

drwxrwxr-x  2 root     techies   2048 Sep 19  1990 bin

But note that other users may still list or execute files in /bin.

It's possible — though unusual — to have read permission on a directory but not search permission. For example, ls could work (depending on the options you give it), but you wouldn't be able to access any file in the directory or do a cd to the directory.

How mode bits are assigned

The permissions on a file are derived by combining the current umask of the creating process with that process's requested open()/creat() mode.

The umask is a permission bit mask that indicates which permission bits are to be turned off if a process specifies default permission when a file, directory, or FIFO is created (see umask in the Utilities Reference).

The mask is the logical AND of the mode and the complement of the umask. For example, if the mode requests read-write permission for everyone as follows:

and the umask indicates write permission for group and other:

then the result is read-write permission for the owner, and read permission for everyone else:

Changing permissions

You can change the permissions of a file with the following commands:

setuid and setgid

To perform certain functions, a user must sometimes run a command at a privilege level higher than their own. For example, a user may need to run the passwd utility to modify their own entry in the password database, even though they would normally be denied write access to that database.

Two file mode bits allow a user to run a command at a higher privilege level:

• setuid (set-user-ID)
• setgid (set-group-ID)

With these bits set, an executable file will run with the privileges of its owner and group rather than with the privileges of the process that invokes the file. These mode bits apply only to executable regular files.

When a file is loaded for execution and the setuid mode bit is set, the effective user ID of the new process becomes that of the file's owner. Similarly, if the setgid mode bit is set, the effective group ID becomes that of the file's group.

To close a potential security hole, the setuid and setgid bits are cleared any time the file ownership (owner or group) is changed. This prevents users from writing an executable file to disk, setting the setuid bit, and then changing the ownership of the file to root, thereby gaining unlimited system access.

The passwd, login, su, and newgrp utilities are all setuid to root; these programs therefore run with the permissions of the superuser.

By convention, root is the only user with user ID zero, which yields superuser status. With respect to access control, you must ensure that only programs that can be trusted — and absolutely need to be trusted — are setuid to root. No special privileges are bestowed on a program when it's setgid to root.

The password database

Three files collectively form the password database:

• /etc/passwd
• /etc/shadow
• /etc/group

The access permissions to these files should be set as follows:

/etc/passwd

The /etc/passwd file contains a set of lines in the following format:

username:haspw:userid:group:comment:homedir:shell

where:

/etc/group

The /etc/group file contains lines in the following format:

groupname::group_ID:user_ID[,user_ID]*

where:

/etc/shadow

The /etc/shadow file contains lines in the following format:

user_ID:password:0:0:0

where:

You may notice from the above permission list that /etc/passwd is readable by anyone. This is to provide standard utilities with a simple mechanism to find information about users. Since this file is readable, the encrypted password isn't stored in it.

The encrypted password is stored in the /etc/shadow file, which is readable only by the superuser. This is to inhibit unauthorized attempts to decrypt the passwords. To protect the security of your user community, you should ensure that these permissions are maintained.

QNX is shipped with a default password database that includes /etc/passwd and /etc/group. The /etc/shadow file isn't shipped, because the accounts initially don't have passwords associated with them.

Default password files

The default /etc/passwd file that was shipped with your QNX system contains the following:

root::0:0::/:/bin/sh

The default /etc/group file contains the following:

root::0:root

touch /etc/acclog
chmod g=,o= /etc/acclog

670464500 TS //1/dev/ser1 modem -b 19200 -L
670464545 MO //1/dev/ser1 2400
670464550 LO //1/dev/ser1 100 101 steve
670465824 TS //1/dev/ser1 modem -b 19200 -L

mv /etc/acclog /etc/acclogs/9607
touch /etc/acclog
chmod g=,o= /etc/acclog

mv /etc/acclog /etc/logs/9607
touch /etc/acclog
chmod g=,o= /etc/acclog
freeze /etc/logs/9607