The last update highlighted the issue I was having with repopulating the inode security label from the extended attribute value, when the system reboots/gets powered off. Below is the extract from the project README regarding the issue.

 #Current issue – The ‘appcl_lsm_inode_post_setxattr’ hook in ‘appcl_lsm.c’ passes the extended attribute to the function ‘make_appcl_entry()’ to set up the security information based on the extended attribute value. AppCL must now do this with the extended attribute when the system reboots.
– When the system is powered off/reboots, AppCL must reset the security information for the inodes with an AppCL extended attribute. This is because the inode security label is stored in RAM and the extended attribute is used to retain a representation of this on disk.
The ‘security_inode_setsecurity’, ‘security_inode_getsecurity’, ‘security_inode_d_instantiate’, ‘security_inode_init_security’ are all security hooks relating to the extended attributes.

New update – AppCL LSM is now able to repopulate the inode security label based on the extended attribute value for the inode object. This is how the addition reads in the project README.

– NEW: The ‘appcl_lsm_d_instantiate’ hook initialises the inode security label. It checks the superblocks ‘smagic’ attribute to avoid getting the extended attribute from a filesystem that does not support it or for cases such as inodes that have not been fully initialised, such as during boot. It then uses the ‘getxattr’ interface to receive the extended attribute value. As with the ‘appcl_lsm_inode_post_setxattr’ hook, the ‘appcl_lsm_d_instantiate’ hook passes the extended attribute to the function ‘make_appcl_entry()’ to set up the security information based on the extended attribute value. This handles the repopulation of the inode security label when the system reboots.

It is with input from the ‘SMACK’ d_instantiate hook function that the ‘appcl_lsm_d_instantiate’ hook has taken shape. The project will contain further comments to reflect this and better explain the code.

The ‘make_appcl_entry()’ helper function parses the extended attribute string and creates the ‘appcl_pacl_entry’ objects. Figure 1.0 shows the kernel log output from the helper function. The extended attribute has been added as 3 entries to the inode security label. Each entry contains a pathname (application identity) and a permission (read, write, execute). You can specify multiple entries (delimited with a ‘;’).

As mentioned this function is called in the ‘appcl_lsm_post_setxattr’ hook when the attribute is set. It is then called in the ‘appcl_lsm_d_instantiate’ hook when initialising the inode after power has been lost.

Figure 1.0 – ‘make_appcl_entry’ kernel log output

Figure 2.0 shows 3 files and the extended attributes for each file in the security.appcl namespace. The file ‘test3’ has ‘read’ and ‘write’ permissions for the application ‘nano’. The file ‘test4’ has only ‘read’ permissions for the application ‘nano’. The file ‘test5’ has no AppCL extended attribute set and is not affected by the AppCL LSM module.

Figure 2.0 – security.appcl extended attributes

AppCL LSM will now continue to ensure permissions are appropriately enforced. The ‘inode_init_security’ hook function will also be set up to handle the creation of new inode objects and security information for the new inode.

You can now follow me on twitter for updates to the AppCL LSM project.

@jbondjohnson

---

To view the public git for this project visit:

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

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