QotW: Filesystem Security

May 23, 2011 by . 0 comments

Ultimate Fish Battle Royale

Is NTFS really secure?

I have Mac PC, in which I have created a Windows partition and have installed Windows using Boot Camp. If I log in to the Mac OS, I can read all the files from the Windows partition from Mac. If I compare the same scenario from within Windows, Windows claims to secure a user’s private files (stored in My Documents for instance) from other users with equal or less privilege. I was expecting to see the same protection from Mac as well. I was expecting an error message in Mac to show that these files are inaccessible, if I try to see or open them. Can someone explain if my perception is right or am I missing something?

While the question specifically mentions NTFS the answer applies to almost every file system that is able to be accessed by another operating system and has not had native support for that file system built in.

The same would apply to EXT2/3/4 (Linux) support on Windows, HFS (Mac) support on Linux or any combination of file systems that are standard for one system and just barely “supported” on another.


What this all boils down to is the fact that the file system and operating system security models are very tightly bound and in order to enforce security in the file system the operating system absolutely must know about all the possible security bits that the file system supports and be able to resolve whatever information is provided.

As an example almost every modern file system supports file information such as “Creator”, “Owner” and what permissions apply to each user or group that has access to a particular file and those are stored in what are known as ACLs or “Access Control Lists”.  These lists will not have a full username against every file, and will instead list a “user number” and what permissions that user has.

The file system itself can not know who the current user on the computer is, only that a user number X has permissions to read and write a file while user Y can only read the file.  These user numbers and permissions are then resolved by the operating system which in turn enforces the security of access to the file, either by providing full access, limited access as determined by the ACL or completely denying access.

The problem with support for “guest” file systems (such as NTFS being accessed under Linux) is that they have no easy task of resolving an NTFS user ID to a Linux user ID.  It is potentially possible to find and read where Windows stores its user ID data as long as you have access to the Windows system partition, but then you have to have some way of mating those user IDs with their Linux counterpart which would have to be done by the user themselves.  But what do you do in the event that the system partition is not available, you have no way to find out what all these user numbers mean in the first place and no way to even begin matching them.

So, what do most operating systems do when faced with these problems?  That’s right, they ignore them and give you full access to everything, restricted only by the permissions that have been set up when the file system was mounted.

The best you can say is that your files are secure within the confines of the currently running operating system – most operating systems do not provide security for “guest” file systems.

To a great extent this security issue can actually be helpful, especially when you have a broken Windows install and need to use a Linux LiveCD to recover your data…

Keeping Files Secure

The question then becomes about what you do to keep your files secure if this supposed security vanishes the moment you start using another operating system on your computer and here there is only one real option. As mentioned in the question above the only real way to keep your files secure is to use encryption. There are a number of options here, with varying degrees of usefulness and painfulness.

  • Native user file encryption (such as supported by NTFS)
  • Archive (zip, 7z, rar, etc.) container based encryption
  • Encryption Container (TrueCrypt and similar) based encryption
  • Full partition or disk encryption.

Each one of these options has pros and cons:

Method Pros Cons
OS Native File Encryption
  • Highly transparent to user, can be enabled quickly and easily.
  • Alternate operating systems will have no access to the real file contents without “brute-force” decryption.
  • If the operating system becomes corrupt then the file data is potentially lost as the decryption certificate may be stored in the user profile.
  • If user walks away from the computer without locking it all their encrypted files are accessible.
Archive Based Encryption
  • Easy to recover assuming the password is known.
  • Easy to transfer the file and password to another user.
  • Data has to be temporarily stored before encryption and may be recoverable by other means.
  • Requires decryption when data is to be modified, then re-encryption when finished.
  • If the password is known then all the data is completely accessible.
Encryption Container, Partition or Disk encryption
  • Can be transparent to the user, requiring only a password to access.
  • Can be set to dismount after a period of inactivity, requiring password to be re-entered thus improving security if user walks away from the computer.
  • Can potentially be a large file or disk requiring backup.
  • Difficult to give the entire container to another user if a large size is used.
  • If the password is known then all the data is completely accessible.
  • Requires software support on all operating systems that will access it.

In the long run though whatever options you choose will mean that there are some trade-offs for your security, whether it is recoverability, portability or even having to enter a password before having access to your secure files.  You’ll always have to make a choice about which option suits what you need to do and how secure you need it to be.

Subscribe to comments with RSS.

Comments have been closed for this post