Permissions update:

AppCL LSM grants permissions in the format of ‘read’, ‘write’ and ‘execute’ permissions. This is done based on a path-based application identifier. A limitation of previous versions is that only one permission could be granted per application in the format below:

/path/to/app:perm;

/bin/nano:r;

To grant multiple permissions, an additional entry was required, in the format below:

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

/bin/nano:r;/bin/nano:w;

The latest update has removed the need for multiple entries by allowing multiple permissions to be specified for each application path. This is in the format below:

/path/to/app:perms;

/bin/nano:rw;

Other minor updates:

 – The appcl.py userspace tool has been updated to allow multiple permission values to be specified in the attribute build mode.

 – Definitions in the ‘audit.h’ header file have been moved to the ‘appcl_lsm.h’ header file removing the need for this file.

Talks:

The project website now has a page detailing the talks that I have presented on AppCL LSM. The slides from the presentations are available as PDF’s, and when the videos from the talks are released, I will make them available at the link below.

AppCL LSM Talks/Videos

---

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.

Cybercrime and Security Innovation Centre Launch

Following on from the talk I gave on AppCL LSM at Securi-Tay V, I will be presenting a further talk on this project at the ‘Cybercrime and Security Innovation Centre Launch’, being held at Leeds Beckett University on Wednesday 6th April.

View the event details/get your ticket from Eventbrite.

The Cybercrime and Security Innovation Centre Launch event will take place 1.30pm-18:00. Following this the Leeds Ethical Hacking Society will host a session with a number of student talks relating to Information Security and projects ongoing at Leeds Beckett University, 18.30 – 20.30.

As part of this I will present a talk on AppCL LSM and appcl.py.

AppCL LSM: Implementing and managing application oriented access controls

This talk will take a different perspective to the talk at Securi-Tay V. I will take a higher level look at how AppCL LSM achieves its goal of implementing application oriented access controls.

As well as a discussion on AppCL LSM and its use of the Linux Security Module (LSM) framework, I will provide demonstrations of AppCL LSM in use. The python tool ‘appcl.py’ will be used to demonstrate the management of the security module and it’s policies.

If you are attending the Cybercrime and Security Innovation Centre Launch event, it would be great to see you. If you are interested in the talk I will be giving or in the AppCL LSM project, please contact me.

---

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.

AppCL LSM has been developed against the Linux kernel version 4.3. At present the latest stable kernel, as shown in Figure 1.0, is version 4.5. This is available from ‘https://www.kernel.org/‘ along with previous kernel versions.

Figure 1.0 – Linux Kernel Archives [https://www.kernel.org/]

AppCL LSM is supported in the latest stable build (4.5), as well as version 4.3. The script ‘appcl_lsm_update.sh’, located at ‘appcl-lsm/security-config/appcl_lsm_update.sh’, can be used to include AppCL LSM in the kernel build process. As well as copying the appropriate files into the Linux source directory, the security configuration files are updated. This update script has a variable for the linux source version, as shown in Figure 2.0. Changing this to ‘linux-4.5’ (previously linux-4.3) includes AppCL LSM in the kernel build process for the appropriate version.

Figure 2.0 – appcl_lsm_update.sh Linux source version

---

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.

“appcl.py is a Python script that can be used to manage the AppCL LSM extended attributes and security policies. The appcl.py tool is currently located at: ‘/appcl-lsm/security-config/tools/appcl.py’ in the project repository.” –appcl.py

appcl.py now has a ‘build mode’, that can be started against a file (–file option) or a complete directory (–dir option). Knowledge of the AppCL LSM attribute format (as discussed in the post ‘Default ‘DENY’ behaviour‘), nor the pathname of an application is required. Figure 1.0 shows build mode against a file (test3).

The user first enters the application name, which then finds the path for the binary applications matching the application name. Then the user enters the permission to grant the application.

Multiple applications can be restricted by adding additional programs to the attribute. Finally build mode checks whether the user wants to enable default DENY behaviour to DENY all other actions by default. appcl.py then sets the attribute to the file specified and sets up the security information on the inode.

Figure 1.0 – appcl.py file build mode

Figure 2.0 shows build mode against a complete directory (testdir/). The same process as with a file is completed, except appcl.py sets the attribute to all files within the specified directory.

Figure 2.0 – appcl.py directory build mode

‘Build mode’ makes the job of setting AppCL LSM attributes to files/directories simpler. If the required pathname is known and the AppCL extended attribute format is known then the appcl.py ‘–set’ option can still be used to set the attributes. The appcl.py ‘–get’ and ‘–remove’ options are still used to view and remove the AppCL LSM attributes.

As well as the long argument options (–file, –dir, –set, –get, –remove, –build), short switches (-f, -d, -v, -g, -x, -b) can be used, this is detailed in the appcl.py help page (appcl.py –help/-h).

---

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.

appcl.py is a Python script that can be used to manage the AppCL LSM extended attributes and security policies. The linux utilities ‘setfattr’ and ‘getfattr’ can be used with the appropriate security namespace [security.appcl]. appcl.py offers an easier to use interface and also has the option to set an attribute to the contents of a directory.

Below is the help page for the appcl.py tool from the AppCL LSM project. It provides an interface to; set, get and remove the AppCL extended attributes for files and complete directories.

python appcl.py – -help

# Help:
# python appcl.py -h
#
DESCRIPTION
The appcl.py script handles the extended attributes associated with the AppCL LSM security module.
The setfattr and getfattr system utilities can also be used to manage extended attributes. If using these utilities the appcl security namespace must be specified [-n security.appcl] for AppCL LSM to process and enforce the attribute.
The attr package is still required for appcl.py.
#
EXAMPLE USAGE
Set Attributes:
Directory – python appcl.py –dir <input-directory> –set <xattr-value>
File – python appcl.py –file <input-file> –set <xattr-value>
Get Attributes:
Directory –  python appcl.py –dir <input-directory> –get
File – python appcl.py –file <input-file> –get
Remove Attributes:
Directory –  python appcl.py –dir <input-directory> –remove
File – python appcl.py –file <input-file> –remove
#
OPTIONS
-f file, –file=file
Specifies a file input.
-d directory, –dir=directory
Specifies a directory input.
-v, –set
Sets the new AppCL LSM extended attribute, and associated permissions.
-g, –get
View the AppCL LSM stored extended attribute for file/directory contents.
-x, –remove
Remove the AppCL LSM extended attribute and associated permission entries.
-h, –help
Help page

Setting attributes:

– -set  “/path/to/app:perm;”

Figure 1.0 shows setting an AppCL attribute to the file ‘test3’ using the ‘–file’ option. The same was set to the contents of the directory ‘testdir’ using the –dir’ option.

Figure 1.0 – appcl.py setting AppCL LSM attributes

Getting attributes:

– -get

Figure 2.0 shows getting the AppCL attribute for the file ‘test3’ using the ‘–file’ option. The attributes for the contents of the directory ‘testdir’ are viewed using the –dir’ option.

Figure 2.0 – appcl.py getting AppCL LSM attributes

Removing attributes:

– -remove

Figure 3.0 shows removing the AppCL attribute for the file ‘test3’ using the ‘–file’ option. The attributes for the contents of the directory ‘testdir’ are removed using the –dir’ option.

Figure 3.0 – appcl.py removing AppCL LSM attributes

Example:

Default ‘DENY’ behaviour && appcl.py

Figure 4.0 shows the attribute set using appcl.py on the file ‘test3’. The application ‘less’ has ‘read’ permissions and the default DENY behaviour is set. In testing ‘less’ was able to read the file ‘test3’ and no other application was able to access it.

Figure 4.0 – appcl.py default DENY behaviour

The appcl.py tool is currently located at: ‘/appcl-lsm/security-config/tools/appcl.py’ in the project repository.

---

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.

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.

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

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

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

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

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

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:

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

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

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.

It’s now been a week since Securi-Tay V came to an end!

It was a brilliant conference with a lot of interesting and inspiring talks from both students, and industry professionals.

I gave my talk on AppCL LSM on the first day and have received a great response. Thank you to everyone that came to see me present and to all of you who have given me feedback and advice following this.

The guys at Abertay (who did an amazing job putting Securi-Tay V together!), tell me my talk has been recorded, along with many other great talks from across the conference and I will be posting a link to these once they’re made available. This will be through the project website and twitter. @jbondjohnson

---

The project README has been updated and includes the current issues I am facing. This is included on the appcl-lsm.org home page and the public git repository. If you have any feedback please get in touch.

# 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 inode from the 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.

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 GitHub page for updates regarding the project progress/development blog.

With only 9 days to go until Securi-Tay V kicks off in Dundee, preparations are underway!

The schedule has now been released and can be accessed from Securi-Tay V schedule.

The talk I will be presenting:

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

Is on the 26th February, 13.45 – 14.45.

As part of my preparation I will be presenting a preview of the talk at Leeds Ethical Hacking Society, at Leeds Beckett University. On Thursday 18th February at 19.30.

If you are interested in any activities/projects at Leeds Hacking Society or would like to get involved, please contact me.