mailing list archives
Re: File system recursion and symlinks: A never-ending story (and how to bring it to an end for me)
From: halfdog <me () halfdog net>
Date: Tue, 31 May 2011 11:47:43 +0000
-----BEGIN PGP SIGNED MESSAGE-----
On Tue, May 31, 2011 at 12:13 AM, halfdog <me () halfdog net> wrote:
... Yes, absolutely correct. Only working through the path using
fstat/openat with O_NOFOLLOW and keeping every dir-fd open would
allow to make sure, that no links are followed -- at the risk of
keeping every dir-fd open? not necessary.
Keeping the last dir-fd open and the fd to the file to modify would be
sufficient when only one file should be modified. When performing
recursion over tree, you will have to open the directories up and down
the tree, which might impede performance.
And if not keeping them open, the first normal open/stat call will be
the first one leading to misery.
These questions are remaining open:
Is the existence of a whole group of symlink/timing vulnerable
applications, that are currently used on symlinks in racy live
systems, a hint, that there is something fundamentally wrong in
it's a hint that directory traversal in a secure manner is not
Of course, but could it be made simpler with additional syscalls, e.g.
OPEN_TRUSTED or OPEN_NOLINKS, that can operate on path components?
just like secure development in general is not trivial.
there are file systems which don't support symlinks or hardlinks.
yet they are also less useful in practice.
Of course, they are useful to map parts of the filesystem. But the
userspace has no simple, secure and atomic means to access the
filesystem. I would wish for an atomic open call using a pathname, that
would check on OS-side:
* That I do not leave one filesystem
* That all path elements and symlinks are owned by me or a user with
* That all the elements cannot be modified by any other user with same
or lower privileges, e.g. due to open permissions (0777)
It would be nice, if the call could also consider the
security-classification of the device, that was specified during mount,
e.g encrypted partition mount = 100, normal partition mount = 0, trusted
nfs = -100, usb = -200 ... and so on. The open does only succeed, if all
elements in the trust chain have security >= 0.
Even if this is bad filesystem/kernel interface design, in the
light of other vulnerabilities, should one care about it, e.g. to
implement a "secure fs syscall"?
you create secure_recurse_dir() to fit all needs, more power to you.
still should not go in syscall or stdlib, perhaps
That means, that tar/rsync/cpio/cp/ls and all applications using those
commands were not designed with security in mind? Or were the developers
not caring or smart enough to do it right?
Please consider also, tar format is POSIX standard since 1988, I do not
know, how old the GNU tar implementation is. But since ages, the read
file inclusion issue was never found during any audits or whatever,
until fixed last year.
PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/