Fedora Board Recap 2010-11-08

[Toshio Kuratomi]

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 at fedoraproject.org> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/advisory-board/attachments/20101109/a6418e6d/attachment.bin