New Technolgy File Systems: NTFS

Now that I’ve covered FAT16 and FAT32 both in excruciating detail, let’s turn our attention to NTFS, the proprietary file system for WinNT. While FAT32 was a decent system, it lacked some of the more advanced features that many businesses need to run a network. Chief among them are file level security, encryption, event logging, error recovery and compression. NTFS (5.0) provides all of these features in a nicely optimized package.

Permissions:

The feature that NT is probably best known for is its file level security. With NTFS permissions, you can control which users have what kind of access to which files. This is a stark contrast to the “security” in Windows 9x, where the system policy editor affords the only measure of protection. Once a knowledgeable user gets past the policy protections, which is only skin deep (or interface deep), every file on the system is his for the taking. In Windows NT, even if you get past the interface lockouts, you’ll still have a hell of a time accessing other people’s files, because they are locked at the file level.

Before I discuss how to set file permissions, we need to take a step back and look quickly at how permissions in general work on Windows NT. Windows NT’s security model is an entire topic onto itself. So I will not cover it in detail here. However, a general overview will prove beneficial.

With Windows NT, you can assign security at two different levels – on a per user basis, and on a group basis. So, if there is a user called Jane who belongs to the Marketing User Group, you can affect Jane’s access permissions by either assigning permissions to her account, or to her group. So what happens if Jane’s group has Modify Access to a document, but Jane is only assigned Read Access? Surprising enough, the least restrictive of the two permission sets takes precedence, in this case, the Modify Access. The one glaring exception is the No Access permission. If a No Access permission is assigned at any level, the user has no access, regardless if any other permissions assigned. So if the Marketing Group is assigned No Access, Jane would have no access even if her account is assigned Full Control.

So there you have it, NT file level security at a glance. There is so much more to it, but as this is an intro article, a more in-depth exploration of NT file security seems more appropriate in a separate article. With that said, let’s take a look at some of the other features of NTFS.

Compression:

Another useful feature is compression. It works transparently (like DriveSpace), and can be assigned to individual files (unlike DriveSpace). To turn on compression for a file, right-click on it and choose Properties. From the Properties menu, you can check the Compressed attribute. The same can be done on a directory.

Encryption:

But what is even more useful is the encrypted file system (EFS) included in NTFS 5.0. With EFS, you can actually encrypt a file, rather than just protect it via permissions. This is a long overdue feature since there are other operating systems on the market which will read files on an NTFS volume while bypassing the NT security. BeOS is one example, one which I have used. Various flavors of Linux might also provide similar functionality, though I have yet to personally encounter one. However, if a file is encrypted, then such dangers are drastically mitigated. NT5’s EFS is a system level service, which means it runs even when all users are logged off. This also prevents hackers from easily disabling the program, as is the case with user mode encryption programs. Moreover, the encryption system works transparently with respect to the user. What that means is that if a user has permissions to decrypt the file, then when the file is being accessed, it will be decrypted seamlessly, without any user intervention. On the other hand, if the user does not have appropriate access, then an “Access Denied” error will pop up.

In principle, EFS works on a public/private key system (via CryptoAPI if you are interested). When a file is encrypted, a file encryption key (FEK) is automatically generated. That randomly generated FEK is used to encrypt the file(or folder). The FEK is then, itself, encrypted using the user’s public key. A list of encrypted FEKs is stored as a part of the file content. When the user tries to access the file, the system will attempt to decrypt the FEK with the user’s private key. If it succeeds, then the decrypted FEK is then used to decrypt the actual file. However, if a file is copied to a non-NTFS partition, then a plaintext version of the file is created.

To activate encryption, simply right-click on a folder and choose Properties from the popup. Then simply check the Encrypt checkbox. By default, Windows Explorer will only allow folders to be encrypted (which is the recommended method). However, the command CIPHER can be used to encrypt on a per file basis. To encrypt:

CIPHER /e myfile.txt

To decrypt:

CIPHER /d myfile.txt

The other nice thing about EFS is that it offers a data recovery mechanism. A data recovery agent is automatically configured. In a Windows 2000 domain, that defaults to the domain admin. The assigned security agent could then decrypt any file that is under his scope. It is important to note that when recovery occurs, only the file’s FEK is revealed, and NOT the user’s public key. This way, it prevents the security agent from accessing files that are not under his scope. As always, the domain admin will have the power to delegate security recovery rights to other user groups as to provide both flexibility and redundancy.