On 4/8/2020 3:19 AM, Tushar Sugandhi wrote: > The goals of the kernel integrity subsystem are to detect if files have > been accidentally or maliciously altered, both remotely and locally, > appraise a file's measurement against a "good" value stored as an > extended attribute, and enforce local file integrity [1]. > > To achieve these goals, IMA subsystem measures several in-memory > constructs and files. > > We propose to measure constructs in dm-crypt and selinux to further > enhance measuring capabilities of IMA. > > If there is existing or planned work to measure dm-crypt and selinux > constructs, we would like to contribute to that. > > dm-crypt is a subsystem used for encryption of the block device, which > is essential for ensuring protection of data and secrets at rest. > > Measuring encryption status of the device will ensure the device is not > maliciously reporting false encryption status - thus, it can be > entrusted with sensitive data to be protected at rest. > > SELinux is an implementation of mandatory access controls (MAC) on > Linux. Mandatory access controls allow an administrator of a system to > define how applications and users can access different resources - such > as files, devices, networks and inter-process communication. With > SELinux an administrator can differentiate a user from the applications > a user runs [2]. > > Measuring SELinux status and various SELinux policies can help ensure > mandatory access control of the system is not compromised. > > Proposal: > --------- > A. Measuring dmcrypt constructs: > We can add an IMA hook in crypt_ctr() present in > drivers/md/dm-crypt.c, so that IMA can start measuring the status of > various dm-crypt targets (represented by crypt_target struct - also > defined in dm-crypt.c). > The mapping table[3] has information of devices being encrypted > (start sector, size, target name, cypher, key, device path, and > other optional parameters.) > e.g. > 0 417792 crypt serpent-cbc-essiv:sha256 > a7f67ad520bd83b9725df6ebd76c3eee 0 /dev/sdb 0 1 allow_discards > > We can pass various attributes of mapping table to IMA through a key > value pair of various dmcrypt constructs. > > Proposed Function Signature of the IMA hook: > void ima_dmcrypt_status(void *dmcrypt_status, int len); > > B. Measuring selinux constructs: > We propose to add an IMA hook in enforcing_set() present under > security/selinux/include/security.h. > enforcing_set() sets the selinux state to enforcing/permissive etc. > and is called from key places like selinux_init(), > sel_write_enforce() etc. > The hook will measure various attributes related to selinux status. > Majority of the attributes are present in the struct selinux_state > present in security/selinux/include/security.h > e.g. > $sestatus > SELinux status: enabled > SELinuxfs mount: /sys/fs/selinux > SELinux root directory: /etc/selinux > Loaded policy name: default > Current mode: permissive > Mode from config file: permissive > Policy MLS status: enabled > Policy deny_unknown status: allowed > Memory protection checking: requested (insecure) > Max kernel policy version: 32 > > The above attributes will be serialized into a set of key=value > pairs when passed to IMA for measurement. > > Proposed Function Signature of the IMA hook: > void ima_selinux_status(void *selinux_status, int len); > > Please provide comments\feedback on the proposal. TL;DR - Why make this SELinux specific? Integrating IMA and SELinux is a layering violation at best. Why isn't this ima_lsm_status(void *lsm_status, int len)? Or, better yet, how about ima_lsm_status(char *name, void *value, int len), and you pass each name/value pair separately? That makes the interface generally useful. Believe it or not, there *ARE* security modules that are not SELinux. > > Thanks, > Tushar > > [1] https://sourceforge.net/p/linux-ima/wiki/Home/ > [2] https://selinuxproject.org/page/FAQ > [3] https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt
