Garrett D'Amore wrote: > Joep Vesseur wrote: >> Interesting case... At first I thought it was April 1st already, but >> I guess >> we'll see more tools like this appearing as familiarity cases (NFS-shell >> anyone?) >> >> I realize that any user can install this software by downloading and >> compiling, but I'm left with two questions when it's present out of >> the box: >> >> - what privileges are needed by this software? Can any regular user >> run this >> and, perhaps accidentally, create havoc on the networks he's >> connected to? >> I guess it would be nice if only users with "Network Security" or >> another >> suitable profile were able to use this program. >> >> - The FOSS document states that there are no network services >> provided by >> this software and no authentication performed. The man-page however >> mentions a daemon mode that offers a Cisco-like CLI that people >> can use >> to monitor and launch attacks from. Who can start this daemon and >> how is >> access to the daemon controlled? >> >> Joep >> > I'm actually of the opinion that this is not something we ought to be > bundling with our systems. I understand there might be some intent to > allow administrators to do penetration testing, but I really believe > we shouldn't be encouraging end-users to do this. Basically, tools > like this just facilitate life for the "script kiddies". Is there absolute or substantial distinction between administrators and end-users in this case? NOTE that any privileged user can download and compile this piece of software if one wish to, even at the time yersinia hasn't yet been shipped out of the box. However, an unprivileged user could never have a chance to impose anything harmful to the hosts or networks by yersinia. I don't follow the saying that shipping this tool equals to encouraging anyone - including end-users - to attack the network. Just an example, almost all system adminstrators know that by doing "rm -rf /", one would damage the root filesystem and result in all the data in the disk or datastore ruined at all. But we should not say, umm, "rm is too dangerous a tool, thus we shouldn't get it shipped thus encourging end-users damage any data". I admit this is one rather extreme example, but the logic is that the only thing should be taken care of is the proper privileges and authorizations. It's all up to the user with the correspoding level of privileges - who should really take care about what the real impact is. The more privileges, the more responsibilities.
Additionally, both Redhat and Canonical have shipped yersinia into their Linux distros respectively, for long. I don't think they shipped this because they encourage end-users to attack the network. Is OpenSolaris/Solaris a special case that cannot offer this kind of flexibility to end-users? > From an architectural point of view, does it make sense that we > include tools that have the primary purpose of being used to identify > and exploit weaknesses in the network infrastructure? I really don't > think so. Not to rain on the parade ... But if you recall there had been a time telnet worm was raging amongst SWAN, a vulnerability scanner tool - nmap, was integrated soon because it's identified to be useful for discover and exploit the affected systems in the network. However ,on the other mixed blessing end, nmap is also nortorious intrution tool since last 90s, that many hacker's sites provide it as a spoofing or attacking tool in hackers' daily toolkit. But we rarely notice the complaint that someone is scanning or hacking network since nmap is being bundled with Solaris, although it's believed that nmap itself could do more harm than yersinia, to stress the attacks to quite amount of systems in parallel. But yersinia just fill the gap that nmap cannot do - explore system vulnerablity against layer 2 spoofing attacks, that help administrators aware of the potential security problems much better. Hence from purely the ARC's POV, I do think it can make sense to include this tool as well. > > If just one corporate catastrophe is avoided by not having this kind > of software "too readily available", then I'll be glad we haven't > shipped it. > > I think this case pushes the "familiarity envelope" just a bit too > far. My fingers are hovering over the derail button... but I'll give > the submitter/owner a chance to help me understand the architectural > vision here -- how does offering this in prepackaged form do more good > than harm? I hope the clarifications above would be helpful for you to understand the vision and scope here. :-) Thanks, -Siwei > > - Garrett >
