Defining permissions

Following on from the previous blog post ‘process security labelling, process path, test inode labelling‘, AppCL LSM continues to define permissions to store in the inode security label.

The inode security label (defined in appcl_lsm.h) stores an array of permission entries named ‘a_entries’. This is shown in Figure 1.o.

Figure 1.0 – inode security label, a_entries[APPCL_MAX_INODE_ENTRIES];

An array of type ‘struct appcl_posix_pacl_entry’ (defined in appcl_lsm.h) stores the file system permissions for the inode and is labelled using the application path name, for example ‘/bin/ls’. AppCL will add a new entry to this array to define an application (inode_sec_pathname) and its permissions (e_tag, e_perm).  This is shown in Figure 2.0.

Multiple entries can be added to the ‘a_entries’ array (up to the maximum of ‘APPCL_MAX_INODE_ENTRIES’), to define multiple applications and their permissions for the inode.

Figure 2.0 – Permission entry array item

‘audit.c’ and ‘audit.h’ define audit functions for testing the current process path name (process security labelling, process path, test inode labelling) with that stored in the inode security label and associated permission entries (a_entries).

The audit function; ‘get_current_inode_perm_count’, loops though the permission entries array, and checks each labelled application path against the current process path, using the audit function ‘check_current_cred_path’. It then returns the count of entries that match. This is shown in Figure 3.0

Figure 3.0 – audit.c, get_current_inode_perm_count

The ‘appcl_lsm_file_open security’ hook uses the ‘get_current_inode_perm_count’ audit function to determine if the inode has permissions defined for the current application. It then uses the audit function ‘get_inode_perm_count’ to return the total number of permission entries to store in the file security label ‘entries_count’, as defined in ‘appcl_lsm.h’.

As a test, the ‘inode_alloc_security’ hook stores a total of 6 entries (for now in all inodes). These where stored as follows:

Permission entry 1 – a_entries[0]

• Path – /bin/nano
• Permission – Read

Permission entry 2 – a_entries[1]

• Path – /bin/nano
• Permission – Write

Permission entry 3 – a_entries[2]

• Path – /bin/cat
• Permission – Execute

Permission entry 4 – a_entries[3]

• Path – /bin/ls
• Permission – Read

Permission entry 5 – a_entries[4]

• Path – /bin/cat
• Permission -Read

Permission entry 6 – a_entries[5]

• Path – /bin/cat
• Permission – Read

Figure 4.0 shows the kernel log output for running two of the test applications (‘ls’, ‘cat’). The output shows the audit collected the correct number of permission entries for each application. Figure 4.0 highlights the entry to the kernel log output for one file opened by ‘ls’ in blue. It highlights the kernel log output for one file opened by ‘cat’ in green.

Figure 4.0 – Kernel log output, test applications ls & cat

Next AppCL LSM will enforce any permissions that are associated with the application and provide a method for users to specify permissions and behaviours to enforce through AppCL.

---

The public git repository has been updated and includes many more comments throughout.

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.