В Mon, 09 Oct 2017 17:40:53 -0400 Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> пишет: > [Cc'ing Dmitry Kasatkin] > > On Tue, 2017-10-10 at 00:33 +0300, Mikhail Kurinnoi wrote: > > В Mon, 09 Oct 2017 17:10:49 -0400 > > Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> пишет: > > > > > On Mon, 2017-10-09 at 23:23 +0300, Mikhail Kurinnoi wrote: > > > > В Mon, 09 Oct 2017 14:40:41 -0400 > > > > Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> пишет: > > > > > > > > > On Mon, 2017-10-09 at 11:18 -0700, Matthew Garrett wrote: > > > > > > On Mon, Oct 9, 2017 at 11:15 AM, Mimi Zohar > > > > > > <zohar@xxxxxxxxxxxxxxxxxx> wrote: > > > > > > > On Mon, 2017-10-09 at 10:59 -0700, Matthew Garrett > > > > > > > wrote: > > > > > > >> Ok, that makes sense. But for cases where we do have > > > > > > >> security.ima, the inode doesn't seem to provide > > > > > > >> additional security but does make deployment more > > > > > > >> difficult. Does supporting this use case seem > > > > > > >> reasonable? > > > > > > > > > > > > > > Yes! > > > > > > > > > > > > Excellent. This means defining a new signature type - the > > > > > > two options seem to be Mikhail's portable format, or the > > > > > > approach I took of having the signature define which > > > > > > metadata is included. Do you have a preference? > > > > > > > > > > We now understand that as long as the EVM signature includes > > > > > security.ima, it is safe not to include the i_ino/uuid. This > > > > > new format can be written to disk. > > > > > > > > But, isn't this mean we could have this scenario of offline > > > > manipulations: > > > > 1) store old file with xattrs; > > > > 2) wait; > > > > 3) replace new file with fixed exploits on old one. > > > > > > > > Since we don't have directory tree protection yet and we don't > > > > use i_ino, someone could reuse old files more easy during > > > > offline manipulations. Right? > > > > > > As long as the new EVM signature format requires the existence of > > > a security.ima xattr, I don't see how. The new EVM signature > > > format would not be replaced with an HMAC. > > > > > > I understood the idea. > > > > Looks like portable EVM format support proposed by Matthew, could be > > easy realized. Probably, will be good idea add only this one, test > > it, and later add immutable EVM format and portable EVM format that > > converted into HMAC (that I proposed in patch set)? > > > > If no one ask for portable EVM format that converted into HMAC, do > > we really need push all in one bunch? > > It looks like Dmitry already defined a new "immutable" EVM signature > format in ima-evm-utils and posted the corresponding patch to linux- > ima-devel a long time ago. > > The new "immutable" EVM signature doesn't include the i_ino or > generation. Yes. Btw, Dmitry's patch is the base of proposed by me "portable" version support patch: https://sourceforge.net/p/linux-ima/mailman/message/35587348/ since for portable format we use same idea - EVM signature format without i_ino/generation/uuid. Plus, that was the reason for keep for "portable" format signature version number "3", since Dmitry already did all changes in ima-evm-utils, portable format could be tested. In the same time, I proposed "immutable" EVM signature, that identically to current EVM digsig (with i_ino,...), but can't be changed into HMAC. This patch don't related to Dmitry's "immutable" EVM signature format support: https://sourceforge.net/p/linux-ima/mailman/message/35601151/ I didn't really work on "immutable" EVM signature, only "portable" version support needs was taken into account. For now, we don't have ready for upstream "immutable" EVM signature format support patch. Both, Dmitry's and my, patches need more work in order to prevent file's data changes (in case of IMA hash) and metadata changes for files signed by "immutable" EVM xattr (same idea as we already have for IMA digsig, that prevent file's data change). -- Best regards, Mikhail Kurinnoi
