On Tue, Nov 09, 2010 at 09:11:43AM -0500, Jared K. Smith wrote: > On Tue, Nov 9, 2010 at 3:39 AM, Joerg Simon <jsimon@xxxxxxxxxxxxxxxxx> wrote: > > I have a question regarding the consequences of this above decision for > > the Fedora Security Lab. Fedora as Security Test Platform has a big > > usecase - from what i see here in Germany and i work with the ISECOM to > > develop a good learning platform for teaching security, based on our > > Fedora Security Lab. With FSL we ship already a lot of "tools" which can > > do very bad things and can be used to spoof, attack, decrypt or brute > > force - and where to draw the line? even nc can do a lot harm. > > This is something we debated for quite a while in the Board meeting. > I think we as the Board tend to agree -- there are a *lot* of security > tools that are very useful, but can also be used maliciously. The > question of where to draw the line (or lines, as the case may be) is > not easy, but here were some of the guidelines we used in making our > decision: > > * Does the application increase the potential for legal threats > against Fedora (and Red Hat, as our primary sponsor)? > * Does the application have significant non-malicious uses? > * Is this an application that could be easily hosted in a third-party > repository? > > In the case of this particular application, it seems the authors have > gone out of their way to say "This is a tool for automating SQL > injection attacks so that you can exploit someone else's system", and > as such, does open Fedora up to some legal risk. I'm not a lawyer, > but I know Spot (as the official Fedora legal representative) well > enough to know that if it makes him nervous, that I should probably be > a bit nervous as well. > > In short, it's a really tough judgment call. We ended up taking two > votes -- one for the additional language to clarify the Board's stance > on this type of software, and another vote on whether or not to > include the application in Fedora. In the end I voted to excluding > this application because I figured that if someone is smart enough to > use it for non-malicious purposes, they're probably smart enough to > find it in a third-party repository or package it themselves. In a > perfect world we wouldn't have to make nearly so many subjective > judgment calls like this one, but we don't live in a perfect world. > I'm not putting this out there to second guess the Board (The legal threats question being the piece that I have no knowledge about) but two of the arguments used here seem to be very weak at drawing the line between good and bad software. == Does the application have significant non-malicious uses? == The significant non-malicious use here would be the same as the malicious use. As jsimon expresses, attempting SQL injection attacks is a valid non-malicious use case if you are in charge of testing and securing a system against that threat [likely against non-production instances]). To use an analogy, an army hates to see new weapons deployed against them but if new weapons are used against them, it's much better if they have a copy of the weapon so they can test out its capabilities and take appropriate steps to counteract the problems it causes. To me this criteria would be better expressed as "Does the application have significant uses outside of attacking a system?" This should be more specific than "malicious" and make more clear that nc does not fall under this while SQLNinja does. You may also want to explicitly talk about testing and teaching since it seems that SQLNinja was seen as being outside the pale due to "gone out of their way to say" it's for launching attacks whereas if it was marketted as a tool to identify SQL Injection attacks so you could close them it would be okay. == Is this an application that could be easily hosted in a third-party repository? == In particular, this reasoning: "if someone is smart enough to use it for non-malicious purposes, they're probably smart enough to find it in a third-party repository or package it themselves." The purposes of the Fedora Security spin would seem to be three-fold to me: 1) Make it convenient for a knowledgable user to do security auditing and perform forensics on their systems. 2) Allow a user interested in security to get a collection of tools that they can use in one collection. 3) Demonstrate how Fedora specifically contains the tools that a user may need to audit and perform forensics on their systems. The class of user being targeted by the Spin may well be capable of finding *all* of the software on the spin from a third party repository or packaging it themselves but not packaging the software would obviate all three of those goals. To me, this decision boils down to the big unknown, the potential for increased legal threats. If jsimon is concerned that this rule is a problem for other programs on the Security Spin, perhaps he should assemble a list of other attack-oriented teaching and testing tools and the Board + legal can decide whether the rule is or can be crafted to allow them while still mitigating the legal risk. -Toshio
Attachment:
pgplkKbkcvJiA.pgp
Description: PGP signature
_______________________________________________ advisory-board mailing list advisory-board@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/advisory-board
