Setuid in Subsystem for UNIX-based Applications

setuid and setgid

Subsystem for UNIX-based Applications and identities

Setup considerations for setuid in Subsystem for UNIX-based Applications

The setuid and setgid mechanisms allow a program, when run, to adopt certain aspects of a security principal other than that of the user running the program. They allow the program to alternate these aspects between those of the invoking user and those of another security principal.

Appropriate privileges are distinct from this. While the setuid and setgid mechanisms allow an application to control the answer to the question: "Who are you?", appropriate privileges answer the question: "What can you do?"

In typical UNIX environments, there is exactly one user to whom all privileges are granted. That user, typically called root, has uid == 0. In Subsystem for UNIX-based Applications, all supported privileges on a given system are granted to users who are members of either the Administrators group or the Domain Administrators group on that system. You do not need to log on as administrator. Any user with membership in either the Administrators group or the Domain Administrators group possesses root privileges. Not all privileges defined in POSIX or UNIX are available in SUA; that is, there are certain privileges that are not granted to any user.

Appropriate privileges are typically required for a variety of actions. These include accessing the file system, sending signals to other processes (process control), or changing the effective user identifier (UID) or group identifier (GID) for a process in order to change the ability of that process to perform certain actions.

According to the POSIX standard, a file has permissions that include bits to set a UID (setuid) and set a GID (setgid). If either or both bits are set on a file, and a process runs that file, the process gains the UID or GID of the file. When used carefully, this mechanism allows a nonprivileged user to run programs that run with the higher privileges of the file's owner or group. When used incorrectly, however, this can present security risks by allowing nonprivileged users to perform actions that should only be performed by an administrator. For this reason, SUA does not support this mechanism by default. Instead, if you attempt to run a file with either the setuid or setgid bit set, SUA does not run the file and returns the error code ENOSETUID.

If you rely on an application that requires standard POSIX behavior, you can configure SUA to run files with the setuid or setgid bits set. If SUA is configured in this way, when a process runs a file that has the setuid or setgid bit set, SUA constructs local security tokens for the process with the privileges assigned to the owner or group of the file. Because the tokens are local, they are not recognized by other computers on the network. This means that, even if the file is owned by a member of the Domain Administrators group, for example, the process does not have trusted access through Microsoft® Windows® networking to other computers in the domain. Instead, the privileges will be effective only on the computer on which the process is running.

For example, a process runs a program file with its setuid bit set and owned by a member of the Domain Administrators group. If that program attempts to change a domain user's password, that attempt will fail because the security tokens of the process are local and so are not recognized by other systems in the domain. If, on the other hand, the program attempts to change a local user's password, the attempt will succeed because the file's owner is a member of the Domain Administrators group, which typically belongs to the local computer's Administrators group. For information about how to configure SUA to run files with the setuid or setgid bits set, see the Help files that ship with the download package Utilities and Software Development Kit (SDK) for UNIX-based Applications.

For the setuid(2), setgid(2), and chroot(2) functions, a process must have the effective UID that maps back to the system account, the administrator account for the local domain, or the administrator account for the principal domain. The local administrator account can only change the UID or GID to another ID in the same domain.

For chown(1), chmod(1), and chgrp(1), an account must have the Windows privileges SE_BACKUP and SE_RESTORE to perform make operations on files owned by another user or group, or to modify permissions on a file owned by another user. These permissions typically belong to the administrator and backup operator accounts.