View
232
Download
0
Category
Preview:
Citation preview
CE01000-3 Operating Systems
Lecture 18
Windows – NT File System (NTFS)
Overview of lecture
In this lecture we will look at: NT File System (NTFS) Encrypting File System (EFS)
Windows structure overview
USER APPLICATION SYSTEM SYSTEM SUBSYSTEM DLL ENVIRONMENT SUBSYSTEM SUPPORT SERVICES
NTDLL.DLL USER MODE
KERNEL MODE EXECUTIVE
API
I/O MANAGER
CACHE MANAGER
PROCESS & THREAD MANAGER
SECURITY REFERENCE MONITOR
VIRTUAL MEMORY MANAGER
Win32 USER and GDI (Graphics engine)
FILE SYSTEMS
PLUG & PLAY MANAGER
POWER MANAGER
CONFIGUARION MANAGER
OBJECT MANAGER /
LOCAL PROCEDURE CALL
Graphics drivers
DEVICE
DRIVERS KERNEL
HARDWARE ABSTRACTION LAYER (HAL)
File systems in Windows
in Windows the file system is part of the I/O system.
the I/O manager provides device independent I/O facilities, in our case
Either the file manipulation facilities that are independent of the hardware of the physical device the file data is stored on
or the type of the file system that is used to organise the way the file data is held on the physical device.
File systems in Windows (Cont.)
to achieve this the software that controls the physical hardware and any file systems must be separate from the I/O manager
physical devices which hold file data e.g. disks, DVDs, pen drives, etc. will have device drivers that form part of the I/O system
File systems in Windows (Cont.)
the file system is implemented by a file system driver - in this case the file system driver will use the backing store device drivers when it wishes to access the physical devices.
Windows processes can access files from different file systems provided an appropriate file system driver exists e.g. Dos FAT file system, NT File System, Posix (Unix) file system, etc.
Representation of files in Windows
files in Windows are considered objects i.e. they are resources for which the object manager holds a representation that is an object
a process that is accessing a file will have a file handle (as a data structure or an object, depending upon the language of the processes source code)
Representation of files in Windows
the file handle will contain an index into the object handle table
the object handle contains the reference to file object
the file object contains a set of attributes and services
Representation of files in Windows
Process
Object handletable
File objectFilehandle
File systemspecificdata structures
Representation of files in Windows (Cont.)
the attributes include file name, but also info on current location in file for next read/write operation, type of device file resides on, etc.
the services include file creation, deletion, read, write, get file info, set file info, etc.
file object also contains a reference to file system specific data structures that provide the mapping between the logical file object and the physical file data on the hardware device e.g. disk
Layered file system driver and disk device driver
Environment subsystem or DLL
User mode
Kernel mode
Executive API
I/Omanager
File systemdriver
Device driver
disk
2
3
4
5
1
writing to disk via file system driver and disk driver
1. write data at specified byte offset within file
2. translate file-relative byte offset into disk relative byte offset and call next driver
3. call driver to write data at disk relative byte offset
4. translate disk relative byte offset into physical location
5. transfer data
Files, sectors, and clusters - reminder
File data is held on disk is broken up into smaller units. Smallest unit of data on disk is the data held by 1 physically formatted sector (segment of a track) - often 512 bytes in size (but this can be Operating System specific).
NTFS organise disk manipulation in terms of a consecutive sequence of sectors on a disk called a cluster (this is not true of all Operating Systems)
Files, sectors, and clusters (Cont.)
File data is held on disk in 1 or more clusters. These clusters may not be consecutive but may be spread all over the disk.
The problem for the file system is to be able to retrieve the sequence of file data from these scattered locations
Clusters and files - reminder
sector = formatted segment of track typically 512 bytes per sector
Cluster is sequence of sectors (often 4/8 sectors depending on disk size)
File is sequence of clusters (not necessarily consecutive)
Sectors
Logical Cluster Numbers
NTFS refers to disk locations via a Logical Cluster Number (LCN)
numbers are assigned to all clusters in disk volume from 0 to N (number of clusters in volume - 1)
this number is LCN these LCNs are mapped onto physical
cluster locations by storage media device driver
Virtual Cluster Numbers
NTFS refers to locations within a file by a Virtual Cluster Number (VCN)
numbers are assigned to all clusters that make up the file from 0 (file start) to M (number of clusters in file - 1)
the clusters that make up the file may not be contiguous
NTFS maps from VCN for a file onto LCN
Indexing of blocks in NTFS
NTFS locates files on disks using index blocks (Unix uses a similar index block method)
File object contains a reference to File Control Block (1 per file) and this in turn contains a file reference number
file reference numbers identify a record (by providing an index) in the Master File Table
Master File Table (MFT) is a file of file records - with usually 1 record per file in the file system
Master File Table (Cont.)
Process
object handletable
File objectFilehandle
File control block
Master FileTable
Record in Master File Table (MFT) contains: standard file information such as time stamps,
whether read-only, etc. Filename security descriptor - file ownership and access
permissions file data attribute field (for data files) or file
indexing attribute field (for directories) data is treated as just another attribute of a file
Master File Table (Cont.)
file info file namesecurity
infoDATA
SMALL FILE
For very small files data is actually contained in data attribute field of MFT record
Master File Table (Cont.)
Master File Table (Cont.)
LARGE FILE
file info file namesecurity
infofile data run references
DATA
DATA
DATAVCN 0
LCN 134
VCN 1
LCN 135
VCN 2
LCN 213
Master File Table (Cont.)
For larger files (most files) data attribute field contains a series of references to file data runs
a file data run is a cluster that contains the actual file data
For even larger files the MFT record will contain a reference to another MFT record entry that contains further file data run references in its data attribute field i.e. the MFT records can become chained together to represent massive files
Directory file indexes
in NTFS directories are represented by entries in MFT
MFT contains an entry for the root directory of the NTFS file system volume
for directories files are identified by file indexes
file indexes contain file reference numbers (effectively an index into MFT), plus file name, time stamp info and file size for file
file info file namesecurity
infofile-index1....
file-indexN
SMALL DIRECTORY
in a directory record in MFT then instead of data attribute field there are indexing attribute fields
For small directories files within directory are identified by a series of file indexes held in indexing attribute field
Directories
Directories (Cont.)
file info file namesecurity
infofile index buffer
references
file-indexN+M+1.... file-indexZ
file-indexN+1.... file-indexN+M
file-index1.... file-indexN
LARGE DIRECTORY
Directories (Cont.)
For larger directories indexing attribute field contains a series of references to file index buffers
a file index buffer is a cluster that contains the series of file indexes for the files within that directory
Encryption – simple explanation
Encryption is a mechanism by which you can transform the content of a file into something that appears meaningless by applying an algorithm to change the data (decryption restores original meaningful file content)
The precise way in which the data is changed can be made to depend upon a key value (which is a parameter to the encryption algorithm)
if the encryption algorithm is a good one you can only decrypt the file (get the original content back) if you have the key.
Hence important to have a key that is kept secure and is hard to guess
Encrypting File System
To provide additional levels of security the NTFS provides an encryption & decryption service known as the Encrypting File System (EFS)
Using this a user can encrypt/decrypt specific individual files or whole directories (and sub-directories)
EFS was a separate file system driver in Windows 2000, but in XP onwards has been integrated into NTFS itself
Encryption process
When encrypting a file Windows generates a random key FEK (File Encryption Key)
Windows uses an industry standard encryption algorithm AES (Advanced Encryption Standard) or 3DES (Triple Data Encryption Standard)
These are symmetric key encryption algorithms that are suitable for encrypting large amounts of data
Encryption keys
Windows stores the FEK as part of the file it has encrypted – so how to stop someone decrypting the file by using the FEK that is held as part of the file?
Windows encrypts the FEK itself using RSA an asymmetric key algorithm – these are only suitable for encrypting small amounts of data (which the FEK is)
RSA uses a public key in its encryption/and a separate private key in decryption
Encryption keys (Cont.)
Anyone who has the private key can decrypt the FEK – so Windows needs to keep that private key safe
Windows stores the private key that is used for decryption in a subdirectory of the user profile directory and encrypts all the keys and files in that subdirectory using a AES/3DES using a master key
But how do we keep the master key safe?
Encryption keys (Cont.)
Master key is also stored with the user profile information and encrypted in turn by a key that is based on the user password
This key is constructed at logon and held in the OS address space (i.e. in main memory) – ready to be used – but not written to the disk
Encryption keys (Cont.) Problem is – master key is only as good as
the user password i.e. you might be able to guess the password (based on information you know about the person) or try out different keys (a key search) but rather than trying all possible keys (takes too long) you try likely keys (based on likely passwords, e.g. dictionary words/names, etc)
So maybe not as secure as it seems
References
Operating System Concepts. Chapter 22.
Recommended