On Sun, 2018-01-28 at 16:49 -0500, Theodore Ts'o wrote: > On Sun, Jan 28, 2018 at 10:03:10AM -0800, James Bottomley wrote: > > > > > > OK, so we agree then that what IMA provides: a hash and potential > > signature over the hash is sufficient input for what you want and > > does > > provide existing tooling to achieve it. > > Well, that's not all IMA provides. Remmber, the 'M' in IMA is > *measurement*. IMA was originally about checksuming every single > file that is opened and writing it to a long. You could suppress it > by using SELinux to tag files (using xattrs which are *not* signed) > and then writing an IMA policy which tells IMA to ignore files that > belong to a certain SE Linux tag. This is something that I *don't* > want and today, enabling CONFIG_IMA drags all of this (including > doing text parsing of the IMA policy in the kernel, SELinux, etc.) > into the kernel. That's not actually correct. For instance, it's not how I'm using IMA in the cloud to give me immutability and tamperproofness. In fact, I'm not using IMA with selinux at all. The only connection between them is that they both use xattrs. > One of my other complaints about IMA is that it's an integrated > solution, with a huge amount of complexity. If it was only about > file signing, that would be one thing, but that's actually not the > case today. OK, so I think I need to get a tame IMA developer to explain simply what IMA actually does before we start accusing it of things it doesn't do (or doesn't have to do). > Hence my comment about I don't want fs-verity to have a > dependency on IMA, such that we are forced to drag in all of IMA and > SELinux for anyone who wants to use use fs-verity. > > This is fine; I don't want to have to dictate changes to IMA; I'd > much prefer to avoid the complexity instead of trying to reform it, > since I'm sure the IMA folks will be happy to explain why there are > all sorts of reasons why things have to be done the way it has to be > done. For example, the assertion that the latency hit at open(2) > *must* be there in order to kowtow to Microsoft because of its > Trusted Boot policies; fair enough, but *I* don't care about Trusted > Boot, and it's not fair to impose penalties on all scenarios because > of a desire to keep Microsoft happy just for one particular use case. OK, so I don't believe that to be true either. Secure Boot was something we did based on MS mandated technologies and something *some* people though we had to impose strange policies over to please MS. However, IMA was never part of that secure boot solution, so trying to tar it with the same brush is unfair (and inaccurate). > > 1. Could the signature piece of this be done in the way IMA > > currently > > does file signatures. We all agree "yes" on this, since a > > signed > > mekle hash head is the same size as an existing IMA signature > > and > > therefore does fit into xattrs. > > Well.... not exactly. > > It is fair to say that there are two parts of integrity metadata; and > the Merkle tree can be reconstructed at file install time. I thought we agreed the signature need only be over the head hash of the tree, which means it's the same size as a current IMA signature (because they're both signatures of hashes). I left all questions about how we obtain the entire tree to step 3. > > 2. Could IMA use a merkle tree for hash verification a page at a > > time > > as part of its implementation? I think the answer to this is > > yes, > > except the hook has to be somewhere in the page fault > > mechanism, so > > it would need some exploration and prototyping. > > The way you are formulating things presumes that all of IMA has to be > dragged into any file integrity solution. That's begging the > question. The question I'm poking at is how integrity is enforced. Right at the moment it's a small number of security hooks but they're on the fops gates (exec and the like). To verify a per page hash, they'd have to be in the mm subsystem as well (regardless of whether it's IMA or fs- verity doing it) ... unless you're planning to ignore all the security hooks as well. > As I've mentioned above, IMA has all sorts of complexity > which is currently mandatory, and I'm not volunteering to > disentagling the mess to make it be sane. (And if you don't like > that word, how about, "designed with good taste?") This boils down to IMA is insane so I can't use it. It's an emotional not a technical argument. Can we look at the pieces of IMA that you might be able to use and make an evaluation on that. The hooks, for instance, exist within the kernel when CONFIG_IMA=n. > > 3. Could the merkle tree be cached somehow in the filesystem > > (probably > > as part of the filesystem implementaiton)? You've already > > assumed > > "yes" for this since it's how fs-verity is proposed to work. > > I don't consider this the Merkel tree to a *cache*, however because > if you don't mind a massive latency at file open tme, you can just > use the existing IMA mechanism. So a core part of the design is that > the Merkle file is stored permanently (*not* as a cache) alongside > the file. That's a semantic quibble. I think of it as a "cache" because we can verify and derive the entire tree from the head node. However, doing the derivation costs, so supplying the tree is a shortcut but it's telling us nothing we couldn't have worked out for ourselves (hence it's a cache). We definitely use the base of the tree to verify the file a page at a time. > And if the file is renamed, the Merkle tree should come along > for the ride. > > Whether the Merkle tree is reconstructed as part of the file / > package installation process, or whether the Merkle tree stored as > part of the package or streamed from the app store, etc., is an > implementation detail, and I don't think we need to prescribe one way > of doing things. agreed. > I *do* think though we should allow for possibility where > limitations on the local CPU power is such that it would be > preferable for the Merkle tree to be supplied from a remote server > instead of generated on the local system. > > The problem is you have a specific use case in mind, involving the > Docker client, where you want to store the signature in an xattr, and > then not require any local changes to the Docker client --- and > that's not in my requirements set, and it was *your* statement that > the Docker client MUST NOT be modified which forced where (a) the > Merkle tree must be reconstructed in the kernel, and (b) it must be > triggered by setting the xattr. My goal (the reason I know all this about IMA) is actually to get some integrity and signature verification in containers. Your goal seems to be the same for a non-container use case. I really don't think we need two completely separate mechanisms to achieve the same goal ... it's going to create userspace confusion about which mechanism they're supposed to be using. > My goal is to keep things simple, which means > > * No parsing of the IMA policy as a text input in the kernel > * No Merkle tree construction in the kernel (which is also true of > dm-verity) > * No magic xattr triggering So I don't actually think there's anything here that means we have to have two solutions. > Speaking as a kernel developer, it makes a more sense to keep things > in the kernel, and do as much in userspace as possible --- and if > that means that the Docker client (or the package manager, etc.) > needs a minor change to call the userspace library, that's infinitely > preferable to keeping huge amounts of complexity in non-swappable > kernel memory --- which increases the attack surface of the kernel, > and so on. > > So in my opinion, clean design of the kernel trumps the requirement > of "not one change, not one jot, in the Docker client". OK, bad example on my part, thanks to runc and containerd I don't give much of a toss about the docker client. I care much more about compliance with the container runtime standard. At it's base that has anything you can do to tar is fine because it uses tar to define the image. I buy that we can modify tools easily, but the same doesn't apply to standards. > It could be that the requiremnts of "keep the kernel changes simple" > and "no massive latency at file open time", means that requiremnt > sets of fs-verity and IMA are irreconcilable. Which is fine as far > as I'm concerned. Maybe IMA and fs-verity should be considered > orthogonal solutions. I don't really think that's a good way to go, given they're both mechanisms for enforcing file integrity. James > - Ted >
