On Mon, 2017-10-02 at 10:09 -0700, Matthew Garrett wrote: > On Sat, Sep 30, 2017 at 7:36 PM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 2017-09-29 at 13:09 -0700, Matthew Garrett wrote: > >> If the security metadata is different then copying another > >> security.evm will fail, surely? > > > > A copy of the file could exist with a valid hmac on the system with > > different security xattrs. Without the inode/uuid, the xattrs could > > be cut & pasted. > > So we have /usr/bin/a and /usr/bin/b, which are identical but have > different security contexts. Outside some unusual cases, if I have the > ability to modify /usr/bin/b's security.evm, I can delete /usr/bin/b. > I can then also just do: > > ln -f /usr/bin/a /usr/bin/b > > and /usr/bin/b now has the same security context as /usr/bin/a, > including security.evm. All true, but instead of /usr/bin/a and /usr/bin/b, which most likely have the same LSM labels, think of it in terms of /home/bin/b. An offline attack wouldn't require access to the EVM HMAC key or any privileges. Mimi
