ome observers might well believe that the kernel has accumulated plenty of special-purpose virtual filesystems. Even so, 2.6.14 will include yet another one: securityfs. This filesystem is meant to be used by security modules, some of which were otherwise creating their own filesystems; it should be mounted on /sys/kernel/security. Securityfs thus looks, from user space, like part of sysfs, but it is a distinct entity.

The API for securityfs is quite simple – it only exports three functions (defined in <linux/security.h>). The usual first step will be to create a directory specific to the security module at hand with:

    struct dentry *securityfs_create_dir(const char *name, 
                                         struct dentry *parent);

If parent is NULL, the directory will be created in the root of the filesystem.

That directory can be populated with files using:

    struct dentry *securityfs_create_file(const char *name, 
                                          mode_t mode,
				          struct dentry *parent,
                                          void *data,
					  struct file_operations *fops);

Here, name is the name of the file, mode is the permissions the file will have, parent is the containing directory (or NULL for the filesystem root), data is a private data pointer, and fops is a file_operations structure containing the methods which actually implement the file. The calling module must provide operations which make the file behave as desired. Securityfs differs from sysfs in this regard; it makes no attempt to hide the low-level file implementation. As a result, security modules can do ill-advised things like creating highly complex files, providing ioctl() operations, and more. Most modules, however, will simply want to provide straightforward open(), read(), and (maybe) write() methods and be done with it.

All of these files and directories should be cleaned up when the module is unloaded. The same function is used for both files and directories:

    void securityfs_remove(struct dentry *dentry);

There is no automatic cleanup of files performed, so this step is mandatory.

Those wanting to see an example of securityfs in action can look at this patch in 2.6.14

author serue@us.ibm.com <serue@us.ibm.com> Sat, 09 Jul 2005 01:44:19 -0500
committer Chris Wright <chrisw@osdl.org> Sat, 09 Jul 2005 08:49:05 -0700

which causes the seclvl module to use it.

src: https://lwn.net/Articles/153366/

cat /proc/self/mountinfo
16 21 0:16 / /sys rw,nosuid,nodev,noexec,relatime shared:7 - sysfs sysfs rw
17 21 0:4 / /proc rw,nosuid,nodev,noexec,relatime shared:12 - proc proc rw
18 21 0:6 / /dev rw,nosuid,relatime shared:2 - devtmpfs udev rw,size=493488k,nr_inodes=123372,mode=755
19 18 0:17 / /dev/pts rw,nosuid,noexec,relatime shared:3 - devpts devpts rw,gid=5,mode=620,ptmxmode=000
20 21 0:18 / /run rw,nosuid,noexec,relatime shared:5 - tmpfs tmpfs rw,size=101048k,mode=755
21 0 8:1 / / rw,relatime shared:1 - ext4 /dev/sda1 rw,errors=remount-ro,data=ordered
22 16 0:7 / /sys/kernel/security rw,nosuid,nodev,noexec,relatime shared:8 - securityfs securityfs rw
23 18 0:19 / /dev/shm rw,nosuid,nodev shared:4 - tmpfs tmpfs rw
24 20 0:20 / /run/lock rw,nosuid,nodev,noexec,relatime shared:6 - tmpfs tmpfs rw,size=5120k
25 16 0:21 / /sys/fs/cgroup ro,nosuid,nodev,noexec shared:9 - tmpfs tmpfs ro,mode=755
26 25 0:22 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime shared:10 - cgroup cgroup rw,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd
27 16 0:23 / /sys/fs/pstore rw,nosuid,nodev,noexec,relatime shared:11 - pstore pstore rw
28 25 0:24 / /sys/fs/cgroup/freezer rw,nosuid,nodev,noexec,relatime shared:13 - cgroup cgroup rw,freezer
29 25 0:25 / /sys/fs/cgroup/net_cls,net_prio rw,nosuid,nodev,noexec,relatime shared:14 - cgroup cgroup rw,net_cls,net_prio
30 25 0:26 / /sys/fs/cgroup/pids rw,nosuid,nodev,noexec,relatime shared:15 - cgroup cgroup rw,pids
31 25 0:27 / /sys/fs/cgroup/devices rw,nosuid,nodev,noexec,relatime shared:16 - cgroup cgroup rw,devices
32 25 0:28 / /sys/fs/cgroup/cpuset rw,nosuid,nodev,noexec,relatime shared:17 - cgroup cgroup rw,cpuset
33 25 0:29 / /sys/fs/cgroup/memory rw,nosuid,nodev,noexec,relatime shared:18 - cgroup cgroup rw,memory
34 25 0:30 / /sys/fs/cgroup/cpu,cpuacct rw,nosuid,nodev,noexec,relatime shared:19 - cgroup cgroup rw,cpu,cpuacct
35 25 0:31 / /sys/fs/cgroup/blkio rw,nosuid,nodev,noexec,relatime shared:20 - cgroup cgroup rw,blkio
36 25 0:32 / /sys/fs/cgroup/perf_event rw,nosuid,nodev,noexec,relatime shared:21 - cgroup cgroup rw,perf_event
37 17 0:33 / /proc/sys/fs/binfmt_misc rw,relatime shared:22 - autofs systemd-1 rw,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=1571
39 16 0:8 / /sys/kernel/debug rw,relatime shared:23 - debugfs debugfs rw
38 18 0:34 / /dev/hugepages rw,relatime shared:24 - hugetlbfs hugetlbfs rw
40 18 0:15 / /dev/mqueue rw,relatime shared:25 - mqueue mqueue rw
42 16 0:35 / /sys/kernel/config rw,relatime shared:26 - configfs configfs rw
106 20 0:36 / /run/user/1000 rw,nosuid,nodev,relatime shared:62 - tmpfs tmpfs rw,size=101044k,mode=700,uid=1000,gid=1000

whats in there?

root@debian9:~# ll /sys/kernel/security/ima/*
-r--r----- 1 root root 0 Jul  5 11:12 /sys/kernel/security/ima/ascii_runtime_measurements
-r--r----- 1 root root 0 Jul  5 11:12 /sys/kernel/security/ima/binary_runtime_measurements
--w------- 1 root root 0 Jul  5 11:12 /sys/kernel/security/ima/policy
-r--r----- 1 root root 0 Jul  5 11:12 /sys/kernel/security/ima/runtime_measurements_count
-r--r----- 1 root root 0 Jul  5 11:12 /sys/kernel/security/ima/violations
root@debian9:~# ll /sys/kernel/security/lsm
-r--r--r-- 1 root root 0 Jul  5 11:12 /sys/kernel/security/lsm

cat /sys/kernel/security/ima/violations
0

root@debian9:~# cat /sys/kernel/security/ima/policy
cat: /sys/kernel/security/ima/policy: Permission denied

root@debian9:~# cat /sys/kernel/security/ima/ascii_runtime_measurements
10 1d8d532d463c9f8c205d0df7787669a85f93e260 ima-ng sha1:0000000000000000000000000000000000000000 boot_aggregate
admin