AppCL LSM uses the security label of a process to store the path of the application for that process. The inode security label is then used to define an application and its file system privileges (read-write-execute). When a file is opened, AppCL checks the security label of the inode and compares any path with that stored in the current process label. If the path matches then the module will continue to enforce the defined permissions. This is represented in Figure 1.0.
This will allow file system permissions to be implemented based on the current application, rather than the current user.
Figure 1.0 – AppCL LSM concept
The following blog post will look at the current progress of the project, and how AppCL LSM is successfully labelling processes with the application path. A test was also run to see if the current process and inode labelling produce a match using the test application ‘cat’ (/bin/cat).
The following security hooks are used to prepare, allocate, free and transfer the AppCL security label part of the process:
security_cred_alloc_blank
security_cred_free
security_cred_prepare
security_cred_transfer
The security label (task_audit_data) is defined in ‘audit.h’ and is shown in Figure 2.0
Figure 2.0 – Process security label, task_audit_data
The security hook ‘appcl_lsm_bprm_set_creds’ identifies the path of the binary application, and stores this in the ‘bprm_pathname’ attribute of the process security label. This is shown in Figure 3.0.
Figure 3.0 – appcl_lsm_bprm_set_creds path name
As discussed in a previous post, AppCL LSM already labels an inode however the appropriate attributes have not yet been defined. To compare the path of a current process with the inode security label, a test application is used (cat), with the path (/bin/cat), stored in the ‘inode_sec_pathname’ attribute of the security label. For now applied to every inode. This is shown in Figure 4.0.
Figure 4.0 – inode_alloc_security test pathname
AppCL LSM then uses the ‘appcl_lsm_file_open’ security hook, to retrieve the pathname stored for the current process. It also retrieves the pathname stored for the inode relating to that file.This is shown in Figure 5.0. These pathnames are compared and if they match, a line is printed to the kernel log. This is where the appropriate permissions will be enforced. At present a couple of other test applications are checked in the ‘appcl_lsm_file_open’ hook, including ‘ls’, ‘tail’ and ‘cat’. This is shown in Figure 6.0.
Figure 5.0 – appcl_lsm_file_open
Figure 6.0 – appcl_lsm_file_open pathname test
When tested, each file that was accessed by the test applications printed the path of the current process, as stored in the process security label, to the kernel log as expected. When ‘cat’ was tested, the test against the inode security label also printed to the kernel log as expected. This is shown in Figure 7.0.
Next AppCL LSM will define the file system permissions and the methods for enforcing this.
Figure 7.0 – Kernel log output
To view the public git for this project visit:
AppCL LSM 