This is a list of potential work items that relate to the SELinux kernel component. If you are interested in helping out with one of these items, or have something you would like to add, please contact the SELinux development team using the mailing list below.

SELinux Developer's Mailing List Subscribe Info
SELinux Developer's Mailing List Archive

This list is being migrated to https://github.com/SELinuxProject/selinux-kernel/issues. The old list is below until we have finished migrating.

At the moment most of the work items have been taken from an older SELinux todo list which was not well maintained, and as a result many of the items are no longer applicable. We will be going through this older list to capture items that are still relevant, moving them to the "New Items" list below, but this will likely take some time.

• Improve the scripts/selinux/mdp script to generate a more useful and flexible minimal policy
• Develop a mechanism to automatically detect new syscalls in RC kernels and determine SELinux coverage
• APIs for getting and setting security contexts of IPC objects
• Ensure that socket context is kept consistent on socket inode and sock structures
• Increased granularity for Generic Netlink access controls

• Revoke memory-mapped file access upon policy change or setxattr.

PM: How feasible is this?

SDS: revoke(2) seems to be an ever-recurring topic on lkml. However, even with a revoke(2) implementation on regular files, it isn't quite what we want, as it would revoke all open references to the file, whereas ideally we'd like it to revalidate all open references to the file under the new policy or file security context and only revoke the ones which no longer are allowed by policy. However, for cross-domain solutions / assured pipelines without data copying, a simple revoke(2) would be better than nothing; the program would know that it needed to close and re-open its references to the file upon calling revoke(2) and any other process that is trying to access the file would correctly be deprived of its access.

• Real device labeling and access control (i.e. bind a label to a device in the kernel irrespective of what device node is used to access it so that a process that can create any device nodes at all can't effectively bypass all device access controls just by creating an arbitrary node to any device in a type accessible to it).

PM: Labeling a device seems like it might not be too bad, implementing reasonable access controls seems like it might be a nightmare depending on your security goals. What exactly would we want to control? Just device creation/management?

SDS: The problem today is that any process that can create device nodes (i.e. has mknod capability and create to chr_file or blk_file) is free to create an alias to any device in a type for which it has create permission, and thus can effectively gain read/write to any device. If only udev ever created device nodes, then this would be a relatively minor concern; we would just need to verify that udev always creates the device node with the correct type and then everything else follows. But in practice, many programs create device nodes, and currently all such programs have to be fully trusted not to misuse that power to gain access to arbitrary devices. What we want is a tighter binding or validation between the label used for checking read/write access and the underlying device. That could be implemented as some kind of associate check between the device node security context and some security context associated with the driver or major/minor or some other identifier in the kernel, or as a separate device access control layer. Not sure of the best approach.

• Crypto policy for domains & object handling.

PM: We need more detail on this item.

• Update performance testing & profiling, try to characterize SELinux performance overhead and identify performance hotspots for improvement.

PM: It would be nice if we could document or script some sort of relatively simple performance measurement as a first step towards regular performance testing.

• Better support for FS whose labelling behaviour is not specified in policy. If nothing from policy just test for xattr support and use it if it is there (in progress at RH, patch reverted due to fuse deadlocks).

PM: Is this inherently not possible or just something that is problematic with FUSE? If the latter, why can't we simply blacklist FUSE?

SDS: FUSE is used widely in distributions (and Android), and the current lack of support for passing through file security contexts prevents granular control of files backed via FUSE filesystems. Also, the fact that the kernel fuse implementation does not convey the process security context to the FUSE userspace daemon makes it impossible to implement any SELinux userspace access controls in the FUSE userspace daemon based on calling process, an issue in e.g. the Android sdcard daemon.