On Mon, 2018-02-19 at 20:02 -0600, Eric W. Biederman wrote: > James Morris <jmorris@xxxxxxxxx> writes: > > > On Mon, 19 Feb 2018, Eric W. Biederman wrote: > > > >> Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> writes: > >> > >> > Files on untrusted filesystems, such as fuse, can change at any time, > >> > making the measurement(s) and by extension signature verification > >> > meaningless. > >> > >> Filesystems with servers? > >> Remote filesystems? > >> Perhaps unexpected changes. > >> > >> Untrusted sounds a bit harsh, and I am not certain it quite captures > >> what you are looking to avoid. > > > > Right -- I think whether you trust a filesystem or not depends on how much > > assurance you have in your specific configuration, rather than whether you > > think the filesystem can be manipulated or not. > > > > There is a difference between: > > > > - This fs has no way to communicate a change to IMA, and; > > > > - This fs could be malicious. > > > > In the latter case, I suggest that any fs could be malicious if the > > overall security policy / settings are inadequate for the threat model, or > > if there are vulnerabilities which allow such security to be bypassed. > > > > Whether a user trusts FUSE on their particular system should be a policy > > decision on the part of the user. The kernel should not be deciding what > > is trusted or not trusted here. > > I believe there has been a good techincal argument made that fuse > mounted by an malicious user can defeat the protections ima is trying to > provide. > > In particular the file could change after the signature of the file has > been verified without ima being alerted. > > As such I think it is very reasonable for ima when a fuse filesystem has > been mounted by an unprivileged user to report that it can not verify > signatures, because IMA can not verify signatures in a meaningful way. > > Now that might be better called SB_I_IMA_UNVERIFIABLE_SIGNATURES. The file signatures are always unverifiable, whether it is mounted by root or an unprivileged user. This flag would always be set. > We may want to complement that flag with SB_I_UNTRUSTED_MOUNTER. > For the times when it is not the global root user who mounts > the filesystem. Ok > So I do think when both conditions are true there very much is a case > for the kernel saying realizing it would be stupid to trust sigantures > it can not reliably verify. Agreed > On the flip side when it really is a trusted mounter, and it is in a > configuration that IMA has a reasonable expectation of seeing all of > the changes it would be nice if we can say please trust this mount. IMA has no way of detecting file change. This was one of the reasons for the original patch set's not using the cached IMA results. Even in the case of a trusted mounter and not using IMA cached results, there are no guarantees that the data read to calculate the file hash, will be the same as what is subsequently read. In some environments this might be an acceptable risk, while in others not. > It would also be nice if I could provide all of this information at > mount time (when I am the global root) with mount options. So I don't > need to update all of my tooling to know how to update ima policy when I > am mounting a filesystem. The latest version of this patch relies on a builtin IMA policy to set a flag. No other changes are required to the IMA policy. This builtin policy could be used for environments not willing to accept the default unverifiable signature risk. Mimi
