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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 14 Feb 2019 15:14:29 -0800 From: Omar Sandoval <osandov@...ndov.com> To: Dave Chinner <david@...morbit.com> Cc: linux-fsdevel@...r.kernel.org, Al Viro <viro@...iv.linux.org.uk>, kernel-team@...com, linux-api@...r.kernel.org, linux-btrfs@...r.kernel.org, linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net, linux-xfs@...r.kernel.org Subject: Re: [RFC PATCH 0/6] Allow setting file birth time with utimensat() On Fri, Feb 15, 2019 at 09:06:26AM +1100, Dave Chinner wrote: > On Thu, Feb 14, 2019 at 02:00:07AM -0800, Omar Sandoval wrote: > > From: Omar Sandoval <osandov@...com> > > > > Hi, > > > > Since statx was added in 4.11, userspace has had an interface for > > reading btime (file creation time), but no way to set it. This RFC patch > > series adds support for changing btime with utimensat(). Patch 1 adds > > the VFS infrastructure, patch 2 adds the support to utimensat() with a > > new flag, and the rest of the patches add filesystem support; I excluded > > CIFS for now because I don't have a CIFS setup to test it on. > > > > Updating btime is useful for at least a couple of use cases: > > > > - Backup/restore programs (my motivation for this feature is btrfs send) > > - File servers which interoperate with operating systems that allow > > updating file creation time, including Mac OS [1] and Windows [2] > > So you're adding an interface that allows users to change the create > time of files without needing any privileges? I think it'd be reasonable to make this a privileged operation. I didn't for this initial submission for a couple of reasons: 1. The precedent on Mac OS and Windows is that this isn't a privileged operation. 2. I knew there would be different opinions on this either way I went. > Inode create time is forensic metadata in XFS - information we use > for sequence of event and inode lifetime analysis during examination > of broken filesystem images and systems that have been broken into. > Just because it's exposed to userspace via statx(), it doesn't mean > that it is information that users should be allowed to change. i.e. > allowing users to be able to change the create time on files makes > it completely useless for the purpose it was added to XFS for... > > And allowing root to change the create time doesn't really help, > because once you've broken into a system, this makes it really easy > to cover tracks If the threat model is that the attacker has root, then they can overwrite the timestamp on disk anyways, no? > (e.g. we can't find files that were created and > unlinked during the break in window anymore) and lay false > trails.... Fair point, although there's still ctime during the break-in window, which I assume you'd be looking for anyways since files modified during the break-in window are also of interest. 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. Thanks!
Powered by blists - more mailing lists