linux-kernel - Re: [PATCH v3 0/7] User namespace mount updates

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: <564B79B1.3040207@gmail.com>
Date:	Tue, 17 Nov 2015 14:02:09 -0500
From:	Austin S Hemmelgarn <ahferroin7@...il.com>
To:	Al Viro <viro@...IV.linux.org.uk>,
	Seth Forshee <seth.forshee@...onical.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-bcache@...r.kernel.org, dm-devel@...hat.com,
	linux-raid@...r.kernel.org, linux-mtd@...ts.infradead.org,
	linux-fsdevel@...r.kernel.org,
	linux-security-module@...r.kernel.org, selinux@...ho.nsa.gov,
	Serge Hallyn <serge.hallyn@...onical.com>,
	Andy Lutomirski <luto@...capital.net>,
	linux-kernel@...r.kernel.org, Theodore Ts'o <tytso@....edu>
Subject: Re: [PATCH v3 0/7] User namespace mount updates

On 2015-11-17 12:55, Al Viro wrote:
> On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:
>
>> Shortly after that I plan to follow with support for ext4. I've been
>> fuzzing ext4 for a while now and it has held up well, and I'm currently
>> working on hand-crafted attacks. Ted has commented privately (to others,
>> not to me personally) that he will fix bugs for such attacks, though I
>> haven't seen any public comments to that effect.
>
> _Static_ attacks, or change-image-under-mounted-fs attacks?
To properly protect against attacks on mounted filesystems, we'd need 
some new concept of a userspace immutable file (that is, one where 
nobody can write to it except the kernel, and only the kernel can change 
it between regular access and this new state), and then have the kernel 
set an image (or block device) to this state when a filesystem is 
mounted from it (this introduces all kinds of other issues too however, 
for example stuff that allows an online fsck on the device will stop 
working, as will many un-deletion tools).

The only other option would be to force the FS to cache all metadata in 
memory, and validate between the cache and what's on disk on every 
access, which is not realistic for any real world system.

It's unfeasible from a practical standpoint to expect filesystems to 
assume that stuff they write might change under them due to malicious 
intent of a third party.  Some filesystems may be more resilient to this 
kind of attack (ZFS and BTRFS in some configurations come to mind), but 
a determined attacker can still circumvent those protections (on at 
least BTRFS, it's not all that hard to cause a sub-tree of the 
filesystem to disappear with at most two 64k blocks being written to the 
block device directly, and there is no way that this can be prevented 
short of what I suggest above).

Download attachment "smime.p7s" of type "application/pkcs7-signature" (3019 bytes)