[Biojava-dev] biojava / Security

Thu Aug 14 17:34:13 EDT 2003

Dear Mathew,
  this is definitively easy to do and will spot some problems.
I tried it and could not find anything concerning.

Best, Rainer

-----Original Message-----
From: Matthew Pocock [mailto:matthew_pocock at yahoo.co.uk]
Sent: samedi, 26. juillet 2003 11:21
To: Brian Repko; Warth,Rainer,LAUSANNE,NRC/BAS
Cc: biojava-dev at biojava.org
Subject: Re: [Biojava-dev] biojava / Security

Hi,
Hi Rainer,

The other realy quick thing you can do is grep the
source code for exec(), new File() and new sockets. If
you don't see anything you dislike using these calls,
then the worst BioJava can be doing is
infinite-looping, which you will probably spot anyhow.

If it helps any, the number of people who hold the
keys to our CVS repository is relatively small, and
every few months one of the core 5 ends up doing a
project-wide fix of something (like removing
deprecated API useage) which means that we've all
ended up code-reviewing bits we've not seen before.

Having done sysadmin on a university windows and
solaris network, I have to agree with the other
posters that os Java code is the least of your
worries. Never hurts to be paranoid, though :)

Matthew

 --- Brian Repko <brian_repko at hotmail.com> wrote: 
> Rainer and biojava,
> 
> As far as point (2) below, you could do the
> following:
> 
> 1. turn on java security checking (java
> -Djava.security.manager)
> 
> 2. add a grant entry in the
> ${java.home}/lib/security/java.policy file
> (Assuming you are using the standard Policy
> implementation) for
> the appropriate jar files for biojava and grant it
> the permissions that
> you feel are "safe".  You could start very
> restrictive and grant more
> and more based on need and a code review.  You can
> also setup
> a policy file somewhere else (along with the biojava
> jars) and point
> to that as well (so you don't change the default JRE
> policy file).
> 
> 3. It's not really "applet" vs "application", it is
> much more than that
> and you have quite fine grained access control with
> java (1.2 and higher)
> 
> 4. If biojava was signed, then you could add that to
> the policy file
> as well for more security.
> 
> 5. If you are using JDK 1.3 with JAAS or JDK 1.4,
> you can also adjust
> the permission based on who is running the code.
> 
> Open source java is about the most secure
> environment I can think
> of...then the other stuff about security comes into
> play.
> 
> This is pretty quick to setup (harder to learn) so
> as far as cost vs
> benefit.  If you want to email me at
> brian_repko at hotmail.com, I
> can give you some good reference links as well or
> help out with
> some of the details.
> 
> Brian Repko
> Principal Consultant
> nVISIA
> 
> ----Original Message Follows----
> From: Francois Pepin <francois_pepin at attglobal.net>
> To: "Warth,Rainer,LAUSANNE,NRC/BAS"
> <rainer.warth at rdls.nestle.com>
> CC: "'biojava-dev at biojava.org'"
> <biojava-dev at biojava.org>
> Subject: Re: [Biojava-dev] biojava / Security
> Date: 25 Jul 2003 12:36:40 -0400
> 
> Hi Rainer,
> 
> As far as I know, it would be theoretically possible
> for someone to
> submit malicious code in the CVS, but keep in mind
> that anyone can go
> and see the code there, and a lot of the developers
> have this reflex
> (especially since the javadoc isn't always that
> good). The chances of
> malicious code being included and not detected are
> slim, but it can
> still be a problem in some cases.
> 
> If this is a serious problem for your company, you
> have 2 basic
> solutions that I can see:
> 1- Go over the code that you're using from Biojava
> and don't always use
> the CVS version. Check the changes in the code by
> yourself when updating
> from CVS (diff works wonders for that). And while
> you're doing that, if
> you see bugs or things that can be improved, send it
> back to be included
> in the next version.
> 
> 2- Sandbox the java application as if it was an
> applet. This is a quick
> and dirty solution and probably not worth it because
> the default sandbox
> is probably too restrictive for you, but you can
> change the settings a
> bit.
> 
> My advice would be to use the first one. Possibly,
> there's been other
> people who did this and might be able to certify
> that a given version of
> the classes are clean (if you're willing to trust
> them).
> 
> Francois
> 
> On Fri, 2003-07-25 at 12:06,
> Warth,Rainer,LAUSANNE,NRC/BAS wrote:
>  > Hi,
>  >    biojava has probably became an import part of
> our daily work and we 
> would
>  > not like to miss it. However, I was just recently
> asked within the 
> company,
>  > what would be the security risk by using software
> from a public project 
> such
>  > as biojava. Could it be possible that sombebody
> submits undesired code 
> into
>  > the biojava package, which would end up on my
> machine and cause harm to 
> our
>  > intranet.
>  >    Does anybody has some suggestions where to
> learn more about this type 
> of
>  > problem ? Maybe somebody can propose a good
> strategy to protect againt 
> this
>  > type of security risk ?
>  >
>  > Best, Rainer
>  >
>  > Dr. Rainer Warth
>  > Research Scientist Bioinformatics
>  >
>  > Nestle Research Center
>  > NESTEC LTD.
>  > Vers-Chez-LES-BLANC     phone: +41/21 785 87 13
>  > 1000 LAUSANNE 26          FAX: +41/21 785 89 25
>  > SWITZERLAND            e-mail:
> rainer.warth at rdls.nestle.com
>  >
> 
>
_________________________________________________________________
> Tired of spam? Get advanced junk mail protection
> with MSN 8. 
> http://join.msn.com/?page=features/junkmail
> 
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at biojava.org
> http://biojava.org/mailman/listinfo/biojava-dev 

________________________________________________________________________
Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/