On Sun, 12 May 2002, Elladan wrote:
> His test was different.
>
> He opened a file in a legal situation (shell can create a new file), and
> then forked off a suid process over and over with the stdout of that
> process set to a dup of the shell's already open fd.
>
> It's perfectly legal for the shell to sit around with a file open and
> pass it off to a child, even if the disk is full.
>
> It's also perfectly legal for root to write to the fd, even if the disk
> is full (for normal users).
>
> It just happens that the suid program wasn't the one who chose what file
> it was going to write stdout to - the shell did.
>
> Thus, the security violation.
<shrug> relying on 5% in security-sensitive setup is *dumb*.
In that case you need properly set quota (better yet, no lusers with write
access anywhere on that fs)..
There are worse holes problems 5% rule. E.g. you can create a
file with hole, mmap over that hole, dirty the pages and exit. Guess
who ends up writing them out? Right, kswapd. Which is run as root.
No suid applications required...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 14 2002 - 12:00:18 EST