linux-kernel - Re: [PATCH 07/10] ovl: add initial revalidate support

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] [day] [month] [year] [list]

Date:	Tue, 21 Sep 2010 12:40:56 +1000
From:	Neil Brown <neilb@...e.de>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 07/10] ovl: add initial revalidate support

On Thu, 16 Sep 2010 16:47:29 +0200
Miklos Szeredi <miklos@...redi.hu> wrote:

> On Mon, 06 Sep 2010, NeilBrown wrote:
> > Add dentry_revalidate method and fail validation of either the
> > upper or lower dentry has been renamed or unlinked directly in the
> > otherlying filesystem.
> > This allows such changes to appear promptly in the overlay providing
> > the file isn't currently in use.
> 
> I fixed up some things in the revalidation logic and tested it out.
> There are some unexpected effects, but they boil down to the fact that
> busy directories can't be invalidated.  Mostly it works as expected.
> 
> However, the "rearange directories so that a/b becomes b/a" trick
> still strikes in evil ways.  Consider the following script:
> 
> mkdir /upper/a/b
> cd /mnt/overlay/a
> while true; do
> 	cd b
> 	mv /upper/a/b /upper/b
> 	mv /upper/a /upper/b/a
> 	cd a
> 	mv /upper/b/a /upper/a
> 	mv /upper/b /upper/a/b
> done
> 
> It will create an ever deeper directory tree on the overlay.
> 
> Can this be prevented?  Probably, e.g. lookup should make sure that
> each new directory gets a *unique* set of lower and upper dentries
> (e.g. by creating hash tables indexed by lower and upper dentries).
> 
> Is it worth the trouble?

The only real problem here is that an unprivileged user with direct access
to 'upper' could consume unlimited kernel memory without using a
corresponding mount of storage space (so quotas etc wouldn't stop them).

Maybe the easiest counter-measure to that is to keep track of a 'depth' of
each dentry and disallow lookups that go much beyond PATH_MAX???

Either that or rely in the sysadmin to hide the upper/lower filesystems from
untrusted users.  I particularly see value in sysadmins being able to modify
these filesystem - not so much for 'regular users'.

NeilBrown

> 
> Any other ideas?
> 
> Thanks,
> Miklos
> 
>
--
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/