Gaining file accessibility in an integrated environment doesn’t mean you give up authentication, permissions, or accountability. These products and approaches make it happen.

Mix It Up: Security in an NT/Unix Enterprise

Gaining file accessibility in an integrated environment doesn’t mean you give up authentication, permissions, or accountability. These products and approaches make it happen.

• By Roberta Bragg
• May 01, 1999

Windows NT is about as related to Unix as I am to Bill Clinton. (My mother was an innocent country girl, my father a Klingon.) Nevertheless, like any fledgling, NT’s parentage is rooted in the past. Its developers brought with them a vast and varied heritage and attempted to combine the best of what went before with visions for a more perfect OS.

At first look, Unix aficionados find familiar utilities (such as telnet, rsh, rcp, FTP, and TCP/IP). But they’re often frustrated with the lack of comprehensive command line management utilities and the differences in file system permissions. Microsoft has claimed strengths in these perceived weaknesses: “Without a Telnet server you’re protected…” NT purists who stumble into Unix will point to the lack of unity in Unix, the lack of richness in its file permissions, and the obtuse nature of its command set. But, finally, NT is not Unix and Unix is not NT. Our job isn’t to judge; it’s to make these systems play well together. And we mustn’t sacrifice security to do so. In fact, that’s the true quandary here.

Utilities abound for allowing NT clients to access NFS volumes (Microsoft’s NT Services for Unix Add-On Pack is just the latest ) or Unix clients to access Microsoft’s SMB volumes (such as Samba, covered in Jeremy Allison's May cover article, “Integrating NT and Linux through Samba,” or AT&T’s Advanced Server for Unix). Several utilities extend the command structure of NT with Unix-like commands. (Yes, you too can sit at your terminal and type long command strings to control your enterprise!)

So how do you permit access without violating the security structure imposed by either system? In order to allow that access, we often relax the security structure of one or both.

Let’s begin our quest by looking at areas where security is imposed differently by the two systems and how current utilities for integration handle the translation of NT security to Unix or vice versa. For lack of space, I’m limiting the discussion to step one: file accessibility. This lets us look into interoperability along three fronts: authentication, file access ( permissions), and accountability. I’ll leave a discussion of all those utilities that reach across the boundaries and provide system administration (changing Access Control Lists or ACLs, remotely running commands, and the like) to another time. Finally, keeping with the spirit of cooperation, not obfuscation, I’ll make some recommendations for imposing security on the whole concern.

Remember that any discussion of security between Unix and NT is limited and hampered by the fact that there is no single Unix. Each Unix vendor has made “improvements” to the operating system, which may make it act differently than described below. Review the specifications of your flavor of Unix before rolling up your sleeves.

Authentication: I Yam Who I Yam

Before users on either system can access a file, they must first prove they have access to the system and then be authenticated by the system. Authentication by both systems is based on user ID and password. While other utilities exist to add increased security to this process (Crypto API for NT, Kerberos for Unix, and hardware-based encryption and authentication for both), both systems rely on a simple scheme, something the user knows.

When a user logs onto NT, user ID and password credentials are checked against a database. The username/password information doesn’t pass openly over the network. NT’s database includes encrypted passwords. The usual implementation of Unix places user IDs and passwords in a text file. Each implementation may encrypt the passwords in a unique way. The file is usually hidden. Required password strength, length, and history can be implemented for greater security. In both systems, what’s actually implemented depends on the administrator, system capabilities, and company security policy.

NT’s authentication information is integrated into overall security; a trusted path is established with the OS, and an access token is returned. This token contains three bits of information: the security identification (SID) of the user, the SIDs of any groups that the user is a member of, and additional user rights or privileges. NT uses this information to determine if the user has access to resources and special privileges. Application programming interfaces (APIs) exist to provide native abilities to create new and stronger authentication systems. You can implement authentication at the logical group level (domain), which then provides central authorization. In other words, a central authority controls resource access.

Unix works differently. You accomplish authentication by username and password, but there’s no standard way of integrating overall security and architecture. Applications may rely on Telnet and FTP, which uses passwords sent in the clear. Some vendors offer secure Unix authentication servers. Other implementations may use the Kerberos system for distributed authentication. Authentication isn’t inherently integrated into the OS and must be also installed in and integrated into client systems. Mechanisms exist to group hosts (computers) into trusted systems where authentication by one host allows access to others. System access is controlled by each host in the group. That is, once I’m authenticated on one host, the other hosts will trust me.

Managing initial accessibility in a mixed NT/Unix environment may become the first point of compromise. Should authentication be set via Unix Network Information Services or NT domain? (NIS is an unsecured directory services program that allows you to move data across an enterprise. It can be used for name resolution.) Some utilities, such as Samba, can be configured to authenticate Windows users via either the Unix /etc/passwd file or by an NT domain controller. Windows 2000 provides support for Kerberos; thus centralization for Unix and NT authentication may be easier. Samba can also be configured to use the smbpasswd file for authentication of NT users. The NT encrypted passwords are downloaded using pwdump and stored in the smbpasswd file. The file is then used for authentication without accessing an NT domain controller. (I’m horrified; aren’t you?) The user is authenticated, but no information on global group membership, account restrictions, or other information is supplied.

File Access: Keeping out the Riffraff

Unix controls file access with file permissions. Permission bits for each file provide a fixed granularity for user (owner), group, and other. User perm bits define read, write, and execute (rwx) for the owner. Group perm bits define rwx for the group and other perm bits define rwx for anyone else. For example, the standard system default protections for newly created files on one popular proprietary Unix system is:

-rw -r -r

The owner has read and write permission; group and other permission is read. These permissions may be changed, but there’s no allowance for varied, multiple group access control. It’s as if your ACL could only have three rules; the owner would have one, a single group could have another, and one would be applied for the group Everyone. The single group used would be defined by the administrator, and this is the only way to specify permissions for more than one user.

There’s no default way to give users system privileges. These are assigned to the root, or superuser. The administrator can build privileges. Therefore, many Unix implementations include the ability to allow users to assume limited administrative abilities; but there’s no uniform way of doing so. Nor are there uniform definitions that cross all Unix implementations. The administrator can use the setuid command to assume the identity of another user while executing a file. An application can become privileged and is then privileged, no matter who uses it.

NT allows both object-specific permission and system-wide user rights. Access control under NT is based on object permission. You access objects and implement permissions through the file system. Discretionary access controls, by definition, allow the owner of an object to set and change the access controls. Each user and each group has a SID. You can apply user rights to groups and implement “role”-based access control. Permissions to perform functions on objects (such as NTFS files, shares, and printers) are stored in ACLs. These lists aren’t fixed in size. An owner can specify very comprehensive lists, which finely control the object’s use. Further, each group ACL has one or more access control entries, or ACEs. The ACE indicates the SID (user or group) to which it applies. It includes a set of permissions, including read, write, and execute; change permissions; take ownership; and delete. In addition, user rights give privileges for specific purposes. They’re bound to the user name at login and can be changed only if a user is granted the privilege. No application run by a typical user can alter the security settings.

Each OS uses different file system protocols for accessing remote directories. NT uses Server Message Block (SMB). Unix has traditionally used NFS; Network File System is a facility that allows file systems on foreign hosts to be shared locally. Both file system protocols handle authentication differently. NFS is connectionless. Each NFS request includes a User ID (UID) and Group IDs (GID) of the user. The client typically looks up the UID and SID. SMB is session-based, which means the identity of the client can only be determined once, at login. The server determines the SIDs at login.

So, in a mixed NT and Unix network, which operating system controls the assignment of file permissions? And how are NT ACLs converted to Unix permissions and vice versa—if at all?

Among Unix systems, three scenarios typically play out:

• There may be no attempt to map file level security between NFS and SMB (or its later specification, Common Internet File System, CIFS).
• Support may be present for checking both ACLs and Unix perms.
• Or, user IDs may simply be mapped to Unix UIDs, making Unix perms the only method of access control.

Not surprisingly, both Samba and AS/U (AT&T’s Advanced Server for Unix) use the Unix file system as the arbiter of access. They both attempt to replace NT as a PDC in the NT domain.

Network Appliance, Inc., which publishes Windows Networking Software, uses a different model of implementing access from both CIFS and NFS. Files reside in a central area and can be accessed by either type of host. Each sees the file resource as existing in its native structure. Thus, NT accesses both CIFS and NFS files but thinks it’s accessing CIFS; Unix accesses both CIFS and NTFS files but thinks it’s accessing NFS.

Accountability: Whodunnit?

No matter how secure you think your system is, someday, somewhere, someone will breach that security. Auditing helps you figure out what happened and establishes accountability. So you have to evaluate your system’s abilities to assign responsibility and how well it can make decisions based on the information it gains.

NT binds a SID to uniquely identify a user to each process; the SID is therefore part of the audit record. Accountability can be maintained across client/server interactions.

Unix binds a UID to identify a user on the host to process or action. The use of UIDs can be expanded to a group of hosts by using NIS, making it possible to audit across a distributed client/server application. Mind you, the application doesn’t require this strong accountability, but merely trusts the client machine. Its authentication is subject to spoofing.

Intrusion detection products use the OS audit trail as a basis for analysis. If you have a strong audit trail, then you can derive a detailed and reliable analysis. NT logs events and can be configured to log security-related events at both the system and object level, including but not limited to file and object access, use of user rights, user and group management, and policy changes.

Unix logs authentication-related events but in event-specific files (sulog, utmp, wtmp, and loginlog on many systems). Generic syslog login focuses on error logging, but not for security purposes. Of course, vendor-specific packages can provide auditing features every bit as comprehensive as—and some will claim, superior to—NT.

Next month I’ll explain what opportunities present themselves to you for protecting mixed NT/Unix environments.Plus, I’ll tell you about a product that lets your server respond to users the right way, whether they’re on NT or Unix clients.