INFO: Understanding Volume-Level Security on Windows NT

ID: Q150101

The information in this article applies to:

Microsoft Win32 Application Programming Interface (API), used with:
- Microsoft Windows NT versions 3.5, 3.51, 4.0
- Microsoft Windows 2000

SUMMARY

This article describes how volume-level security behaves, and how it differs from the file- and directory-level security provided by the New Technology File System (NTFS).

Microsoft Windows NT provides auditing and access control facilities for physical and logical volumes. Conceptually, volume-level security is designed to control volume-level access, such as formatting operations, rather than file- and directory-level operations. Volume-level security also minimally protects logical volumes that are not formatted with NTFS, such as floppy disks and compact discs.

MORE INFORMATION

Windows NT was designed to have security descriptors applied to volumes control and audit volume-level access such as formatting a disk or reading raw disk sectors. The file system with which the logical volume is formatted is responsible for control and auditing of access to files and directories. Currently, the only file system to support file- and directory- based security is NTFS.

There are two types of volume-level operations that need to be understood: physical drive access and logical volume access. Physical drive access allows Win32-based applications to manage hard disk partition tables and logical volumes. Logical volume access allows Win32-based applications to manage the contents of a partition below the file system level. Logical volume access is most often used to format a partition with a particular file system, such as FAT or NTFS. The following sections explain how volume- level security applies to each type of volume-level access.

Physical Drive Security

Win32-based applications can open handles to physical hard disk drives for low-level access by calling CreateFile() with \\.\PHYSICALDRIVEx, where x is the zero-based physical drive number. Once the applications have a handle, they can use DeviceIoControl() to call IOCTL functions, or ReadFile() and WriteFile() to perform sector reads and writes.

Access to physical drives is a built-in right of the Administrators group and does not need to be enabled. Users who are not members of the Administrators group cannot open physical drives under any circumstances.

Although any member of the Administrators group can enable access control and auditing on physical drives, doing so provides little value for two reasons, the first leading to the second:

Adding access control lists (ACLs) to a physical drive does not control or audit access to the logical volumes on the drive, or to files and directories within those logical volumes. Instead, the ACLs are used to control and audit access to the physical drive itself, such as opening the physical drive with CreateFile() using \\.\PHYSICALDRIVEx.

Because only members of the Administrators group can access physical drives, the only use for an ACL on a physical drive is to control or audit the access that they have. Because members can change the ACLs on physical drives, their access is not truly limited.

Finally, the ACLs applied to physical drives are in effect only until the system is shut down or restarted.

Logical Volume Security

Win32-based applications can open logical volumes with CreateFile() by specifying the file name as \\.\X:, where X is the actual drive letter. Once this is done, the applications can use the handle to issue IOCTL functions or read and write raw sectors.

Specifying access control on a logical volume controls access to the logical volume itself and to all of the files and directories contained by the volume allows Windows NT to provide a basic level of security to media that is not formatted with NTFS, such as floppy disks, compact discs, and hard disk partitions formatted with the FAT file system.

Access controls applied to removable media affect access to the drive, not just to the media that was in the drive when the drive was secured. For example, if users are prevented from accessing A:\, they are not able to use drive A:, no matter which floppy disk is inserted.

Although access control protects a logical volume and all of its contents, auditing only records accesses to the volume itself. Accesses to files and directories within the volume are not recorded. This is analogous to the way NTFS audits directories; only access to the directory itself is audited. Thus, opening a logical volume by specifying \\.\X: as a file name to CreateFile(), causes an entry to be placed in the security event log while opening a file on the same volume does not.

Auditing and access control apply to logical volumes only as long as the system is running. If you want to control access to or audit logical volumes after the machine has been restarted, you must reapply the security.

How to Enable Volume-Level Security

Access control and auditing are enabled by placing access control lists (ACLs) on the volume. The discretionary ACL (DACL) provides access control information, while the system ACL (SACL) provides auditing. To apply ACLs to a volume, create a security descriptor with the desired ACLs, and then use SetFileSecurity() to apply it. SetFileSecurity() can be used on both physical and logical volumes and in addition to files and directories, as follows:

Physical volumes must be specified as a string in the form \\.\PHYSICALDRIVEx, where x is the zero-based drive number.

Logical volumes must be specified as a string in the form \\.\x:, where x is the actual drive letter of the volume.

Additional query words: 3.50 3.51 4.00 NTFS CD-ROM

Keywords : kbAPI kbFileIO kbKernBase kbWinOS2000 kbSecurity kbDSupport kbGrpKernBase
Version : winnt:3.5,3.51,4.0
Platform : winnt
Issue type : kbinfo