Now that AppCL LSM is able to label a process with the path of the binary application relating to that process, and label the inode kernel object with permission entries, it must enforce the permissions that are defined in the permission entries.

Essentially it must enforce the ‘READ | WRITE | EXECUTE’ permissions using the Linux Security Module (LSM) framework hooks. The LSM framework supports this through the security hooks that allow access control decisions to be made at key decision making processes within the kernel.

General Permissions

The following security hooks are used to check permissions for an inode object and a file object. Figure 1.0 shows the ‘appcl_lsm_inode_permission’ security hook

appcl_lsm_inode_permission

appcl_lsm_file_permission

The security hook ‘appcl_lsm_inode_permission’ grants general permissions to an inode object based on the requested permission mask. It does this using a series of audit functions.

check_inode_path_match

• checks to see if the current process path matches any permission entry for the current inode. If a permission entry is present then AppCL knows to enforce permissions for that inode.

appcl_check_permission_mask_match

• loops through the permission entries to check if a labelled permission (e_perm) matches the requested permission (mask). If the inode includes a permission entry for the current process, but no matching permission is found, permission is not granted to the inode. Whereas a matching permission label for a process will return a success and the permission will be granted.

Figure 1.0 – ‘appcl_lsm_inode_permission’ security hook

The LSM framework also includes additional hooks for checking permissions. The ‘inode_permission’ and ‘file_permission’ hook do not cover all operations by an inode so additional checks must also be made.

Specific Permissions

As well as granting general permissions to kernel objects, AppCL enforces specific permissions based on the operation.

AppCL LSM uses the audit function ‘appcl_check_rperm_match’ to check for a specific permission when performing an audit. For example, it can be used to check for ‘WRITE’ permission when renaming an inode. Figure 2.0 shows the ‘appcl_check_rperm_match’ audit function.

Figure 2.0 – ‘appcl_check_rperm_match’ audit function

‘appcl_check_rperm_match’

The following security hooks are used to check specific permissions for an inode object. For example, when creating a new inode, it checks that the process has a permission entry with ‘WRITE’ permission. A number of operations check for specific permissions outside of the permission hooks. Some of the hooks used in AppCL LSM to enforce specific permissions are shown below:

appcl_lsm_inode_create 

Called when a new inode is created. AppCL checks for specific ‘WRITE’ permission. This is shown in Figure 3.0.

Figure 3.0 – ‘appcl_inode_create’ security hook

appcl_lsm_inode_rename 

Called when an inode is renamed. AppCL checks for specific ‘WRITE’ permission.

appcl_lsm_inode_mkdir

Called when a new directory is created. AppCL checks for specific ‘WRITE’ permission.

appcl_lsm_file_open

Called when a file object is opened. AppCL checks for specific ‘READ’ permission.

The security hooks for opening a file or receiving a file (‘security_file_open’, ‘security_file_receive’), will grant access based on the file mode, this being whether the file is to be opened for reading, writing, etc. The ‘appcl_check_permission_file_match’ audit function will decide access based on the file mode and the inode’s labelled permissions.

Testing

Two test applications have been used, ‘nano (/bin/nano)’ and ‘vim (/bin/vim.basic)’, to test enforcing permissions. This involved using the ‘inode_alloc_security’ hook to define 6 permission entries to be applied to every inode. ‘nano’ used three permission entries, to allow ‘READ’ and ‘EXECUTE’, but deny ‘WRITE’ permissions. The same was also done for ‘vi’.

Figure 4.0 shows that ‘nano’ was denied ‘WRITE’ permission, however files where able to be opened due to having ‘READ’ access. Figure 5.0 shows that ‘vi’ was denied ‘WRITE’ permission, however files where able to be opened due to having ‘READ’ access.

Figure 4.0 – ‘nano’ write permission denied

Figure 5.0 – ‘vi’ write permission denied

 

Next AppCL LSM will complete the ‘appcl_check_permission_file_match’ audit function to mediate access decisions based on a file mode. It must then allow users to label specific inodes with specific permissions. Further security hooks will also be initialised to enforce specific permissions as required.

---

To view the public git for this project visit:

https://github.com/jamesbjohnson/appcl-lsm-public

Continue to see the GitHub page for updates regarding the project progress/development blog.