linux-ext4 - Re: [RFC PATCH 0/6] Allow setting file birth time with utimensat()

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]

Date:   Sat, 16 Feb 2019 18:57:45 -0700
From:   Andreas Dilger <adilger@...ger.ca>
To:     Omar Sandoval <osandov@...ndov.com>
Cc:     Dave Chinner <david@...morbit.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>, kernel-team@...com,
        Linux API <linux-api@...r.kernel.org>,
        linux-btrfs <linux-btrfs@...r.kernel.org>,
        linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
        linux-xfs@...r.kernel.org, Theodore Ts'o <tytso@....edu>,
        Jaegeuk Kim <jaegeuk@...nel.org>,
        Steve French <sfrench@...ba.org>
Subject: Re: [RFC PATCH 0/6] Allow setting file birth time with utimensat()

On Feb 14, 2019, at 11:59 PM, Omar Sandoval <osandov@...ndov.com> wrote:
> 
> On Fri, Feb 15, 2019 at 11:16:57AM +1100, Dave Chinner wrote:
>> On Thu, Feb 14, 2019 at 03:14:29PM -0800, Omar Sandoval wrote:
>>> I see a few options, none of which are particularly nice:
>>> 
>>> 1. Filesystems like XFS could choose not to support setting btime even
>>>   if they support reading it.
>>> 2. XFS could add a second, writeable btime which is used for
>>>   statx/utimes when available (it would fit in di_pad2...).
>>> 3. We could add a btime_writable sysctl/mount option/mkfs option.
>> 
>> 4. create time remains a read-only field, and btrfs grows its own
>> special interface to twiddle it in btrfs-recv if it really is
>> necessary.
> 
> I'm curious to hear what the ext4/f2fs/CIFS developers think. If no one
> else wants btime to be mutable, then I might as well make it
> Btrfs-specific. That is, assuming we reach consensus on the Btrfs side
> that btrfs receive should set btime.
> 
>> I'm still not convinced that even backup/restore should be doing this,
>> because there's so much other metadata that is unique even on
>> restored files that it doesn't really make any sense to me to lie
>> about it being created in the past....
> 
> I suppose it depends on how you interpret btime: if it's strictly
> filesystem metadata, then it makes sense that it should be immutable; if
> it's metadata for the user's own purposes, then we should allow setting
> it.

My personal preference is that crtime/btime be read-only information that
tells when the file itself was created in this filesystem, not some added
metadata that is managed by userspace.  There have been many times when
I've needed to know when a file was _actually_ created in the filesystem,
not what mtime/ctime report.

While it may be a bit of a stretch to call this "forensic evidence", making
it hard to change from except via total root compromise by a skilled hacker
is very useful.

If this were to go in (which I'm not in favour of), then there would need to
be a CONFIG and/or runtime knob to turn it off (or better to only turn it on),
similar to how FIPS and other security options can only go in one direction.

Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)