linux-kernel - Re: [PATCH] fs: Introducing Lanyard Filesystem

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: <20120819142732.GB23464@ZenIV.linux.org.uk>
Date:	Sun, 19 Aug 2012 15:27:32 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Dan Luedtke <mail@...rl.de>
Cc:	Jochen Striepe <jochen@...ot.escape.de>,
	Marco Stornelli <marco.stornelli@...il.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	lanyfs@...relist.com
Subject: Re: [PATCH] fs: Introducing Lanyard Filesystem

On Sun, Aug 19, 2012 at 05:33:52PM +0200, Dan Luedtke wrote:

> Still wondering if anyone bothers to actually look at the code?

Some obvious notes:
	* unlimited recursion is a killer; here its depth is controlled
by the fs image contents and it's trivial to cook one that would overflow
kernel stack.  Seeing that you want to use it for removable media, that's
a gaping security hole right there
	* unlink() does *not* truncate the file contents; file that had been
opened and unlinked should keep its contents until it's closed.  The same
goes for overwriting rename().
	* while we are at it, neither of those should free the on-disk
inode; again, that should happen only when the inode is evicted.
	* I might be missing something, but copying a bunch of files
with something like cp /foo/* /mnt seems to be guaranteed to create
really lousy binary tree in target directory (they will go in lexicographical
order and you don't seem to rebalance the tree at all)
	* you are really abusing iget() there.  Leaving the locking issues
aside, that's going to get you icache filled with irrelevant stuff.  Moreover,
it's far too heavy a club; allocating and filling struct inode when all you
really need is name and a couple of pointers in the disk block?
	* minor point, but endianness-flipping in place is *the* way to get
hard-to-catch endianness bugs.  foo = cpu_to_le64(foo) is a bloody bad idea;
either use object for host-endian all along, or use it only for (in your
case) little-endian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/