linux-kernel - Re: [PATCHv2 1/5] VFS: DazukoFS, stackable-fs, file access control

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: <86eiy1v27b.fsf@johno.fn.ogness.net>
Date:	Sat, 14 Feb 2009 09:43:04 +0100
From:	John Ogness <dazukocode@...ess.net>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	Jan Engelhardt <jengelh@...ozas.de>, linux-kernel@...r.kernel.org,
	malware-list@...ts.printk.net, eparis@...hat.com,
	hch@...radead.org, alan@...rguk.ukuu.org.uk
Subject: Re: [PATCHv2 1/5] VFS: DazukoFS, stackable-fs, file access control

On 2009-02-13, Al Viro <viro@...IV.linux.org.uk> wrote:
>> You could write an additional mount helper (and putting that into
>> /sbin/mount.dazukofs) that does all the security checks:
>> 
>>  - that the device is the same as mountpoint
>>  - that the device belonging to the underlying '/mnt' is not
>>    mounted anywhere else (in this namespace, at least)
>>  - exit(1) otherwise
>> 
>> Sure, it may not protect against all the cases Al can come up with,
>> but it is better than having nothing.
>
> It's still racy, at the very least.  Folks, seriously, you can not
> rely on the underlying tree being inaccessible elsewhere.  Anything
> that does stacking has to cope with that possibility; it's not
> bypassable by userland helpers.

Indeed. As long as the stackable filesystem is synchronizing with the
lower layer before doing read actions and synchronizes after all
actions, there should be no problem.

Currently I see a problem when a new directory is created directly on
the lower mount (rather than through the stackable filesystem). A
refcount for "." as seen from the stackable filesystem is then
incorrect. I will investigate this.

And I will look to see why there is any danger at all. There should
not be.

John Ogness
--
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/