The NT security allows a process to allow or deny access of different kind to `objects'. `Objects' are files, processes, threads, semaphores, etc.

The main data structure of NT security is the `security descriptor' (SD) structure. It explains the permissions, that are granted (or denied) to an object and contains information, that is related to so called `security identifiers' (SID).

A SID is a unique identifier for users, groups and domains. SIDs are comparable to UNIX UIDs and GIDs, but are more complicated because they are unique across networks. Example:

SID of a system `foo':

  S-1-5-21-165875785-1005667432-441284377

SID of a user `johndoe' of the system `foo':

  S-1-5-21-165875785-1005667432-441284377-1023

The above example shows the convention for printing SIDs. The leading `S' should show that it is a SID. The next number is a version number which is always 1. The next number is the so called `top-level authority' that identifies the source that issued the SID.

While each system in a NT network has it's own SID, the situation is modified in NT domains: The SID of the domain controller is the base SID for each domain user. If an NT user has one account as domain user and another account on his local machine, these accounts are under any circumstances DIFFERENT, regardless of the usage of the same user name and password!

SID of a domain `bar':

  S-1-5-21-186985262-1144665072-740312968

SID of a user `johndoe' in the domain `bar':

  S-1-5-21-186985262-1144665072-740312968-1207

The last part of the SID, the so called `relative identifier' (RID), is by default used as UID and/or GID under Cygwin. As the name and the above example implies, this id is unique only relative to one system or domain.

Note, that it's possible that a user has the same RID on two different systems. The resulting SIDs are nevertheless different, so the SIDs are representing different users in an NT network.

There is a big difference between UNIX IDs and NT SIDs: the existence of the so called `well known groups'. For example UNIX has no GID for the group of `all users'. NT has an SID for them, called `Everyone' in the English versions. The SIDs of well-known groups are not unique across an NT network but their meanings are unmistakable. Examples of well-known groups:

everyone                        S-1-1-0
creator/owner                   S-1-3-0
batch process (via `at')        S-1-5-3
authenticated users             S-1-5-11
system                          S-1-5-18

The last important group of SIDs are the `predefined groups'. This groups are used mainly on systems outside of domains to simplify the administration of user permissions. The corresponding SIDs are not unique across the network so they are interpreted only locally:

administrators                  S-1-5-32-544
users                           S-1-5-32-545
guests                          S-1-5-32-546
...

Now, how are permissions given to objects? A process may assign an SD to the object. The SD of an object consists of three parts:

UNIX is able to create three different permissions, the permissions for the owner, for the group and for the world. In contrast the ACL has a potentially infinite number of members. Every member is a so called `access control element' (ACE). An ACE contains three parts:

The two important types of ACEs are the `access allowed ACE' and the `access denied ACE'. The ntsec functionality only used `access allowed ACEs' up to Cygwin version 1.1.0. Later versions also use `access denied ACEs' to reflect the UNIX permissions as well as possible.

The possible permissions on objects are more detailed than in UNIX. For example, the permission to delete an object is different from the write permission.

With the aforementioned method NT is able to grant or revoke permissions to objects in a far more specific way. But what about cygwin? In a POSIX environment it would be fine to have the security behavior of a POSIX system. The NT security model is MOSTLY able to reproduce the POSIX model. The ntsec method tries to do this in cygwin.

You ask "Mostly? Why mostly???" Because there's a leak in the NT model. I will describe that in detail in chapter 5.

Creating explicit object security is not that easy so you will often see only two simple variations in use:

For parameters to functions that create or open securable objects another data structure is used, the `security attributes' (SA). This structure contains an SD and a flag that specifies whether the returned handle to the object is inherited to child processes or not. This property is not important for ntsec so in this document the difference between SDs and SAs is ignored.

Any process started under control of Cygwin has a semaphore attached to it, that is used for signaling purposes. The creation of this semaphore can be found in sigproc.cc, function `getsem'. The first parameter to the function call `CreateSemaphore' is an SA. Without ntsec this SA assigns default security to the semaphore. There is a simple disadvantage: Only the owner of the process may send signals to it. Or, in other words, if the owner of the process is not a member of the administrators' group, no administrator may kill the process! This is especially annoying, if processes are started via service manager.

Ntsec now assigns an SA to the process control semaphore, that has each permission set for the user of the process, for the administrators' group and for `system', which is a synonym for the operating system itself. The creation of this SA is done by the function `sec_user', that can be found in `shared.cc'. Each member of the administrators' group is now allowed to send signals to any process created in Cygwin, regardless of the process owner.

Moreover, each process now has the appropriate security settings, when it is started via `CreateProcess'. You will find this in function `spawn_guts' in module `spawn.cc'. The security settings for starting a process in another user context have to add the SID of the new user, too. In the case of the `CreateProcessAsUser' call, sec_user creates an SA with an additional entry for the sid of the new user.

If ntsec is turned on, file permissions are set as in UNIX. An SD is assigned to the file containing the owner and group and ACEs for the owner, the group and `Everyone'.

The complete settings of UNIX like permissions can be found in the file `security.cc'. The two functions `get_nt_attribute' and `set_nt_attribute' are the main code. The reading and writing of the SDs is done by the functions `read_sd' and `write_sd'. `write_sd' uses the function `BackupRead' instead of the simpler function `SetFileSecurity' because the latter is unable to set owners different from the caller.

If you are creating a file `foo' outside of Cygwin, you will see something like the following on ls -ln:

If your login is member of the administrators' group:

  rwxrwxrwx 1  544  513  ... foo

if not:

  rwxrwxrwx 1  1000  513  ... foo

Note the user and group IDs. 544 is the UID of the administrators' group. This is a `feature' :-P of WinNT. If you are a member of the administrators' group, every file that you create is owned by the administrators' group, instead of by you.

The second example shows the UID of the first user, that has been created with NT's the user administration tool. The users and groups are sequentially numbered, starting with 1000. Users and groups are using the same numbering scheme, so a user and a group don't share the same ID.

In both examples the GID 513 is of special interest. This GID is a well known group with different naming in local systems and domains. Outside of domains the group is named 'None' (`Kein' in German, `Aucun' in French, etc.), in domains it is named 'Domain Users'. Unfortunately, the group `None' is never shown in the user admin tool outside of domains! This is very confusing but this seems to have no negative consequences.

To work correctly, ntsec depends on the files /etc/passwd and /etc/group. In Cygwin release 1.0 the names and the IDs must correspond to the appropriate NT IDs! The IDs used in Cygwin are the RID of the NT SID, as mentioned earlier. A SID of e.g. the user `corinna' on my NT workstation:

  S-1-5-21-165875785-1005667432-441284377-1000

Note the last number: It's the RID 1000, Cygwin's UID.

Unfortunately, workstations and servers outside of domains are not able to set primary groups! In these cases, where there is no correlation of users to primary groups, NT returns 513 (None) as primary group, regardless of the membership to existing local groups.

When using mkpasswd -l -g on such systems, you have to change the primary group by hand if `None' as primary group is not what you want (and I'm sure, it's not what you want!)

Look at the following examples, which were parts of my files before storing SIDs in /etc/passwd and /etc/group had been introduced (See next chapter for details). With the exception of my personal user entry, all entries are well known entries.

everyone:*:0:0:::
system:*:18:18:::
administrator::500:544::/home/root:/bin/bash
guest:*:501:546:::
administrators:*:544:544::/home/root:
corinna::1000:547:Corinna Vinschen:/home/corinna:/bin/tcsh

everyone::0:
system::18:
none::513:
administrators::544:
users::545:
guests::546:
powerusers::547:

As you can see, I changed my primary group membership from 513 (None) to 547 (powerusers). So all files I created inside of Cygwin were now owned by the powerusers group instead of None. This is the way I liked it.

Groups may be mentioned in the passwd file, too. This has two advantages:

The group `system' is the aforementioned synonym for the operating system itself and is normally the owner of processes that are started through service manager. The same is true for files that are created by processes, which are started through service manager.

In Cygwin release 1.1 a new technique of using the /etc/passwd and /etc/group was introduced.

Both files may now contain SIDs of users and groups. They are saved in the last field of pw_gecos in /etc/passwd and in the gr_passwd field in /etc/group.

This has the following advantages:

The tools mkpasswd and mkgroup create the needed entries by default. If you don't want that you can use the options -s or --no-sids. I suggest not to do this since ntsec works better when having the SIDs available.

Please note that the pw_gecos field in /etc/passwd is defined as a comma separated list. The SID has to be the last field!

As aforementioned you are able to use Cygwin account names different from the NT account names. If you want to login through `telnet' or something else you have to use the special login. You may then add another field to pw_gecos which contains the NT user name including it's domain. So you are able to login as each domain user. The syntax is easy: Just add an entry of the form U-ntdomain\ntusername to the pw_gecos field. Note that the SID must still remain the last field in pw_gecos!

the_king::1:1:Elvis Presley,U-STILLHERE\elvis,S-1-5-21-1234-5678-9012-1000:/bin/sh

For a local user just drop the domain:

the_king::1:1:Elvis Presley,U-elvis,S-1-5-21-1234-5678-9012-1000:/bin/sh

In either case the password of the user is taken from the NT user database, NOT from the passwd file!

As in the previous chapter I give my personal /etc/passwd and /etc/group as examples. Please note that I've changed these files heavily! There's no need to change them that way, it's just for testing purposes and... for fun.

root:*:0:0:Administrators group,S-1-5-32-544::
SYSTEM:*:18:18:,S-1-5-18:/home/system:/bin/bash
admin:*:500:513:,S-1-5-21-1844237615-436374069-1060284298-500:/home/Administrator:/bin/bash
corinna:*:100:0:Corinna Vinschen,S-1-5-21-1844237615-436374069-1060284298-1003:/home/corinna:/bin/tcsh
Guest:*:501:546:,S-1-5-21-1844237615-436374069-1060284298-501:/home/Guest:/bin/bash

root:S-1-5-32-544:0:
local:S-1-2-0:2:
network:S-1-5-2:3:
interactive:S-1-5-4:4:
authenticatedusers:S-1-5-11:5:
SYSTEM:S-1-5-18:18:
local_svc:S-1-5-19:19:
netwrk_svc:S-1-5-20:20:
none:S-1-5-21-1844237615-436374069-1060284298-513:513:
bckup_op:S-1-5-32-551:551:
guests:S-1-5-32-546:546:
pwrusers:S-1-5-32-547:547:
replicator:S-1-5-32-552:552:
users:S-1-5-32-545:545:

If you want to do similar changes to your files, please do that only if you're feeling comfortably with the concepts. Otherwise don't be surprised if some stuff doesn't work anymore. If you screwed up things, revert to files created by mkpasswd and mkgroup. Especially don't change the UID or the name of user SYSTEM. Even if that works mostly, some Cygwin applications running as local service under that account could suddenly start behaving strangely.

Now its time to point out the leak in the NT permissions. The official documentation explains in short the following:

Note that the last rule is a preference, not a law. NT will correctly deal with the ACL regardless of the sequence order. The second rule is not modified to get the ACEs in the preferred order.

Unfortunately the security tab of the NT4 explorer is completely unable to deal with access denied ACEs while the explorer of W2K rearranges the order of the ACEs before you can read them. Thank God, the sort order remains unchanged if one presses the Cancel button.

You still ask "Where is the leak?" NT ACLs are unable to reflect each possible combination of POSIX permissions. Example:

rw-r-xrw-

1st try:

UserAllow:   110
GroupAllow:  101
OthersAllow: 110

Hmm, because of the accumulation of allow rights the user may execute because the group may execute.

2st try:

UserDeny:    001
GroupAllow:  101
OthersAllow: 110

Now the user may read and write but not execute. Better? No! Unfortunately the group may write now because others may write.

3rd try:

UserDeny:    001
GroupDeny:   010
GroupAllow:  001
OthersAllow: 110

Now the group may not write as intended but unfortunately the user may not write anymore, either. How should this problem be solved? According to the official rules a UserAllow has to follow the GroupDeny but it's easy to see that this can never be solved that way.

The only chance:

UserDeny:    001
UserAllow:   010
GroupDeny:   010
GroupAllow:  001
OthersAllow: 110

Again: This works for both, NT4 and W2K. Only the GUIs aren't able to deal with that order.

For dealing with ACLs Cygwin now has the ACL API as it's implemented in newer versions of Solaris. The new data structure for a single ACL entry (ACE in NT terminology) is defined in sys/acl.h as:

typedef struct acl {
  int     a_type;  /* entry type */
  uid_t   a_id;    /* UID | GID */
  mode_t  a_perm;  /* permissions */
} aclent_t;

The a_perm member of the aclent_t type contains only the bits for read, write and execute as in the file mode. If e.g. read permission is granted, all read bits (S_IRUSR, S_IRGRP, S_IROTH) are set. CLASS_OBJ or MASK ACL entries are not fully implemented yet.

The new API calls are

acl(2), facl(2)
aclcheck(3),
aclsort(3),
acltomode(3), aclfrommode(3),
acltopbits(3), aclfrompbits(3),
acltotext(3), aclfromtext(3)

Like in Solaris, Cygwin has two new commands for working with ACLs on the command line: getfacl and setfacl.

Online man pages for the aforementioned commands and API calls can be found on http://docs.sun.com

UNIX applications which have to switch the user context are using the setuid and seteuid calls which are not part of the Windows API. Nevertheless these calls are supported under Windows NT/W2K since Cygwin release 1.1.3. Because of the nature of NT security an application which needs the ability has to be patched, though.

NT uses so-called `access tokens' to identify a user and it's permissions. To switch the user context the application has to request such an `access token'. This is typically done by calling the NT API function LogonUser. The access token is returned and either used in ImpersonateLoggedOnUser to change user context of the current process or in CreateProcessAsUser to change user context of a spawned child process. An important restriction is that the application using LogonUser must have special permissions:

"Act as part of the operating system"
"Replace process level token"
"Increase quotas"

Note that administrators do not have all these user rights set by default.

Two new Cygwin calls are introduced to support porting setuid applications with a minimum of effort. You only give Cygwin the right access token and then you can call seteuid or setuid as usual in POSIX applications. The call to sexec is not needed anymore. Porting a setuid application is illustrated by a short example:

/* First include all needed cygwin stuff. */
#ifdef __CYGWIN__
#include <windows.h>
#include <sys/cygwin.h>
/* Use the following define to determine the Windows version */
#define is_winnt        (GetVersion() < 0x80000000)
#endif

[...]

  struct passwd *user_pwd_entry = getpwnam (username);
  char *cleartext_password = getpass ("Password:");

[...]

#ifdef __CYGWIN__
  /* Patch the typical password test. */
  if (is_winnt)
    {
      HANDLE token;

      /* Try to get the access token from NT. */
      token = cygwin_logon_user (user_pwd_entry, cleartext_password);
      if (token == INVALID_HANDLE_VALUE)
         error_exit;
      /* Inform Cygwin about the new impersonation token.
         Cygwin is able now, to switch to that user context by
         setuid or seteuid calls. */
      cygwin_set_impersonation_token (token);
    }
  else
#endif /* CYGWIN */
    /* Use standard method for W9X as well. */
    hashed_password = crypt (cleartext_password, salt);
    if (!user_pwd_entry ||
        strcmp (hashed_password, user_pwd_entry->pw_password))
      error_exit;

[...]

  /* Everything else remains the same! */

  setegid (user_pwd_entry->pw_gid);
  seteuid (user_pwd_entry->pw_uid);
  execl ("/bin/sh", ...);

The new Cygwin call to retrieve an access token is defined as follows:

#include <windows.h>
#include <sys/cygwin.h>

HANDLE
cygwin_logon_user (struct passwd *pw, const char *cleartext_password)

You can call that function as often as you want for different user logons and remember the access tokens for further calls to the second function.

#include <windows.h>
#include <sys/cygwin.h>

void
cygwin_set_impersonation_token (HANDLE hToken);

is the call to inform Cygwin about the user context to which further calls to setuid/seteuid should switch to. While you always need the correct access token to do a setuid/seteuid to another user's context, you are always able to use setuid/seteuid to return to your own user context by giving your own uid as parameter.

If you have remembered several access tokens from calls to cygwin_logon_user you can switch to different user contexts by observing the following order:

  cygwin_set_impersonation_token (user1_token);
  seteuid (user1_uid);

[...]

  seteuid (own_uid);
  cygwin_set_impersonation_token (user2_token);
  seteuid (user2_uid);

[...]

  seteuid (own_uid);
  cygwin_set_impersonation_token (user1_token);
  seteuid (user1_uid);

etc.

Since Cygwin release 1.3.3, applications that are members of the Administrators group and have the Create a token object, Replace a process level token and Increase Quota user rights can switch user context without giving a password by just calling the usual setuid, seteuid, setgid and setegid functions.

On NT and Windows 2000 the SYSTEM user has these privileges and can run services such as sshd. However, on Windows 2003 SYSTEM lacks the Create a token object right, so it is necessary to create a special user with all the necessary rights, as well as Logon as a service, to run such services. For security reasons this user should be denied the rights to logon interactively or over the network. All this is done by configuration scripts such as ssh-host-config.

An important restriction of this method is that a process started without a password cannot access network shares which require authentication. This also applies to subprocesses which switched user context without a password. Therefore, when using ssh or rsh without a password, it is typically not possible to access network drives.

If the current user is not present in /etc/passwd, that user's user id is set to a special value of 400. The user name for the current user will always be shown correctly. If another user (or a Windows group, treated as a user) is not present in /etc/passwd, the user id of that user will have a special value of -1 (which would be shown by ls as 65535). The user name shown in this case will be '????????'.

If the current user is not present in /etc/passwd, that user's login group id is set to a special value of 401. If another user is not present in /etc/passwd, that user's login group id is set to a special value of -1. If the user is present in /etc/passwd, but that user's group is not in /etc/group and is not the login group of that user, the group id is set to a special value of -1. The name of this group (id -1) will be shown as '????????'. In releases of Cygwin before 1.3.20, the group id 401 had a group name 'None'. Since Cygwin release 1.3.20, the group id 401 is shown as 'mkpasswd', indicating the command that should be run to alleviate the situation.

Also, since Cygwin release 1.3.20, if the current user is present in /etc/passwd, but that user's login group is not present in /etc/group, the group name will be shown as 'mkgroup', again indicating the appropriate command.

To summarize:

Note that, since the special user and group names are just indicators, nothing prevents you from actually having a user named `mkpasswd' in /etc/passwd (or a group named `mkgroup' in /etc/group). If you do that, however, be aware of the possible confusion.