Appendix: Interpreting File Access Permissions
Unexpected changes in a file or directory's access permissions can be indicative of an attack or intrusion. Halo displays the permissions for a changed file integrity target in a scan's event details, and also indicates whether the permissions themselves have changed. You can examine the permissions to determine whether a change to them is suspicious.
Every file and directory on a Linux system is owned by a user and by a group. Permissions for accessing that file are defined separately for the user, for the group, and for all others. "Other" is defined as a user that is not the owning user and is not a member of the owning group.
Linux supports three types of access permission:
- read. For a file, the ability to open it and read its contents. For a directory, the ability to list its contents.
- write. For a file, the ability to modify it (write new data to it). For a directory, the ability to add, remove, or rename files within the directory.
- execute. For a file, the ability to execute it as a program or script. For a directory, the ability to make it the current directory (as with the
cdshell command), and the ability to access files within it.
Halo displays a Linux file or directory's permissions using the symbolic mode common to shell displays, with three sets of three single character symbols, specifying the permissions of the owner, group, and others, respectively. For example:
In this example, the user owner has full permissions on the file, the owning group can read and execute the file but not modify it, and others can open and read the file, but not modify or execute it.
Special Linux permissions. The above permissions string can include several additions or substitutions in special cases:
- Directory. If the file is a directory, the permissions string may be prefixed with d. For example:
- setuid /setgid bit. If the executable file's setuid or setgid bit is set (meaning that the file will execute as the user owner or group owner, with the owner's permissions), s or S is substituted for r in in the "User" or "Group" permission. For example:
- Sticky bit. If a directory's sticky bit is set (meaning that no users except the directory's owner and the superuser can rename or delete files within the directory), t or T is is substituted for x in the "Others" (all users) permission. For example:
Windows Access Control Entries
All Windows securable objects such as files and registry keys have security descriptors, which allow the system to determine whether access should be granted to the object. A security descriptor identifies the object's owner and contains, among other things, a discretionary access control list (ACL).
The ACL is an ordered list of zero or more access control entries (ACEs). Each ACE specifies the type of access being addressed (allow, deny, audit), includes inheritance flags, identifies the principal (user or group) for whom this access is specified, and contains an access mask that lists the operations that are allowed or denied to that principal. The access mask is represented as a 32 bit string; each bit location in the access mask represents a specific type of permission for the object.
In file-integrity scan details, Halo represents an object's ACL as a sequence of text lines, one for each ACE—that is, one for each principal with defined permissions on the object. In each ACE, Halo replaces the non-human-readable ACE bit mask with a series of multi-character codes specifying the permission details:
These are values you might see for each of the ACE elements:
- Principal. This is the name of the user or group owner, preceded by a scope designation. The scope may be NT AUTHORITY, BUILTIN, the local domain (machine name), or Active Directory/LDAP domain.
For local user accounts where the scope is the machine name, Halo replaces the machine name with "Local" so that events will not be created when local accounts on different machines differ only by the machine name.
- Inheritance. The inheritance strings can have these values and meanings:
- OI. Object inherit (applies only to folders and non-leaf registry keys)
- CI. Container inherit (applies only to folders and non-leaf registry keys)
- IO. Inherit only (applies only to folders and non-leaf registry keys)
- NP. Do not propagate the inherit (applies only to folders and non-leaf registry keys)
- I. Access control is inherited from parent container
It is also possible for a file object to have no inheritance designation in its ACE.
- Type. The type of the access control entry can be either Allow or Deny.
- Permissions. The following are the rights that can appear in the permissions string in the Halo Portal. Note that Halo displays only "specific rights," not the "simple rights" groupings that you may find using icacls or a similar tool.
File or folder:
- AD. Append data/add subdirectory
- AS. Access system security
- DC. Delete child
- DE. Delete
- GA. Generic all
- GE. Generic execute
- GR. Generic read
- GW. Generic write
- MA. Maximum allowed
- RA. Read attributes
- RC. Read control
- RD. Read data/list directory
- REA. Read extended attributes
- S. Synchronize
- WA. Write attributes
- WD. Write data/add file
- WDAC. Write DAC
- WEA. Write extended attributes
- WO. Write owner
- X. Execute/traverse
- CC. Create child
- CR. Control access
- DC. Delete child
- DT. Delete tree
- KA. Key all
- KR. Key read
- KW. Key write
- KX. Key execute
- LC. List children
- LO. List object
- RC. Read control
- RP. Read property
- SD. Standard delete
- SW. Self write
- WD. Write DAC
- WO. Write owner
- WP. Write property
Interpreting Colored Elements in a File Integrity Issue or Event
In the more details display of a file integrity issue or event, colors indicate the nature of changed elements:
- Any file signature or critical metadata value that does not match the baseline is highlighted in red.
- Items that have been removed since the baseline scan are highlighted in red and lined-through.
- Items that have been added since the baseline scan are highlighted in green.
Note that if permissions are added to or removed from a Windows object, the Permissions field in scan details may display other items twice—once in lined-through red and once in green. This occurs because Halo examines the list in order from the top, and only items that have not changed in content or position remain black (unhighlighted) in the scanned object details. Any item whose position has shifted will appear twice, in green at its new position and in red at its old position.
For example, in the scan details above, the first item in the list ("local\R9:...") was in the baseline scan but was replaced on this server with a different permission ("Local\QA:...") before the most recent scan. The remaining 3 items did not change their content or position in the list, so they remain black. The added item appears underlined in green at its appropriate point in the list, and the removed item appears after the list, lined-through in red.
In another example of scan details (above), the first item in the list ("local\R9:...") was in the baseline scan but was removed from this server before the most recent scan. The remaining 3 items have changed position—what was item two is now item one, and so on. Therefore the entire original list appears to have been removed (and is lined-through in red), and the server's entire current list appears to have been added (and is underlined in green).