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.
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 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.
- Garrett
On 05/ 5/10 10:54 AM, Kacheong Poon wrote:
On 05/ 6/10 12:42 AM, Garrett D'Amore wrote:
1) Can an ill-behaved application cause bad things to happen to the TCP
stack by setting RTO or abort timers too high? I'm specifically thinking
that by setting these timers to a large value, that it might be possible
to cause out of control consumption of resources or exhaustion of TCP
port numbers....
The result is that TCP keeps on retransmitting and won't time
out for the "long" (TCP_ABORT_THRESHOLD option value) period
of time. But an app can do effectively the same thing without
using the option by opening up another socket.
2) Perhaps setting some of these values should require a privilege?
I guess unless the system security or policy is affected, the
use of a privilege may not be appropriate. IMHO, both are not
affected. And from the point of view of resource consumption,
an app can use effectively the same amount of resource without
the help of the options, new and old (*).
If folks are not comfortable with the current ranges of those
existing TCP private parameters (the option value ranges are
the same), I can certainly change them.
3) Ultimately, have the implications of these changes been reviewed from
a security standpoint?
I guess the implications are obvious. If folks on the list
see a problem, please raise it.
(*) Note that TCP_CONN_ABORT_THRESHOLD and TCP_ABORT_THRESHOLD
have been in Solaris for a long time. I just checked the
history, it was added in 1992. Although they were not
documented by us, these two options are known in other
network stacks. Given their history and the fact that we
have not received (AFAIK) any complain, it is safe to assume
that documenting them will not introduce new issues.
_______________________________________________
opensolaris-arc mailing list
[email protected]
