[Biojava-dev] biojava / Security

Schreiber, Mark mark.schreiber at agresearch.co.nz
Fri Aug 15 04:30:19 EDT 2003


Another solution would be to have emails that notify changes to the CVS (aka bioperl-guts) especially if it includes the lines that have changed. It would be a good way for the core to keep up with changes to the CVS and generally review whats going in.
 
- Mark
 

	-----Original Message----- 
	From: Warth,Rainer,LAUSANNE,NRC/BAS [mailto:rainer.warth at rdls.nestle.com] 
	Sent: Fri 15/08/2003 2:34 a.m. 
	To: 'Matthew Pocock'; Brian Repko 
	Cc: biojava-dev at biojava.org 
	Subject: RE: [Biojava-dev] biojava / Security
	
	

	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/
	_______________________________________________
	biojava-dev mailing list
	biojava-dev at biojava.org
	http://biojava.org/mailman/listinfo/biojava-dev
	


=======================================================================
Attention: The information contained in this message and/or attachments
from AgResearch Limited is intended only for the persons or entities
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipients is prohibited by AgResearch
Limited. If you have received this message in error, please notify the
sender immediately.
=======================================================================



More information about the biojava-dev mailing list