On Tue 2009-10-27 21:19:19, Marco Verschuur wrote:
> My buy.. :-( I persumed a re-use of the read-only FD, but that's not
> the case.
>
> I replayed it on a test-box and did some strace meanwhile and also
> took a look
> at the sourcecode of kernel/fs/proc.
>
> It seems that the /proc filedescriptor is directly referring the
> file inode
> When creating this proc-entry the user guest did have access to the
> file and the path via tmp,
> therefore a successfull filedescriptor straight to the file inode is
> being created, while checking
> th entire path towards the file.
>
> Although closing the path to the file, the actual file is made world
> writable due to the file permissions being 666.
> When guest does the "echo got you > /proc/self/fd/3" the /proc
> filedescriptor (which directly refers the file inode)
> is opened in O_WRONLY. So user guest is able to write the file.
> IMHO; no bug or security issue, just a misunderstanding of the
> mechanism...
Well, existing unix mechanisms would not allow writing to that
file. So yes, it works as authors intended, but I believe it is
misdesigned and security problem.
The /proc/self/fd/X appears to be a symlink, but it is not; it
operates on underlying objects directly. And IMNSHO it should honor
restrictions opened filedescriptors have, like append-only or
read-only.
(Or alternatively, it could be fixed to behave like real symlinks. But
that would break /proc/*/fd/ on deleted files).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
