linux-kernel - Re: [PATCH] procfs: make /proc style symlinks behave like "normal" symlinks

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 19 Nov 2009 13:31:16 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Jeff Layton <jlayton@...hat.com>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	pavel@....cz, Miklos Szeredi <miklos@...redi.hu>,
	Trond Myklebust <trond.myklebust@....uio.no>
Subject: Re: [PATCH] procfs: make /proc style symlinks behave like "normal" symlinks

Jeff Layton <jlayton@...hat.com> writes:

> Thanks, that makes sense. The raciness was evident once you pointed it
> out, so I think you're correct that we can't take this approach.
>
> Adding the missing revalidations is fine, but I don't believe that
> helps to fix Pavel's issue. I'll go back and take a more careful look
> at the suggestion that Miklos made and see whether it makes sense to
> implement a new FS_* flag for this, and see what it'll take to fix
> Pavel's issue.

Fundamentally today the proc/fd links are special kind of hard link,
the same kind as bind mounts and have the same issues crop up.  Given
that definition there is absolutely nothing wrong their behavior.

The fact that we create the proc/fd implicitly is a little bit
surprising and the source of the concerns.  So far the cost of
changing the semantics and breaking potentially valid user space
applications appears to outweigh the potential security benefit.

I can't find a reason for the missing revalidate.  It is easy to get
into a state where the destination of of a proc/fd/N symlink or
a file bind mount has been deleted, and everything continues to
work.  You can even open d_dropped file descriptors.

If you want confirmation just do:

$ mkdir toy
$ cd toy
$ echo 123 > f
$ touch g
$ sudo mount --bind ./f ./g
$ sleep 3000 < g &
$ child=$!
$ ls -l /proc/$child/fd/0
lr-x------ 1 eric eric 64 2009-11-19 13:27 /proc/28797/fd/0 -> /tmp/toy/g
$ rm f
$ ls -l /proc/$child/fd/0
lr-x------ 1 eric eric 64 2009-11-19 13:27 /proc/28797/fd/0 -> /tmp/toy/g (deleted)
$ cat /proc/$child/fd/0
123
$ kill $child
$ sudo umount ./g
$ cat g
$ rm g

What we can't do right now is revalidate the source of a mount as
that will make it impossible to find the vfsmount to unmount it.

Eric
--
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/