Date: Tue, 31 May 2011 11:47:43 +0000
From: halfdog <me@...fdog.net>
To: coderman <coderman@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: File system recursion and symlinks: A
 never-ending story (and how to bring it to an end for me)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

coderman wrote:
> On Tue, May 31, 2011 at 12:13 AM, halfdog <me@...fdog.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
>> fd-starvation.
> 
> 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
>> that area?
> 
> it's a hint that directory traversal in a secure manner is not
> trivial.

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.

Hear, hear

> 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
higher privileges
* 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 
> libOSWrappersForDummies.so...

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.

- -- 
http://www.halfdog.net/
PGP: 156A AE98 B91F 0114 FE88  2BD8 C459 9386 feed a bee
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFN5NVYxFmThv7tq+4RAqeNAJ0RZNMD1A7BLTwd5h/lT+rsMwC6SACdF3/R
iNTnJnIodTPjcLZRk7PTWgw=
=Hgng
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists