IMA & truncate

IMA & truncate

[Dmitry Kasatkin]

Hi,

I have discovered one IMA related issue.

IMA file hash is re-calculate if needed on file close.

It works with ftruncate(fd, length) syscall, because it operates on
"opened" file.
Recalculation is happening on file close.

truncate(path, length) syscall works with path and no file open/close
takes place.
Recalculation does not happen.
IMA denies file access later.

It looks like vfs_truncate() should possibly call IMA to recalculate the
hash.

- Dmitry

Re: IMA & truncate

[Javier González]

[-- Attachment #1: Type: text/plain, Size: 2162 bytes --]

Hi,

> I have discovered one IMA related issue.
> 
> IMA file hash is re-calculate if needed on file close.
> 
> It works with ftruncate(fd, length) syscall, because it operates on
> "opened" file.
> Recalculation is happening on file close.
> 
> truncate(path, length) syscall works with path and no file open/close
> takes place.
> Recalculation does not happen.
> IMA denies file access later.
> 
> It looks like vfs_truncate() should possibly call IMA to recalculate the
> hash.

I have had the same issue in an integrity module I am working on to move the hash (and generally encryption) operations to a secure processor (e.g., TrustZone).
After a discussion with Al Viro I was convinced that file_close is not the right place to associate a hook in order to recalculate the hash.

I am now using the LSM hook associated with vfs_truncate to recalculate the hash and it seems to work good. I am still running some performance tests to calculate the overhead of attacking an operation here, so I don’t have data yet. 

Best,

-------------------------------------------------/--
Javier González

IT University of Copenhagen
Rued Langgaards Vej 7, 2300
København S, Danmark 
Office: 4D23

http://javigon.com/
Skype: javigon.napster
(+45)31376927

-------------------------------------------------/--

On 6 May 2014, at 15:32, Dmitry Kasatkin <d.kasatkin@samsung.com> wrote:

> Hi,
> 
> I have discovered one IMA related issue.
> 
> IMA file hash is re-calculate if needed on file close.
> 
> It works with ftruncate(fd, length) syscall, because it operates on
> "opened" file.
> Recalculation is happening on file close.
> 
> truncate(path, length) syscall works with path and no file open/close
> takes place.
> Recalculation does not happen.
> IMA denies file access later.
> 
> It looks like vfs_truncate() should possibly call IMA to recalculate the
> hash.
> 
> - Dmitry
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

Re: IMA & truncate

[Al Viro]

On Tue, May 06, 2014 at 04:32:27PM +0300, Dmitry Kasatkin wrote:
> Hi,
> 
> I have discovered one IMA related issue.
> 
> IMA file hash is re-calculate if needed on file close.
> 
> It works with ftruncate(fd, length) syscall, because it operates on
> "opened" file.
> Recalculation is happening on file close.
> 
> truncate(path, length) syscall works with path and no file open/close
> takes place.
> Recalculation does not happen.
> IMA denies file access later.
> 
> It looks like vfs_truncate() should possibly call IMA to recalculate the
> hash.

Who said that it has permissions to read the file?  Reread truncate(2)
manpage; it requires the file to be *writable* for caller, but it doesn't
need it to be readable.

Re: IMA & truncate

[Mimi Zohar]

On Tue, 2014-05-06 at 17:59 +0100, Al Viro wrote: 
> On Tue, May 06, 2014 at 04:32:27PM +0300, Dmitry Kasatkin wrote:
> > Hi,
> > 
> > I have discovered one IMA related issue.
> > 
> > IMA file hash is re-calculate if needed on file close.
> > 
> > It works with ftruncate(fd, length) syscall, because it operates on
> > "opened" file.
> > Recalculation is happening on file close.
> > 
> > truncate(path, length) syscall works with path and no file open/close
> > takes place.
> > Recalculation does not happen.
> > IMA denies file access later.
> > 
> > It looks like vfs_truncate() should possibly call IMA to recalculate the
> > hash.
> 
> Who said that it has permissions to read the file?  Reread truncate(2)
> manpage; it requires the file to be *writable* for caller, but it doesn't
> need it to be readable.

Al, you're not going to like this, but ima_calc_file_hash() calls
ima_calc_file_hash_tfm(), which already sets/unsets FMODE_READ in order
to calculate the file hash.

Mimi

Re: IMA & truncate

[Al Viro]

On Tue, May 06, 2014 at 02:39:17PM -0400, Mimi Zohar wrote:

> Al, you're not going to like this, but ima_calc_file_hash() calls
> ima_calc_file_hash_tfm(), which already sets/unsets FMODE_READ in order
> to calculate the file hash.

And if it happens to be on NFS and server says "no reads for you"?

Re: IMA & truncate

[Dmitry Kasatkin]

On 6 May 2014 22:11, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Tue, May 06, 2014 at 02:39:17PM -0400, Mimi Zohar wrote:
>
>> Al, you're not going to like this, but ima_calc_file_hash() calls
>> ima_calc_file_hash_tfm(), which already sets/unsets FMODE_READ in order
>> to calculate the file hash.
>
> And if it happens to be on NFS and server says "no reads for you"?

Sorry for repost. Lousy Android gmail client is not able to send with
plain text, even with reply.

IMA works by policy. It ignores non-local file systems by default.

But if someone still tries to enable nfs in the custom policy, it
might get into such situation. But then there are other issues like
security xattrs. Anyone using ima needs to be aware what he does.


> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Thanks,
Dmitry

Re: IMA & truncate

[Dmitry Kasatkin]

On 6 May 2014 19:59, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Tue, May 06, 2014 at 04:32:27PM +0300, Dmitry Kasatkin wrote:
>> Hi,
>>
>> I have discovered one IMA related issue.
>>
>> IMA file hash is re-calculate if needed on file close.
>>
>> It works with ftruncate(fd, length) syscall, because it operates on
>> "opened" file.
>> Recalculation is happening on file close.
>>
>> truncate(path, length) syscall works with path and no file open/close
>> takes place.
>> Recalculation does not happen.
>> IMA denies file access later.
>>
>> It looks like vfs_truncate() should possibly call IMA to recalculate the
>> hash.
>
> Who said that it has permissions to read the file?  Reread truncate(2)
> manpage; it requires the file to be *writable* for caller, but it doesn't
> need it to be readable.

Sorry for repost. Lousy Android gmail client is not able to send with
plain text, even with reply.

This is the same case as for normal file close.
IMA will do file reading for the purpose of calculating a hash, even
file was opened for writing only. File reading is done when the last
writer closes the file and it is protected by mutex. Subsequent file
open is delayed by the mutex.

> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Thanks,
Dmitry