On 05/ 5/10 11:32 AM, Kacheong Poon wrote:
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?
My point was that these timers could affect the resources that are
consumed on the system *after* a socket is closed. Ultimately, that
means that any limits already in existence that limit open files won't
necessarily apply to these timers.
While these timers don't necessarily *create* a *new* weakness, my
concern is that increasing the value of the timers may make it *easier*
for a malicious program to create a DoS situation.
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.
Its not new.. its a situation where the DoS I described above can be
*easier*. I'm not sure just how *much* easier it is, but that's the
nature of the question I'm asking.
If the networking and security folks have looked at this problem in
particular, and decided it is a non-issue (or that I'm misunderstanding
something here), then I'm satisfied. I'm simply asking the question,
rather than insisting on a change or declaring the state busted.
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.
Certainly you're right -- security through obscurity is no security at
all. Still, if we're going to document this functionality, then we
ought (IMO) to at least *try* to make sure that they don't create a
weakness in the system. It may well be that the risk is acceptable --
I'm pointing out my concern here, and am willing to live with the
results of an informed decision, provided the decision is itself
"informed" and made by the people with the knowledge to know whether the
concerns are valid or not.
- Garrett
_______________________________________________
opensolaris-arc mailing list
[email protected]
