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 Subscription Page
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.

##New Items

• Mark the LSM hook structure as read only post-init
• See the Openwall Kernel Hardening archive patchset for details.
• Allow a domain to have a bounded relationship with multiple domains
• The bounded domain transition restriction when NNP is enabled is resulting in an increase in requests for bounded domain transitions in policy and the current 1-to-1 bounding relationship is starting to be a limiting factor. (sds: I don't really agree with this one.)
• Improved coverage in the SELinux testsuite
• https://github.com/SELinuxProject/selinux-testsuite
• Among other things, the SELinux testsuite is used as a regression test and having full/improved coverage of the SELinux access controls would be very helpful.
• Labeling and access controls for namespace operations
• Support for RFC5570, aka CALIPSO
• http:https://tools.ietf.org/html/rfc5570 (done?)
• Proper support for SCTP
• https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol
• RFC patchset from Richard Haines
  • https://marc.info/?l=linux-sctp&m=142219887901738&w=2
• Access controls for generic AF_INET/AF_INET6 traffic and SOCK_RAW sockets
• Access controls for AF_VSOCK sockets
• http:https://lxr.free-electrons.com/source/net/vmw_vsock/af_vsock.c
• Add netmasks to the SELinux network node cache
• Add addresses to the SELinux network port object to match the normal triple (addr/proto/port) to improve the connect() and bind() access controls
• Display bad/deferred file labels in AVC audit records
• Add the FD number in AVC records generated by flush_unauthorized_files()/file_has_perm() to make life easier for the policy developers (sds - why is this helpful?)
• 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
• Investigate SELinux security policy for cgroups
• https://en.wikipedia.org/wiki/Cgroups
• Investigate supporting both SOL_IP/IP_PASSEC and SOL_SOCKET/SO_PASSEC on both datagram and stream sockets
• LSM/SELinux hooks for bus1
• bus1 seems to be on a path to upstreaming. The bus1 developers are including a set of LSM hooks based on the binder hooks and discussions with them; we will ultimately need to validate those hooks and implement them for SELinux, along with corresponding policy changes.

##Carryover Items from the Old List

• Fix signal inheritance controls (possibly drop some or all, or only enforce in policy for certain domains).

• Add a 'map' check on mmap so that we can distinguish memory mapped access (since it has different implications for revocation) When a file is opened and then read or written via syscalls like read(2)/write(2), we revalidate access on each read/write operation via selinux_file_permission() and therefore can revoke access if the process context, the file context, or the policy changes in such a manner that access is no longer allowed. When a file is opened and then memory mapped via mmap(2) and then subsequently read or written directly in memory, we presently have no way to revalidate or revoke access. The purpose of a separate map permission check on mmap(2) is to permit policy to prohibit memory mapping of specific files for which we need to ensure that every access is revalidated, particularly useful for scenarios where we expect the file to be relabeled at runtime in order to reflect state changes (e.g. cross-domain solution, assured pipeline without data copying).

• 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.

• Expand selinux-testsuite as a full regression testuite for every permission & class.

• 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.

• Better validation of classes/perms on policy reload. Warn if any permissions are defined in a kernel class in the policy that are not defined in the kernel's classmap.

PM: Is this still a problem? I haven't checked lately.

SDS: We warn on classes/perms defined in the kernel classmap that are not defined in the policy being loaded (and handle them in accordance with handle_unknown=allow|deny|reject). But we don't do the reverse. So you can silently load a policy that defines and uses some new kernel class or permission and there won't be any indication that the kernel doesn't know about it. OTOH, we rarely will want to fail in that scenario as it is common for policy to pick up new classes/perms before they show up in the currently used kernel.