Public Git update, example implementation

The public git repository for AppCL LSM has been updated to reflect the current progress of the project. The description of the update from the git repository is shown below. This post will look at some of the updates to AppCL LSM in more detail.

Git commit – Update comments throughout, project update
– Update comments.
– Require root to set and remove xattr.
– Specific permission check function [appcl_specific_perm_check()] – applied to more security hooks.
– Reset inode security label from xattr on reboot to retain security information [appcl_lsm_d_instantiate()].
– Debug all compiler warnings. Current build compiles with no warnings.
– Remove some unused definitions.

Public Git update:

Comments have been updated throughout and compiler warnings have been addressed. AppCL LSM now compiles with no compiler warnings as shown in Figure 1.0.

Figure 1.0 – AppCL LSM compilation


The ‘setfattr’ utility from the ‘attr’ package is used to set the extended attribute as first discussed in the ‘Setting extended attributes‘ post. The namespace ‘security.appcl‘ must be specified for the security module to receive the attribute. The value contains the path of an application and its associated permissions. Multiple entries can be specified, using the delimiter ‘;’.

AppCL LSM checks permission to set the extended attribute in ‘appcl_lsm_inode_setxattr‘, now requiring root to succeed. After a successful operation, the security hook ‘appcl_lsm_inode_post_setxattr‘ then processes the extended attribute value and updates the inode security label with the permission entries and associated security information.

The information in the inode security label is lost when the system loses power, so the extended attribute is used to store a representation of this on disk. When the system reboots, the security hook ‘appcl_lsm_d_instantiate‘ processes the AppCL extended attributes and updates the security information so that this information is retained. It first checks if the extended attribute is supported, and then receives the attribute value to process. This is shown in Figure 2.0.

Figure 2.0 – ‘appcl_lsm_d_instantiate‘ security hook, getting extended attribute value

Screen Shot 2016-03-14 at 12.00.55

The function ‘appcl_specific_perm_check()‘ has been added to handle specific permission checks, as first discussed in the post ‘Enforcing permissions – part 1‘. It first checks if the current process path matches a permission entry in the inode security label ‘a_entries’ array, using the audit function ‘check_inode_path_match()‘. It then uses the audit function ‘appcl_check_rperm_match()‘ to check for the appropriate permission entry. This is shown in Figure 3.0.

Figure 3.0 – ‘appcl_specific_perm_check()‘ function

Screen Shot 2016-03-14 at 12.00.02

Example implementation:

For this test example, the test application ‘cat’ is used, with the path ‘/bin/cat’ as the application identifier.

Figure 4.0 shows the first test case, setting only read permissions for the test application. ‘cat’ was able to read the test file, but unable to write to it. This is reflective of the permissions set through the extended attribute.

Figure 4.0 – File ‘test3’: application ‘cat’ with ‘read’ permissions

Screen Shot 2016-03-14 at 12.04.55

Figure 5.0 shows the second test case, setting read and write permissions for the test application. With the additional ‘write’ permission, ‘cat’ was able to read, write and append to the test file. In the future ‘append’ may be added as a separate permission attribute however at present ‘write’ permission must be held to append.

Figure 5.0 – File ‘test3’: application ‘cat’ with ‘read’ and ‘write’ permissions

Screen Shot 2016-03-14 at 12.10.05

Figure 6.0 shows the third test case, setting no permissions for the test application. With no permissions, ‘cat’ was unable to read or write to the test file.

Figure 6.0 – File ‘test3’: application ‘cat’ with no permissions

Screen Shot 2016-03-14 at 12.12.44

The same is true when using the test application ‘nano’ as in some previous development posts. Figure 7.0 shows the same attributes as the test examples above however for ‘nano’. When the system reboots the inode security label is repopulated from the extended attribute value and the permissions continue to be enforced.

To view the public git for this project visit:

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

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s