[Biojava-dev] biojava / Security
Matthew Pocock
matthew_pocock at yahoo.co.uk
Fri Aug 15 04:33:31 EDT 2003
Last time I checked, CVS notification sent messages
/per file/ rather than per commit. That's painfull.
Perhaps a daily single cvs mail would be better?
Matthew
--- "Schreiber, Mark"
<mark.schreiber at agresearch.co.nz> wrote: > 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
>
=== message truncated ===
________________________________________________________________________
Want to chat instantly with your online friends? Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/
More information about the biojava-dev
mailing list