Access control lists provide more security options.
The previous episode described the traditional security model used by Unix computers. This includes Linux and Mac computers as well. It’s a simple model that works really well.
Make sure to listen to the previous episode for more information.
The first time I came across a different system was with Windows NT. This stood for new technology and rewrote a lot of the early DOS-based operating system. Listen to the full episode or read the full transcript below for more details about NTFS security using access control lists (ACL), access control entries (ACE), and security descriptors (SD).
Transcript
The previous episode described the traditional security model used by Unix computers. This includes Linux and Mac computers as well. It’s a simple model that works really well.
But it still requires you to divide everything into three viewpoints. What can the owner do? What can members of a group do? And what can everybody else do? Even the question of what are these things that can or can’t be done comes down to just read, write, and execute.
Make sure to listen to the previous episode for more information.
It’s a lot better than nothing. Early PCs had no concept of security at all. Maybe that’s because they were mainly used by a single person. They were, after all, personal computers.
The first time I came across a different system was with Windows NT. This stood for new technology and rewrote a lot of the early DOS-based operating system. Even when Windows 95 was released, it was really little more than a nice user experience. It was a big step up from Windows 1, 2, and 3 where Windows was started after the computer started up with DOS. The Windows 95 line continued with Windows 98 and then Windows Me. All of these had little in terms of security. The filesystem was based on a system called FAT. The best thing about the FAT filesystem is that it’s old and simple. It has no security at all.
The problem with Windows NT at the time was that it required a lot of memory to install and run. I remember trying to install it on a computer back in the early 1990’s and my computer didn’t have enough memory. It needed 16 MB. That seems tiny compared to today’s computers. But back then, I couldn’t afford a thousand dollars just for some extra memory.
Windows NT 4 came along and computers were beginning to be commonly available and affordable that could run it. But it wasn’t until Windows 2000, and later Windows XP, that personal computers started getting better about security. And even then it wasn’t until Windows XP Service Pack Two that security became a top priority. Microsoft still had consumer oriented operating systems like Windows XP, and server oriented operating systems like Windows 2000 and Windows Server 2003. But they were very similar on the inside because they all came from Windows NT.
Microsoft took Windows NT and kept making it better until it was applicable to personal tasks as well as serving the needs of many people. Once the older DOS based operating system ended with Windows Me, then Microsoft was able to focus on the NT line.
Windows NT from the very beginning had a different security system than traditional Unix. And it took that security system beyond just the file system. Although the file system is where you’ll likely see it used most. Just remember that what you’re learning now is used in other places in Windows. It’s a very flexible system.
Windows NT came with the NT filesystem or NTFS for short. And NTFS security is based on access control lists. The acronym is A C L and is pronounced akal.
As its name implies, an ACL is a list. Each entry in the list is called an access control entry or ACE for short. There can be as many ACEs as you need. And each ACE defines a specific identity and what permissions should be allowed, denied, or audited. The identity is also referred to as a trustee. I know, it sounds like we’re talking about a banking application instead of security. But the word trustee is just a general term that can be used to identify a person, or a group of people, or even other computers and running applications. Don’t worry too much about how this part works. At least for now. The important part is understanding the relationship between ACLs and ACEs.
An ACL is just a list of ACEs and each ACE is used to define a small part of the security of a file or folder. This whole system can be used in many places other than filesystems. But even in filesystems, it existed before Windows NT and it can be found in just about any modern filesystem.
If you’re using Windows, then ACLs are everything. And if you’re using Linux or a Mac, then you can choose to use either the traditional Unix security system or ACLs. Personally, I don’t have a lot of experience with ACLs on Linux or a Mac. I’ve managed to get by just fine with the older system on those computers.
Okay, so let’s dive a little deeper into ACLs. You can already see that they’re more flexible. You’re not limited to just three ACEs and I also mentioned that ACEs can do things like deny access or control when something should be reported to a system administrator through auditing.
Most of my explanation of ACLs will apply to how I understand the system on Windows. But while some things might vary, the concepts should apply broadly.
First of all, Windows defines a securable object to be something that can be controlled with ACLs such as a file or a directory. Each securable object has what’s called a security descriptor or SD for short. Although the abbreviation is normally only used in writing. When referring to a security descriptor, I’ve always said the full name. One of the security descriptor’s jobs is to divide the ACLs into two lists. But the security descriptor also identifies the owner of the object and its primary group. In a way, this is starting to resemble the traditional Unix security system.
It’s with the two access control lists that a security descriptor starts to show its full capability.
The first and most common list is called the discretionary access control list or DACL for short. This list is used to control access. If a security descriptor has no DACL, then it’s the same as the Unix 777, everybody has access with no restrictions. That’s different than a security descriptor that has an empty DACL. An empty DACL is one with no ACEs. This means that nobody is allowed access.
By adding ACEs to the DACL, you can selectively choose who gets access and what they can do. The filesystem will compare what an application wants to do with a securable object with the ACEs in the DACL to determine if the operation should be allowed or not.
Because this is a list of ACEs, the filesystem starts at the beginning and checks each ACE. It might not need to go all the way to the end. Once it either has confirmation that the operation should be allowed or should be denied, then that’s the answer.
This means that the order of the ACEs is important. Let’s say you have a friend at your company named Bob who works in the Sales team. If you have a file with a DACL in its security descriptor that has two ACEs and the first one gives your friend Bob the right to read the file and the second one denies the Sales team from reading the file, then Bob will be able to read the file. The filesystem will stop looking at ACEs once it determines that Bob can read the file and won’t go any further. Now, if somebody else from the sales team tries to read the file, they’ll be denied once the filesystem reaches the denied ACE for the Sales team. And if somebody else entirely tries to read the file, then they’ll also be denied once the filesystem reaches the end of the list and finds nothing granting them the right to read the file.
Now, going back to Bob for a moment. If you reverse the order of the ACEs so that the Sales team is first denied access to read the file and then Bob is granted permission to read the file, then Bob will no longer be able to read the file even though there’s an ACE that gives him this right.
If Bob leaves the Sales team so he’s no longer associated with the Sales group, then he’ll be able to read the file no matter what order the ACEs are found in the example.
You can see how this system gives you much more control over your files and directories. But Windows also allows ACEs to be inherited from parent folders. In the older Unix system, you have to apply the security mode to every file and folder. But with Windows, you can configure a parent folder with a particular security descriptor and have it automatically apply relevant ACEs to child files and folders.
This whole check to determine if access is allowed or not can easily get very complicated especially when multiple groups are involved. It’s never a good idea to try to do this type of check yourself. Let the filesystem make the final determination. If you’re writing an application that needs to provide hints to the user if some operation will be allowed or not, well, there’s not a good answer. You shouldn’t try to determine ahead of time if the user will be allowed to do something or not. At least not completely. You can make a best guess and err on the side of allowing the user to perform the action.
What I mean is let’s say you want to disable a button when you think some user doesn’t have the permission to write to a file. You’re not going to be able to make an accurate determination of this ahead of time in all cases. It’s just too complicated. The only way to be sure is to let the user try to delete the file. If the operation succeeds, then the file is deleted. And if the operation fails, then it’ll be the filesystem that keeps the file around. The worst thing you can do is disable the button because you think the operation would fail. If you can find proof somehow that the user will not be able to delete the file, then fine, go ahead and disable the button. But like the US justice system is innocent until proven guilty, you should let the user have the option to delete the file if you’re unsure.
Alright back to the other half of the security descriptor. Remember there are two lists. There’s another access control list called the system access control list or SACL for short. This is a powerful concept even if it’s not always used. The SACL doesn’t control access like the DACL, but what it does is control when an event should be recorded in the event log. This can alert an administrator that somebody just tried to open a file that they shouldn’t have access to. And it can also make an alert even when access is granted.
You might have an important file and want to know when somebody tries to sneak a peek. But you might also want to know anytime the file is successfully used. It’s a great way to audit your filesystem to know what’s happening, good or bad.