Neal Pollack wrote:
>
> This case, and all the following discussion, brings up a very good
> question;
>
> When an ARC case is filed for what seems like potentially controversial
> software (software that may carry competitive, legal, product strategy,
> or customer perception/relations kind of issues), is it the domain
> of ARC, Marketing, Legal, or Solaris PMT to determine what gets
> accepted and not? In other words, is ARC really the proper body
> to decide the above type issues, or is it simply appropriate for
> ARC to derail, and suggest returning to ARC after a decision is
> rendered by the Solaris Portfolio Mgmt Team?
ARC can't decide these business issues, but it is incumbent on a member
when significantly controversial issues are noticed, to point these out
and ask for review by the appropriate body. (In this case Sun legal,
for example.)
I have architectural concerns about what it is we're providing here as
well, which probably mirror some of the same "legal" considerations. I
don't understand the architectural vision for integrating a piece of
software that is essentially a tool designed as way to launch hostile
attacks on network infrastructure.
- Garrett
>
> Neal
>
>
>
> Garrett D'Amore wrote:
>> Darren Reed wrote:
>>> On 11/25/09 10:45, Garrett D'Amore wrote:
>>>> ...
>>>>
>>>> This is totally different from nmap, btw. IIUC, nmap does scans to
>>>> passively identify potential weaknesses. I don't think it actually
>>>> has any *exploits* for them. (Put another way, I don't think
>>>> "nmap" used solely by itself can do serious harm. I think yersinia
>>>> is quite different. I think their choice of name is suitably
>>>> apropos -- naming after the black plague.)
>>>>
>>>> I feel strongly enough about this that I'm going to derail.
>>>
>>> Let me summarise the differences that I see:
>>>
>>> * I can use nmap from my workstation at Sun to remotely probe and
>>> test a host connected to the Internet anywhere in the world for
>>> services that it provides and might be vulnerable, all the while
>>> looking like it is Sun doing that;
>>>
>>> * I can use yersinia to at most disrupt traffic on SWAN but more
>>> likely this would be restricted to the LAN segment I'm on at Sun.
>>>
>>> Whilst the primary raison d'etre for both might be different, so too
>>> is the scope of their aid to someone undertaking nefarious activity.
>>>
>>> yersnia isn't going to help you break into a remote host but it
>>> might help you become the man in the middle when you others wouldn't
>>> have. Even then it only threatens unencrypted traffic or encrypted
>>> traffic without peer authentication. It also a possible threat when
>>> the trust relationship between two hosts does not involve cryptography.
>>>
>>> I think that derailing this case is an over-reaction primarily
>>> because it has been seen as an "attack" tool without properly
>>> considering what the scope of its potential targets is.
>>
>> Are you saying that the attacks that yersinia provides can't take
>> down router infrastructure?
>>
>> To me it sure looks like they can. While its likely that these
>> attacks will be confined to just your enterprise (be it Sun, or
>> elsewhere on your corporate network), it still seems like they have
>> an active component that nmap lacks.
>>
>> Picture an attach launched on a lan segment against a large corporate
>> router which just happens to have an interface on your segment. If
>> this brings down critical router infrastructure for a trading house,
>> the cost can amount to millions of dollars. While clearly the
>> (ab)user of the tool should bear the bulk of the blame and
>> responsibility, I'm not comfortable with the idea that our actions
>> here might have been overly facilitating for that user.
>>
>> I actually think the fact that other distros have included this in
>> there Linux bits was a poor choice as well. This is an area where I
>> believe that other considerations probably trump "familiarity".
>> (Further, I'd sincerely hope that anyone using this kind of tool for
>> non-nefarious purposes would know enough to understand how to
>> download and install it from source!)
>>
>> For the record, I'm not entirely convinced that including nmap was a
>> good idea either, but at least its probes are non-destructive in nature.
>>
>> I stand by my decision; this case is derailed.
>>
>> The project team now has three options:
>>
>> a) present a full case to the ARC and get a vote on it
>> b) withdraw the case.
>> c) seek an appeal on the derailment. Although, I suspect that
>> since we have no established process for this, it would probably take
>> more effort than just going with option "a".
>>
>> - Garrett
>>
>
