On 05/ 6/10 02:05 AM, Garrett D'Amore wrote:
Thanks for the clarification. The concern I have is that while an app
can achieve the same resource exhaustion by opening multiple files, we
*do* have ways to limit the total number of open files that an
applications is permitted to have. By setting large values here, and
then opening and closing TCP sockets repeatedly, it seems like these
options might provide a (worsened) way to bypass those resource
limitations.
The options do not affect the total number of open file
descriptors an app can have. Suppose there were really
a way now for an app to "kill" a system by opening/closing
TCP sockets repeatedly. Why can these options make things
worse? The system is already dead, is there a worse
situation than this?
Admittedly, the damage here is limited to DoS executed from someone who
already has gained arbitrary code execution capability on the system,
but it still seems like this could be strengthened up a bit.
The key question is if there is a new DoS these options
introduce which cannot be done without them. Please
elaborate the new attack.
The existence of the options in current code doesn't necessarily mean
that the existing code doesn't suffer from the same flaw, and exposing
it more broadly by documenting the behavior may worsen the situation.
As I mentioned in the previous mail, the two old options are
documented in other OSes, such as HP-UX. So it is not like
only folks with access to the Solaris source can know or use
them. I am not saying that they have no flaw. But I don't
understand the concern of making the situation worse by
documenting them by us. They are never a secret. I can't
see how one additional document can suddenly enlighten some
hostile folks to do harm to some Solaris systems which they
don't know before.
--
K. Poon.
[email protected]
_______________________________________________
opensolaris-arc mailing list
[email protected]
