AppCL LSM now includes the option for blacklisting/whitelisting default behaviour. This being the default action taken for applications not labelled on an inode. Attributes are set in the following format:

/path/to/app:perm;

Multiple entries can be specified in the same format:

/path/to/app:perm;/path/to/app:perm;

By default any application not present on an inode label is unaffected and its action allowed (blacklisting). AppCL now allows a default DENY behaviour to deny all actions from any application that is not labelled (whitelisting). To enable this behaviour, add an entry to the label in the following format (may be combined with multiple entries):

/path/to/app:perm;deny:–;

The make_appcl_entry() function now checks for the ‘deny’ attribute, labelling the inodes default behaviour flag as required. This is shown in Figure 1.0.

Figure 1.0 – make_appcl_entry() deny attribute check

The permission check functions ‘appcl_specific_perm_check()’ and ‘appcl_mask_perm_check()’ check the default behaviour flag if the inode has permission entries but not for the current application. This is shown in Figure 2.0.

Figure 2.0 – Check default behaviour flag in permission functions

Example:

The following example will grant the application ‘less’ the permissions ‘read’. The default DENY behaviour is also invoked causing all other actions to be denied.

/bin/less:r;deny:–;

To set this as an attribute the ‘setfattr’ utility can be used. The above example would take the following format to be set on a file named ‘test’.

setfattr -n security.appcl -v “/bin/less:r;deny:–;” test

The inode security label is then populated from the extended attribute value and the appropriate permissions are enforced.

---

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.