lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9c216902-027d-f70f-d896-6d3bb7d6bda9@nod.at>
Date:   Mon, 24 Apr 2017 17:44:50 +0200
From:   Richard Weinberger <richard@....at>
To:     Oleksij Rempel <ore@...gutronix.de>,
        Christoph Hellwig <hch@...radead.org>
Cc:     dedekind1@...il.com, adrian.hunter@...el.com,
        linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, kernel@...gutronix.de
Subject: Re: [PATCH v2 2/3] fs: ubifs: update i_version on inode changes

Oleksij,

Am 12.04.2017 um 09:04 schrieb Oleksij Rempel:
> On Tue, Apr 11, 2017 at 11:08:47PM -0700, Christoph Hellwig wrote:
>> On Wed, Apr 12, 2017 at 08:05:34AM +0200, Oleksij Rempel wrote:
>>> The code seems to confirm it. So i assumed that IMA don't care if
>>> i_version is stored to disk or not. And i_version is the only way
>>> to notify IMA about inode changes.
>>> Since IMA documentation explecitley set i_version as reqieremt, so this
>>> option was provided as well.
>>
>> Maybe IMA doesn't care, but if you set MS_I_VERSION the fs does give
>> a guarantee.  Sp NAK on this patch as-is.
> 
> Ok, it was an expekted NACK :)
> Suddenly right now i don't have good ide to solve it. IMA just won't to
> know if some runtime changes was made to FS. Currently i can image
> fallowing variants:
> - rework IMA

I assumed that you checked that option already. I IMA *really* needs i_version,
we can think of an solution. Adding new filesystem features should be done with
care.

> - add MS_I_TEMP_VERSION and keep i_version using for it.

You mean a non-persistent i_version like fat and exofs use internally?

> - add new variable for external use only. For example: ima_rt_i_version,
>   or some thing like this.

hch will hate this for very good reasons. :-)

> Other ideas?

What about making i_version persistent?
We still have some empty fields in UBIFS' inode data structure.
But first we have to be very sure that we need it.

Artem, do you remember why UBIFS does not store i_version?

Thanks,
//richard

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ