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. Sigh, there seems to be some confusion. Initially, when the Integrity Measurement Architecture (IMA) was first upstreamed, it only extended the trusted boot concept of measuring files before use up to the OS, but that was a long time ago. Since then, IMA-appraisal was upstreamed, which extends the secure boot concept of verifying signatures up to the running OS. Both IMA-measurement and IMA-appraisal are policy based. You can enable one, the other, both or none based on rules. The rules can further be constrained based on LSM hooks, or even further constrained based on LSM labels. > 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. 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. Enabling IMA doesn't automatically require SELinux or any other LSM labels. The rule granularity is up to you. > 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. Nobody is forcing you to define a measurement policy, if all you're interested in is signature verification. > > > 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. > > > 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. 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?") The architecture is really quite simple: if (measurement is enabled) do measurement if (signature verification is enabled) do signature verification if (IMA-audit is enabled) add file signature/hash to audit/system log Pick and choose what you're interested in. Mimi > > > 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. 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. 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 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 > > 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". > > 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. > > - Ted >
