linux-kernel - Re: [PATCH 0/6 v7] overlay 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]

Date:	Tue, 22 Mar 2011 20:56:15 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Al Viro <viro@...IV.linux.org.uk>
CC:	miklos@...redi.hu, torvalds@...ux-foundation.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, apw@...onical.com, nbd@...nwrt.org,
	neilb@...e.de
Subject: Re: [PATCH 0/6 v7] overlay filesystem - request for inclusion

On Tue, 22 Mar 2011, Al Viro wrote:
> On Tue, Mar 22, 2011 at 07:58:17PM +0100, Miklos Szeredi wrote:
> 
> > > >  and its protection against renames is
> > > > nowhere near enough. ??I might be missing something subtle, but...
> > 
> > Protection is exactly as for userspace callers.  AFAICT.
> 
> BTW, what filesystems can act as upper layers and how are you going to
> prevent modifications of upper layer in normal way?  It is mounted,
> after all, or you would be unable to find it when mounting overlayfs.
> And it might be mounted in any number of places, not all even visible to
> you...  I realize that you have it listed as a problem, but do you have
> any ideas on how to deal with that?

Yes, I have some patches, but decided that that should be a separate
set, once the basics are ironed out.

Since the locking guarantees are separated on the upper/lower fs from
the overlayfs, allowing modification is not a huge problem.  The worst
that can happen is that an attacker who has access to both the overlay
and the upper or lower fs then can "build" an arbitrarily deep
directory tree on the overlayfs.  Not a big issue.  There won't be
deadlocks or filesystem corruption.

> If you allow NFS as upper layer, you really have a problem; with this
> approach you probably want to prevent that very forcibly.  Not that
> your open() handling would work correctly with NFS, even with no modifications
> from other clients or from server...

Upper layer doesn't work on NFS for multiple reasons.

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/