Setting extended attributes

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

Screen Shot 2016-01-29 at 12.43.48

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

Screen Shot 2016-01-29 at 12.53.29.png

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

Screen Shot 2016-01-29 at 13.01.13

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

Screen Shot 2016-01-29 at 13.02.18

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:

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

One thought on “Setting extended attributes

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s