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. Mimi
