On Mon, 2018-02-26 at 20:08 -0600, Eric W. Biederman wrote: > Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> writes: > > > For local filesystems, the kernel prevents files being executed from > > being modified. With IMA-measurement enabled, the kernel also emits > > audit "time of measure, time of use" messages for files opened for > > read, and subsequently opened for write. > > > > Files on fuse are initially measured, appraised, and audited. Although > > the file data can change dynamically any time, making re-measuring, > > re-appraising, or re-auditing pointless, this patch set attempts to > > differentiate between unprivileged non-init root and privileged > > mounted fuse filesystems. > > > > This patch set addresses three different scenarios: > > - Unprivileged non-init root mounted fuse filesystems are untrusted. > > Signature verification should always fail and re-measuring, > > re-appraising, re-auditing files makes no sense. > > > > Always enabled. > > > > - For privileged mounted filesystems in a "secure" environment, with a > > correctly enforced security policy, which is willing to assume the > > inherent risk of specific fuse filesystems, it is reasonable to > > re-measure, re-appraise, and re-audit files. > > > > Enabled by default to prevent breaking existing systems. > > > > - Privileged mounted filesystems unwilling to assume the risks and > > prefers to fail safe. > > > > Enabled based on policy. > > I really like the way the flags work in this patchset. > > There is a lot of other nit-picking and bike-shedding I would like to > do. However those are details specific to IMA. So my opion really > doesn't count. > > Those two flags set as you have them in the last patch make it possible > to slightly alter details of when they get set, that are in the perview > of filesystems without having too big a debate over them. > > The changes I imagine most easily are: > In fuse_fill_super: > if (!fc->allow_other) > sb->s_iflags |= SB_I_UNTRUSTED_MOUNTER; Right, as described, above, as the 2nd senario. > > In sget_user_ns: > if (sb->s_user_ns != &init_user_ns) > sb->s_iflags |= SB_I_UNTRUSTED_MOUNTER; The filesystems would then only set SB_I_IMA_UNVERIFIABLE_SIGNATURE. > > My biggest nitpick is I would be inclined to flip the sense of the > unverifiable_sigs policy. By default not trust and trust only if > a special command line option was given. But I realize this could > run into backwards compatibility concerns. And it is IMA specific so > not really my call. The boot command line policy option forces the system to fail safe. Reversing the default to fail unverifiable_sigs and only allow them based on policy, would not be a simple command line option, but would require a per filesystem rule. I agree with you, but as we're not breaking existing userspace, our only option is to audit/log the concern, as suggested by Linus in other threads. It would be nice if we could audit/log it once per each mount. > > But the important part is what winds up in the core of ima. Baring > typo's I think you have something we can all live with. > > So double check yourself and let's start getting this merged. Sure. Mimi
