Business
Enhance UNIX system security with access control lists
If you're new to the UNIX operating system, especially if you're familiar with Windows, you'll find that the file access control mechanisms might not be exactly what you expect.
If you're new to the UNIX operating system, especially if you're familiar with Windows, you'll find that the file access control mechanisms might not be exactly what you expect.
File permissions and file access control don't mean the same thing under UNIX, and there are reasons to use both. The old UNIX file permission system is commonly the only method of access control that people use.
The basic file ownership permissions (user, group, and world/other) on UNIX are a bit outdated. You can typically control permissions in UNIX by using commands such as chown, chgrp, and chmod.
The concepts of layered access controls similar to Windows NTFS and the Novell Bindery environment are somewhat new to the UNIX world, considering how long UNIX has been around. This is somewhat ironic, since NetWare borrowed many concepts from UNIX.
In the days before Windows NT, stand-alone PCs technically had no user rights to worry about. But this wasn't the case with most other systems, particularly networked ones. People who used UNIX or VMS in the '80s were already familiar with file system permissions, but PCs were just getting to that point. (In my opinion, the DOS attrib command doesn't count.)
Those who came from a DOS background probably first experienced file access control with Novell NetWare, which was the most popular local area network (LAN) operating system prior to Windows NT. (I'm disregarding Banyan Vines because everyone else seems to, and I never used it.)
Novell expanded on the simple "user, group, world/other" file access control mechanism provided by UNIX, extending permissions to users and groups using an indexed database called the Bindery. But for some reason, it took a while for this concept to trickle back to the UNIX world.
Microsoft didn't miss a beat in developing access controls for Windows NT that matched NetWare and the fine-grained access controls of mainframes. Windows systems using NTFS have considerably better file access control mechanisms than standard UNIX systems, adding modification, renaming, and deletion rights, as well as permissions to change the access control rights themselves.
NTFS has two types of access controls lists (ACLs) for file system management: The discretionary access control list (DACL) specifies access rights to files and directories, and the system access control list (SACL) logs specific access attempts to files or directories. ACLs extend the concepts of file access rights and ownership to allow other users to access files.
Note that access control isn't available on older FAT file systems. If you want file access control on Windows systems, using FAT or FAT32 isn't going to cut it. But you can convert existing FAT partitions to NTFS easily enough.
In UNIX, the basic file permissions are read, write, and execute. Combine these with the user, group, and world/other file ownership rights, and it's easy to see that standard UNIX file systems often don't have adequate access control.
This is why I find a lot of UNIX system administrators simply ignoring permissions and granting everyone with an account unrestricted file access. I've seen entire file systems wiped out by accident due to this practice--not to mention that a simple nonroot exploit will grant someone complete access to world-readable files.
To better secure your UNIX systems, investigate the use of ACLs instead of using world-writable files and directories or fighting with editing group and user files. ACLs are a much better alternative than leaving entire directories on your UNIX server completely unprotected and open to modification by anyone.
Most commercial UNIX operating systems--including SunOS, Lynx, IRIX, and AIX--can use ACLs for fine-grained file access. All have roots in some way or another in the proposed Portable Operating System Interface (POSIX) specifications before POSIX discontinued its work on ACLs. SunOS/Solaris supports ACLs natively, as does AIX.
Free UNIX systems that implement ACLs are also available. Note that in order to use ACLs on UNIX, you may need to use a different file system, apply operating system patches, and rebuild the operating system kernel.
Jonathan Yarden is the senior UNIX system administrator, network security manager, and senior software architect for a regional ISP.
The basic file ownership permissions (user, group, and world/other) on UNIX are a bit outdated. You can typically control permissions in UNIX by using commands such as chown, chgrp, and chmod.
The concepts of layered access controls similar to Windows NTFS and the Novell Bindery environment are somewhat new to the UNIX world, considering how long UNIX has been around. This is somewhat ironic, since NetWare borrowed many concepts from UNIX.
In the days before Windows NT, stand-alone PCs technically had no user rights to worry about. But this wasn't the case with most other systems, particularly networked ones. People who used UNIX or VMS in the '80s were already familiar with file system permissions, but PCs were just getting to that point. (In my opinion, the DOS attrib command doesn't count.)
Those who came from a DOS background probably first experienced file access control with Novell NetWare, which was the most popular local area network (LAN) operating system prior to Windows NT. (I'm disregarding Banyan Vines because everyone else seems to, and I never used it.)
Novell expanded on the simple "user, group, world/other" file access control mechanism provided by UNIX, extending permissions to users and groups using an indexed database called the Bindery. But for some reason, it took a while for this concept to trickle back to the UNIX world.
Microsoft didn't miss a beat in developing access controls for Windows NT that matched NetWare and the fine-grained access controls of mainframes. Windows systems using NTFS have considerably better file access control mechanisms than standard UNIX systems, adding modification, renaming, and deletion rights, as well as permissions to change the access control rights themselves.
NTFS has two types of access controls lists (ACLs) for file system management: The discretionary access control list (DACL) specifies access rights to files and directories, and the system access control list (SACL) logs specific access attempts to files or directories. ACLs extend the concepts of file access rights and ownership to allow other users to access files.
Note that access control isn't available on older FAT file systems. If you want file access control on Windows systems, using FAT or FAT32 isn't going to cut it. But you can convert existing FAT partitions to NTFS easily enough.
In UNIX, the basic file permissions are read, write, and execute. Combine these with the user, group, and world/other file ownership rights, and it's easy to see that standard UNIX file systems often don't have adequate access control.
This is why I find a lot of UNIX system administrators simply ignoring permissions and granting everyone with an account unrestricted file access. I've seen entire file systems wiped out by accident due to this practice--not to mention that a simple nonroot exploit will grant someone complete access to world-readable files.
To better secure your UNIX systems, investigate the use of ACLs instead of using world-writable files and directories or fighting with editing group and user files. ACLs are a much better alternative than leaving entire directories on your UNIX server completely unprotected and open to modification by anyone.
Most commercial UNIX operating systems--including SunOS, Lynx, IRIX, and AIX--can use ACLs for fine-grained file access. All have roots in some way or another in the proposed Portable Operating System Interface (POSIX) specifications before POSIX discontinued its work on ACLs. SunOS/Solaris supports ACLs natively, as does AIX.
Free UNIX systems that implement ACLs are also available. Note that in order to use ACLs on UNIX, you may need to use a different file system, apply operating system patches, and rebuild the operating system kernel.
Jonathan Yarden is the senior UNIX system administrator, network security manager, and senior software architect for a regional ISP.