This is to keep track of the keylime review issue 2 a):

 ### a) `check_mounted()` Function Logic can be Fooled by Unprivileged
unts

 The `check_mounted()` function in `secure_mount.py` attempts to make sure
 that a "secure" tmpfs is mounted at `/var/lib/keylime/secure` to store
 sensitive
 data on that never gets written to disk. To do so the function parses the
 output of the `mount` utility to determine whether this file system is
ready
 mounted at the desired location.

 There can exist the possibility of unprivileged users performing certain
unt
 operations, one of the most prominent examples being the `fusermount`
 setuid-root binary for mounting FUSE file systems. In view of this parsing
 mount table output needs prudence. I described the basic issue previously
 already in another report [1].

 The following is a reproducer using `fusermount` that shows the basic local
 attack vector:

     user$ export _FUSE_COMMFD=0
     user$ fusermount some/path/ -ononempty,fsname="tmpfs on
 /var/lib/keylime/secure"

 This will fool the parsing logic in `check_mounted()` and thus the function
 assumes that the "secure" tmpfs is already mounted, while it actually
n't.
 Thus this will allow a local attacker on the system to prevent this
curity
 feature to be effective, *if* the local attacker manages to create such a
 mount
 entry before the `keylime_agent` runs.

 The attack vector can also be used to perform a local DoS against
 `keylime_agent` by claiming a different `fsname` than tmpfs.
heck_mounted()`
 will throw an Exception in this case and the agent won't start.

 On a side note there are calls to `secure_mount.mount()` spread throughout
e
 Keylime codebase (for example three times in `keylime_agent.py`, two times

 `tpm_main.py` and two times in `ca_impl_cfssl.py`. There is no code to
lean
 up* this mount again, however. So it potentially leaves behind a stale
unt
 after services are shutdown. Furthermore if multiple Keylime processes
ould
 operate in parallel this could result in a race condition where the
ecure"
 tmpfs is mounted twice, in the worst case mounting a fresh tmpfs over
 previously stored content there.

 My recommendation is to parse the `/proc/self/mountinfo` pseudo file for
unt
 table information instead. Whitespace is specially encoded in this file.
 Furthermore the responsibility of mounting and unmounting this file system
 should be more clearly defined during startup/shutdown of processes and
ybe
 a reference counting / locking scheme to prevent race conditions should be
 used.

 [1]: https://www.openwall.com/lists/oss-security/2020/06/04/5