Download Report

ACL, ACE … Permission… How to handle security?
Nowadays, security concerns are increasing in all industry companies and research institutes.
We need to control who is accessing the information and when it is accessible. Windows provides a built-in way for
accessing information and checking user privileges to know who should be able to access a document/folder or not.
Knowing how to manage permission when you are a CERN user is even more important because most of documents you use
are stored on DFS folders that are directly dependant on the Windows Access Control system
This article will first introduce ACL and related notions. We will then present the way Windows handles security on
files/folders and the way to manage them. Then a section will introduce the notion of rights inheritance before evoking the
notion of Owner and its function. Finally a few “typical test cases” will be presented.
SID, Permission, ACE, ACL: barbarous words
To fully understand the permissions concept, some words need clarification.
.
.
.
.
.
1 ACE
SID, Permission
Acess Control Entry
SID, Permission
SID, Permission
1 ACL
Acess control List
This information can be shown by displaying the file/folder
properties (right click on the file) in the Security tab.
In that case “Bruno Lenski” is the SID of the user, the
permissions are listed below and the couple Bruno Lenski
and its permission consist in the ACE.
The ACL are the set of ACE for Bruno Lenski and for
Administrators
SID (Security Identifier): user identity. This is basically the
user login or the group name.
Permission : integer that represent the access given to the
associated SID (read, write, ...)
ACE (Access Control Entry): couple (SID, permission). It
thus represent the access that is given to a user/group
ACL (Access Control List): list of ACE sat on a given file or
folder
The above view of permission is the condensed way
windows displays the permissions on the folder. To display
the full list of permissions, one would have to click on the
Advanced button in the above picture and get to the screen
on the right.
These permissions can be modified by clicking on the Edit
button.
Question to think about before granting permissions?
Before setting permissions on a folder, there are few points to be considered:
•
•
•
Who will have access? Is that a set of user or a single user? (SID, list of SID)
How often do I expect that list of SID to change? (for instance in the case of a newcomer in the group, ...)
What are the rights to be granted for each SID?
To address the first and second point, on should be aware that, permission are set on file/folder level. Adding a new
permission for a single user in a folder is not a trivial task as it implies modifying all ACL. Therefore it is strongly
recommended to user Groups to give access to folder to avoid massive ACL modification for each new user. For example, if
I want to give access to all persons in IT/IS group to a specific folder I should use the group called “Users IT-IS” to set
permissions. Then any newcomer will simply be added to the group and will automatically be given permissions to the set of
folders. Existing groups can be displayed via the win services web page:
https://winservices.web.cern.ch/winservices/Services/GroupManager/GroupManager.aspx
They can also be managed via the e-group application: http:\\e-groups.cern.ch
It is also strongly recommended to give access to resource rather than denying access to it. If a user is granted access then he
will be able to access a resource. If he is not granting access then he will not be able to access. Denying the access (in a
Windows way) is another process that can have side effect (described below) and thus it is strongly recommended not to use
that functionality. (See the examples for more in formations)
List of possible permissions.
There are 13 permissions in Windows whose names are understandable. These permissions are all stated in the table below
all together and in parallel with UNIX permissions:
Permission Types (Unix)
Permission Components
Read (R)
Traverse Folder /
Execute File
List Folder /
Read Data
Read Attributes
Read Extended Attributes
Create Files /
Write Data
Create Folders /
Append Data
Write Attributes
Write (W)
Execute (X)
Delete (D)
Write Extended Attributes
Delete Subfolders and Files
Delete
Read Permissions
Change Permissions
Take Ownership
A few notes about this table:
•
•
Delete Subfolders and Files can be applied as an individual permission to folders.
There is actually a 14th permission component, called Synchronize. This permission is used to control
synchronization of access to file or folder handles for multithreaded applications.
Ownership and permission assignment
Every file and folder has an owner, which is a user identified as being the one who controls it. By default, the user who
creates a file or folder becomes its owner. The significance of ownership is that the owner of a file or folder always has the
ability to assign permissions for that object. The owner can decide what permissions should be applied to the object,
controlling others' access to the file or folder.
The two special permissions that are associated with ownership and permission assignment are "Change Permissions" (P)
and "Take Ownership" (O). If a user is granted the "Change Permissions" permission, the user can change the permission
settings for the object even if he or she does not own it. If a user has "Take Ownership" permission, the user has the ability to
take over ownership of the resource, and of course, once it is owned the user can do anything he or she wants with the
permissions.
Note that by default, members of the "Administrators" group can always take ownership, or change permissions on, any file
or folder. This allows Administrators to fix permission problems if they occur. Thus removing/denying permissions to the
Administrator is pointless as these persons can reassign all the rights to themselves if needed
Not allowing administrators to access the data does not make it more secure, instead it puts your data at risk.
Permission inheritance
The notion of inheritance is based on the notion of folder and subfolder. The permission set on a parent folder can be
propagated to all the subfolders it contains. An Administrator or user is though inheritance able to manage a hierarchical tree
of permissions that matches the hierarchical tree of directories. Since each child inherits permissions from its parent, when
you set up a hierarchy of three or more levels of folders, the objects deep within the structure will inherit permissions from
their parent, "grandparent", "great grand-parent" and so on.
In addition to this powerful dynamic inheritance feature, Windows offers several advanced inheritance control features that
give the Administrator more power on how inheritance works:
•
•
Child Protection: The main security properties dialog box for each object contains a check box labelled "Allow
inheritable permissions from parent to propagate to this object". If this check box is cleared, it breaks the normal
inheritance link between this child and its parent (and higher-level ancestors as well). When this is done, the child
will no longer dynamically inherit permissions from higher up in the directory tree. Such a child object is said to
be protected from inheritance changes.
Forced Propagation: An option called "Reset permissions on all child objects and enable propagation of
inheritable permissions" is provided. This works the same way as the "Replace Permissions on Subdirectories" and
"Replace Permissions on Existing Files" options from the older Windows NT static permission model. When
selected, NTFS will force propagation down to all child objects and remove any permission that were directly
assigned to those child objects. This allows Administrators to easily "fix" permission problems in large directory
structures.
Inheritance is thus a powerful tool even though it brings a disadvantage: performance. Inheritance requires more processing
resources to deal with changes to files and folders, and to determine which permissions take over each time access to an
object is attempted...
Permission resolution
Here is the difficult part... How does the system interpret the list of ACL? How permissions are granted... this section might
seems a bit technical but few examples afterwards will try to clarify the situation.
Here is the algorithm used to check whether one has access or not:
1.
2.
3.
4.
"Deny" permissions takes over "allow" permissions.
Permissions applied directly to object take over permissions inherited from a parent object.
Permissions inherited from near relatives take over permissions inherited from distant predecessors. So
permissions inherited from the object's parent folder take precedence over permissions inherited from the object's
"grandparent" folder, and so on.
Permissions from different user groups that are at the same level (in terms of being directly-set or inherited, and in
terms of being "deny" or "allow") are cumulative. So if a user is a member of two groups, one of which has an
"allow" permission of "Read" and the other has an "allow" of "Write", the user will have both read and write
permission--depending on the other rules above, of course. :^)
The system combines these rules into a process that it uses to resolve various permission settings. Since directly-applied
permissions take precedence over inherited ones, and "deny" permissions take precedence over "allow" permissions, it first
looks for directly-set "deny" permissions, combining them all together for all groups the user is a member off. If it finds
sufficient deny permission to refuse access, it is done--the access is refused. Otherwise, it looks at directly-set "allow"
permissions. If it finds sufficient permission to allow access, the access is allowed. If not, it continues on; the sequence is as
follows:
Examples
Here is a set of example to explain the system behaviour.
Let’s assume I am Bruno lenski part of the IT-IS group.
In this example the inheritance of rights are removed from that folder.
Case 1:
If I create a folder in “My document”, it has the following ACL :
•
•
Bruno lenski has full Control
Administrators has full Control
In that case Bruno Lenski and administrators of the cenhome12
machine have access to the folder and its content.
All other persons from IT-IS have no access.
Case 2:
I want my colleagues from IT-IS to access this folder with read
permission. I thus have to add the “User IT-IS” Group to the list of
SID and allow them to have read rights.
Note that these “Read” rights for the user are composed of 3 different
Windows rights :
•
List folder /Read Data
•
Read Attributes
•
Read Extended Attributes
Restraining the right only to “List Folder/Read Attribute” would lead
to have “Special permission” ticked instead of “Read”.
When a user X wants to access the folder, the group member
resolution is done and if he is member of IT-IS group, he is granted
the right.
As Bruno Lenski is member of IT-IS he gets the rights.
Case 3:
Let’s assume that I now want to deny access to all persons from IT-IS
group on that folder. I could apply a deny permission on the read
rights to the IT-IS ACL. This would lead to the following behaviour:
If a user X want to access, the system successfully checks:
•
Is X member of IT-IS, if yes the access is denied.
•
If not, is X = Bruno Lenski, if yes the access is granted
•
If not is he in the cernhome12\Administrator Group
The problem here is that Bruno Lenski is member of IT/IS group
though the first rule gives an access deny. So even if the second rule
grants access, the first rule applies and thus Bruno lenski is NOT
granted access.
Due to this behaviour, we recommend not using deny access.
Instead, simply remove the Read access for the “Users IT-IS” group;
it will give the same result.
Case 4:
Starting back from the status in case 2.
Let’s assume I want people from TE-MSC to have access in read
mode instead of IT-IS. Then I remove the IT-IS entry and add a TEMSC entry with read rights.
Thus if a user X tries to read the repository, the system will
successively check :
•
Is X = Bruno Lenski, if yes he has full control
•
If not, is X member of Users TE-MSC
•
If not is he in the cernhome12\Administrator Group
If all tests fail then the access will not be granted.
Case 5:
Let’s assume now, that I am creating a folder inside that folder. This
folder inherits it the parent folder rights.
Thus the security Tab is showing me the permission in grey.
To remove this inheritance, one should click on “Advanced” to open
the detailed rights window. Then one should click on edit on that
newly opened window and untick :
The system will then ask if the user want to remove all permissions or
copy the current permissions. Let’s assume we remove the
permissions. The folder then has no SID and thus nobody has
permissions on that folder.
Nobody except the owner (person that created this folder) have the
permission to change the permissions. Then I can add myself
permission on that folder
The owner can be displayed by clicking on “Advanced” on the
security tab and browse “Owner” tab
Note that the machine Administrator can always take ownership and
thus give himself rights afterwards for maintenance reasons.
I can then add access to myself as having full control on the folder.
The problem I face then is that I cannot grant access to
Administrators anymore (in our case
CERNHOME12\Administrators) thus, the folder will have backup
problems.
Thus removing all permissions is not good. I should have copied the
permissions instead of removing the permissions when I was
prompted.