Re: RFC: Make it practical to ship EVM signatures

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Oct 9, 2017 at 10:51 AM, Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx> wrote:
>> >> I'm not really clear on what attacks are prevented by using the inode
>> >> number. If I'm able to preserve all the other security metadata when
>> >> copying a file, I can just create a hardlink to the original instead
>> >> and have the same outcome.
>> >
>> > The issue is the ability of having different security metadata, not
>> > the same security metadata. (I need to refresh my memory as to hard
>> > links, and whether they can have different security metadata.)
>>
>> If the security metadata is different then copying another
>> security.evm will fail, surely?
>
> The assumption here is that security.ima exists and is included in the
> HMAC calculation.  For files which are not included in the IMA policy,
> the only thing binding the file data and metadata is the i_ino and
> uuid.

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?



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux