To allow the user to manage the security policies of AppCL LSM, extended file system attributes are used. With this in mind, the standard Linux user-space tools are used to set the extended attributes.

On Debian: apt-get install attr

This package includes the system tools: ‘setfattr, getfattr‘

To set an extended attribute, three parameters must be specified. This is shown in Figure 1.0.

Figure 1.0 – setfattr command

The file to set the attribute for (-h)

The extended attribute name space (-n)

security.appcl – tells AppCL to process the extended attribute

The value for the extended attribute (-v)

“/bin/nano rwx “ – the application path and permissions for that application.

The following security hooks are used when setting an extended attribute. AppCL LSM uses these hooks to check permissions and retrieve the extended attribute.

appcl_lsm_inode_setxattr – checks permission to set an extended attribute.

appcl_lsm_inode_post_setxattr – after the attribute has been set, AppCL uses this hook to populate the inode security label. Part of this hook is shown in Figure 2.0.

Figure 2.0 – appcl_lsm_inode_post_setxattr security hook

For testing, when an extended attribute is set with appropriate name prefix (XATTR_SECURITY_PREFIX), as specified with the ‘-n’ option for ‘setfattr’, the application path “/bin/nano” is added to the inode security label for the file that is specified with the ‘-h’ option for ‘setfattr’.

Figure 3.0 shows the output from the kernel log when setting an extended attribute to the file ‘test3’. The value has been split into the application path, “/bin/nano”, and the permissions “rwx”. AppCL will use this to update the inode security label so that the appropriate permissions are then enforced.

Figure 3.0 – ‘setfattr’ kernel log output

For the purpose of testing, the path “/bin/nano” is added to a permission entry (a_entries[]) in the inode security label, in the post_setxattr security hook. The permission enforcing is left as per the previous blog post (read, execute, no write permissions).

After setting the attribute as shown in Figure 3.0, Figure 4.0 shows the file ‘test3’ open in nano, with no write permission. Whereas before setting the attribute, nano was able to write to ‘test3’.

Figure 4.0 – ‘test3’ file, no write permission

Next AppCL LSM will continue to develop the extended attributes. As well as setting an attribute based on the value, handling removing and listing attributes must also be considered.

AppCL will continue to develop to be accepting multiple attributes and enforcing permissions correctly for user defined policies.

---

Great news! I will be giving a talk at Securi-Tay V on AppCL LSM.

Securi-Tay V is being held at Abertay University, Dundee. Friday 26th and Saturday 27th of February.

AppCL LSM: A Linux kernel security module to implement application oriented access controls.

To find out more please read the previous blog post or contact me.

---

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.

Great news! I will be giving a talk at Securi-Tay V on AppCL LSM.

Securi-Tay V is being held at Abertay University, Dundee. Friday 26th and Saturday 27th of February.

AppCL LSM: A Linux kernel security module to implement application oriented access controls

The talk will cover three areas:

ACL’s and PACL’s

• Looking at the issues with current user oriented access controls (ACL’s), and discussing the added benefit of application oriented access controls (PACL’s).

Under a traditional ACL, applications inherit the privileges of the user than runs them. This often granting the application higher privileges than it requires and potential leverage for Zero Day Malware.

The Linux Security Module (LSM) framework

• The Linux Security Module (LSM) framework and how it allows development of additional kernel level security. Current Mandatory Access Controls (MAC) solutions, such as SELinux, use this framework.

AppCL LSM

• AppCL LSM – Linux kernel security module built using the LSM framework. A discussion about how AppCL uses the LSM framework to implement an application oriented access control proof of concept. This is the subject of my final year project at Leeds Beckett University, studying BSc (Hons) Computer Forensics and Security.

If you are attending the conference it would be great to see you. If you are interested in the talk I will be giving or in AppCL LSM please contact me.

Now that AppCL LSM is able to label a process with the path of the binary application relating to that process, and label the inode kernel object with permission entries, it must enforce the permissions that are defined in the permission entries.

Essentially it must enforce the ‘READ | WRITE | EXECUTE’ permissions using the Linux Security Module (LSM) framework hooks. The LSM framework supports this through the security hooks that allow access control decisions to be made at key decision making processes within the kernel.

General Permissions

The following security hooks are used to check permissions for an inode object and a file object. Figure 1.0 shows the ‘appcl_lsm_inode_permission’ security hook

appcl_lsm_inode_permission

appcl_lsm_file_permission

The security hook ‘appcl_lsm_inode_permission’ grants general permissions to an inode object based on the requested permission mask. It does this using a series of audit functions.

check_inode_path_match

• checks to see if the current process path matches any permission entry for the current inode. If a permission entry is present then AppCL knows to enforce permissions for that inode.

appcl_check_permission_mask_match

• loops through the permission entries to check if a labelled permission (e_perm) matches the requested permission (mask). If the inode includes a permission entry for the current process, but no matching permission is found, permission is not granted to the inode. Whereas a matching permission label for a process will return a success and the permission will be granted.

Figure 1.0 – ‘appcl_lsm_inode_permission’ security hook

The LSM framework also includes additional hooks for checking permissions. The ‘inode_permission’ and ‘file_permission’ hook do not cover all operations by an inode so additional checks must also be made.

Specific Permissions

As well as granting general permissions to kernel objects, AppCL enforces specific permissions based on the operation.

AppCL LSM uses the audit function ‘appcl_check_rperm_match’ to check for a specific permission when performing an audit. For example, it can be used to check for ‘WRITE’ permission when renaming an inode. Figure 2.0 shows the ‘appcl_check_rperm_match’ audit function.

Figure 2.0 – ‘appcl_check_rperm_match’ audit function

‘appcl_check_rperm_match’

The following security hooks are used to check specific permissions for an inode object. For example, when creating a new inode, it checks that the process has a permission entry with ‘WRITE’ permission. A number of operations check for specific permissions outside of the permission hooks. Some of the hooks used in AppCL LSM to enforce specific permissions are shown below:

appcl_lsm_inode_create 

Called when a new inode is created. AppCL checks for specific ‘WRITE’ permission. This is shown in Figure 3.0.

Figure 3.0 – ‘appcl_inode_create’ security hook

appcl_lsm_inode_rename 

Called when an inode is renamed. AppCL checks for specific ‘WRITE’ permission.

appcl_lsm_inode_mkdir

Called when a new directory is created. AppCL checks for specific ‘WRITE’ permission.

appcl_lsm_file_open

Called when a file object is opened. AppCL checks for specific ‘READ’ permission.

The security hooks for opening a file or receiving a file (‘security_file_open’, ‘security_file_receive’), will grant access based on the file mode, this being whether the file is to be opened for reading, writing, etc. The ‘appcl_check_permission_file_match’ audit function will decide access based on the file mode and the inode’s labelled permissions.

Testing

Two test applications have been used, ‘nano (/bin/nano)’ and ‘vim (/bin/vim.basic)’, to test enforcing permissions. This involved using the ‘inode_alloc_security’ hook to define 6 permission entries to be applied to every inode. ‘nano’ used three permission entries, to allow ‘READ’ and ‘EXECUTE’, but deny ‘WRITE’ permissions. The same was also done for ‘vi’.

Figure 4.0 shows that ‘nano’ was denied ‘WRITE’ permission, however files where able to be opened due to having ‘READ’ access. Figure 5.0 shows that ‘vi’ was denied ‘WRITE’ permission, however files where able to be opened due to having ‘READ’ access.

Figure 4.0 – ‘nano’ write permission denied

Figure 5.0 – ‘vi’ write permission denied

 

Next AppCL LSM will complete the ‘appcl_check_permission_file_match’ audit function to mediate access decisions based on a file mode. It must then allow users to label specific inodes with specific permissions. Further security hooks will also be initialised to enforce specific permissions as required.

---

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.

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.

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:

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

To manage the process of loading new programs AppCL LSM will use the LSM program loading hooks that mediate program loading. The ‘linux_binprm’ structure represents a new program being loaded during an execve.

Initially the ‘bprm_set_creds’ hook is initialised as shown below. Currently the path name for the loading program is identified (fpath_name) through the ‘linux_binprm’ structure.

The screenshot below shows the output from the kernel log when running a number of command line programs. The path name for each program is identified and detailed below.

Program ‘tail‘ : Path ‘/usr/bin/tail‘

Program ‘ls‘ : Path ‘/bin/ls‘

Program ‘cat‘ : Path ‘/bin/cat‘

The path name of a program on the system can act as a program specific identifier to allow AppCL LSM to identify programs and mediate privileges based on this.

---

To view the public git for this project visit:

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

Security labelling

As with the inode security label, AppCL LSM allocates a file security label. This is done using the ‘file_alloc_security’ and ‘file_free_security’ hooks.

Attributes of these security labels are now permission flags and masks as defined by ‘richacl’, as used with extended access control. These attributes are still to be properly defined by AppCL. Sample values are used at present.

file_open hook

The file_open hook is now initialised as shown below. This hook is accessed whenever a new filesystem object is opened.

Currently AppCL retrieves the file security label and inode security label for the open file system object. It then goes on to identify the path name of that object (fpath_name).

The screenshot below shows the output from the kernel log when running ‘nano’. The pathname for every file object opened by the nano application is then printed.

To manage the process of loading new programs AppCL LSM will use the LSM program loading hooks (binprm).

---

To view the public git for this project visit:

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

In the latest version of AppCL LSM the following security hooks are updated to manage the security labelling of the kernel ‘inode’ object (file system objects, such as files, directories and symlinks). SELinux was consulted for inode security labelling techniques :

inode_alloc_security

• Security hook now passes the ‘inode_security_struct’ to the ‘i_security’ attribute within the inode object.
• inode_security_struct is defined in ‘appcl_lsm.h’.
• This is defined as the inode security label.
• AppCL must decide attributes to label within the inode_security_struct, and then manage security decisions using the inode security label values.

inode_free_security

• Security hook free’s the allocated inode_security_struct.

The output from the kernel log shows an example inode and some of the values associated with the inode_security_struct (inode security label).

AppCL LSM must properly decide security label attributes, define handlers to process these attributes and mediate access based on application specific identifiers.

To view the public git for this project visit:

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

Development began against the 4.1.6 Kernel. I have now updated the module to the 4.3 Kernel and have began identifying relevant security hooks.

Figure 1 – AppCL-LSM kernel build ‘/var/log/kern.log’ output

Initially, inode hooks, program loading hooks and file hooks will be initialised.

This will allow AppCL – LSM to manage security labelling of file system objects, such as files, directories and symlinks (inode hooks). To manage the process of loading new programs (program loading hooks) and to mediate access to open filesystem objects (file hooks).

To view the public git for this project:

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

Currently the AppCL-LSM module initialises various security hooks through the LSM framework and registers the security module with the kernel. See the AppCL-LSM repository for more details.

README.md contains descriptions for source files.

To view the public git for this project:

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