basic security review

[Jarek Gawor <jg...@gmail.com>]

A few security problems were discovered in Geronimo in the last few
months and weeks. Most of them were Geronimo-specific except one.
Therefore, I think we should spend a little bit of our time to review
our code and check for potential security problems.
As the first step, I think we should identify components that make
security decisions (e.g. LoginModules) or enable access to server
management and control (e.g. MEJB) or any other components that might
be important for sever security.
Once we have a few components identified we can start the review.
Besides finding and fixing the potential security problems during the
review we must also ensure that we have decent tests for these
components that cover a range of inputs. For each problem that we do
discover, we must write a test case to make sure it never happens
again. Basically, a problem is not fully addressed until we have a
test for it.

For now, I created the following page where we can keep track of the
components and the review:
http://cwiki.apache.org/confluence/display/GMOxDEV/Security+Review
Feel free to update it in any way.

Opinions? Ideas? Thoughts?

Jarek

Re: basic security review

[Jarek Gawor <jg...@gmail.com>]

Folks,

We added a bunch of tests in the last few days but we still need some
help identifying and reviewing the components. Please see the wiki
page ( http://cwiki.apache.org/confluence/display/GMOxDEV/Security+Review)
for latest updates.

Thanks,
Jarek

On 10/29/07, Jarek Gawor <jg...@gmail.com> wrote:
> A few security problems were discovered in Geronimo in the last few
> months and weeks. Most of them were Geronimo-specific except one.
> Therefore, I think we should spend a little bit of our time to review
> our code and check for potential security problems.
> As the first step, I think we should identify components that make
> security decisions (e.g. LoginModules) or enable access to server
> management and control (e.g. MEJB) or any other components that might
> be important for sever security.
> Once we have a few components identified we can start the review.
> Besides finding and fixing the potential security problems during the
> review we must also ensure that we have decent tests for these
> components that cover a range of inputs. For each problem that we do
> discover, we must write a test case to make sure it never happens
> again. Basically, a problem is not fully addressed until we have a
> test for it.
>
> For now, I created the following page where we can keep track of the
> components and the review:
> http://cwiki.apache.org/confluence/display/GMOxDEV/Security+Review
> Feel free to update it in any way.
>
> Opinions? Ideas? Thoughts?
>
> Jarek
>

Re: basic security review

[Vamsavardhana Reddy <c1...@gmail.com>]

I think I have touched upon everything in the code base that seems to be a
LoginModule implementation.  Only thing that remains w.r.t LoginModules is
the moving of NamedUPCredentialLoginModule to o.a.g.s.realm.providers.  (I
have not bothered about changing UPCredentialLoginModule as I have marked it
deprecated.  Let us wait for one release before deleting the deprecated
LoginModule).  I will call it a completion of one phase in security review.
Thanks to David Jencks for refactoring the tests, it made adding new
testcases much simpler.  This should definitely help avoid any unwanted
surprises like the one that resulted in G 2.0.1 and the one that crept in in
the due course.  One more thing that remains is updating the Wiki page to
reflect all the LoginModules that have been reviewed (argh... I am feeling
lazy :( )

There is definitely a lot more to be done.  Let us keep the ball rolling.

++Vamsi


On Oct 31, 2007 1:14 PM, Vamsavardhana Reddy <c1...@gmail.com> wrote:

> I think we should create JIRAs for each review activity that results in
> code changes and update the wiki with the JIRA number.  This way we will be
> able to track the progress on each activity in one central place.  Also, add
> important points from this discussion thread to the wiki too.
>
> ++Vamsi
>
> On 10/30/07, Prasad Kashyap <go...@gmail.com> wrote:
>
> > I agree. Our strategy to make Geronimo secure should include an
> > elaborate set of unit testcases, a rich set of tests in the
> > security-testsuite in our testsuite framework,  along with  peer
> > review of code in components that are potential security risks.
> >
> > We should aim to have imbricate or maybe even duplicate tests than have
> > gaps.
> >
> > Towards this end, I created a security-testsuite in our testsuite
> > framework. It contains one test now. I shall add some more soon.
> > Please contribute to this testsuite with more and more tests that you
> > can think of.
> >
> > Thanx
> > Prasad
> >
> > On 10/29/07, Jarek Gawor <jg...@gmail.com> wrote:
> > > A few security problems were discovered in Geronimo in the last few
> > > months and weeks. Most of them were Geronimo-specific except one.
> > > Therefore, I think we should spend a little bit of our time to review
> > > our code and check for potential security problems.
> > > As the first step, I think we should identify components that make
> > > security decisions (e.g. LoginModules) or enable access to server
> > > management and control (e.g. MEJB) or any other components that might
> > > be important for sever security.
> > > Once we have a few components identified we can start the review.
> > > Besides finding and fixing the potential security problems during the
> > > review we must also ensure that we have decent tests for these
> > > components that cover a range of inputs. For each problem that we do
> > > discover, we must write a test case to make sure it never happens
> > > again. Basically, a problem is not fully addressed until we have a
> > > test for it.
> > >
> > > For now, I created the following page where we can keep track of the
> > > components and the review:
> > > http://cwiki.apache.org/confluence/display/GMOxDEV/Security+Review
> > > Feel free to update it in any way.
> > >
> > > Opinions? Ideas? Thoughts?
> > >
> > > Jarek
> > >
> >
>
>

Re: basic security review

[David Jencks <da...@yahoo.com>]

On Nov 1, 2007, at 9:59 AM, Jarek Gawor wrote:

> Yes, that's a good idea. Also, excellent work with reviewing the
> LoginModules and adding tests!!!
>
> I just added two new LoginModules to look at. I'm particularly
> concerned about CertificateChainLoginModule since it always returns
> true in its login() function. But I'm not exactly sure how this is
> being used.
The CertificateChainLoginModule probably isn't much good in real life  
at this point.  My thinking was that if we've set up an SSL  
connection with a client certificate, that means the SSL machinery  
has already verified that the client certificate is valid according  
to the CA's we know about, and we aren't going to get much more  
definitive about someone's identity than that.  The real problem is  
that in order for this user to do anything we have to assign  
application level roles to them individually since there is no  
associated concept of "enterprise roles" or "groups".  In our current  
system this is a major inconvenience.  I'm not sure it's worth  
actually fixing it since we'd get into providing a whole lot of  
identity>> enterprise role >> application role stores (properties  
file, sql, ldap, ....).  This kind of mapping is one of the big  
things I want triplesec to support in an easy-to-use-way.

thanks
david jencks

>
> Jarek
>
> On 10/31/07, Vamsavardhana Reddy <c1...@gmail.com> wrote:
>> I think we should create JIRAs for each review activity that  
>> results in code
>> changes and update the wiki with the JIRA number.  This way we  
>> will be able
>> to track the progress on each activity in one central place.   
>> Also, add
>> important points from this discussion thread to the wiki too.
>>
>> ++Vamsi
>>
>> On 10/30/07, Prasad Kashyap <go...@gmail.com> wrote:
>>> I agree. Our strategy to make Geronimo secure should include an
>>> elaborate set of unit testcases, a rich set of tests in the
>>> security-testsuite in our testsuite framework,  along with  peer
>>> review of code in components that are potential security risks.
>>>
>>> We should aim to have imbricate or maybe even duplicate tests  
>>> than have
>> gaps.
>>>
>>> Towards this end, I created a security-testsuite in our testsuite
>>> framework. It contains one test now. I shall add some more soon.
>>> Please contribute to this testsuite with more and more tests that  
>>> you
>>> can think of.
>>>
>>> Thanx
>>> Prasad
>>>
>>> On 10/29/07, Jarek Gawor <jg...@gmail.com> wrote:
>>>> A few security problems were discovered in Geronimo in the last few
>>>> months and weeks. Most of them were Geronimo-specific except one.
>>>> Therefore, I think we should spend a little bit of our time to  
>>>> review
>>>> our code and check for potential security problems.
>>>> As the first step, I think we should identify components that make
>>>> security decisions (e.g. LoginModules) or enable access to server
>>>> management and control (e.g. MEJB) or any other components that  
>>>> might
>>>> be important for sever security.
>>>> Once we have a few components identified we can start the review.
>>>> Besides finding and fixing the potential security problems  
>>>> during the
>>>> review we must also ensure that we have decent tests for these
>>>> components that cover a range of inputs. For each problem that  
>>>> we do
>>>> discover, we must write a test case to make sure it never happens
>>>> again. Basically, a problem is not fully addressed until we have a
>>>> test for it.
>>>>
>>>> For now, I created the following page where we can keep track of  
>>>> the
>>>> components and the review:
>>>>
>> http://cwiki.apache.org/confluence/display/GMOxDEV/Security+Review
>>>> Feel free to update it in any way.
>>>>
>>>> Opinions? Ideas? Thoughts?
>>>>
>>>> Jarek
>>>>
>>>
>>
>>

Re: basic security review

[Jarek Gawor <jg...@gmail.com>]

Yes, that's a good idea. Also, excellent work with reviewing the
LoginModules and adding tests!!!

I just added two new LoginModules to look at. I'm particularly
concerned about CertificateChainLoginModule since it always returns
true in its login() function. But I'm not exactly sure how this is
being used.

Jarek

On 10/31/07, Vamsavardhana Reddy <c1...@gmail.com> wrote:
> I think we should create JIRAs for each review activity that results in code
> changes and update the wiki with the JIRA number.  This way we will be able
> to track the progress on each activity in one central place.  Also, add
> important points from this discussion thread to the wiki too.
>
> ++Vamsi
>
> On 10/30/07, Prasad Kashyap <go...@gmail.com> wrote:
> > I agree. Our strategy to make Geronimo secure should include an
> > elaborate set of unit testcases, a rich set of tests in the
> > security-testsuite in our testsuite framework,  along with  peer
> > review of code in components that are potential security risks.
> >
> > We should aim to have imbricate or maybe even duplicate tests than have
> gaps.
> >
> > Towards this end, I created a security-testsuite in our testsuite
> > framework. It contains one test now. I shall add some more soon.
> > Please contribute to this testsuite with more and more tests that you
> > can think of.
> >
> > Thanx
> > Prasad
> >
> > On 10/29/07, Jarek Gawor <jg...@gmail.com> wrote:
> > > A few security problems were discovered in Geronimo in the last few
> > > months and weeks. Most of them were Geronimo-specific except one.
> > > Therefore, I think we should spend a little bit of our time to review
> > > our code and check for potential security problems.
> > > As the first step, I think we should identify components that make
> > > security decisions (e.g. LoginModules) or enable access to server
> > > management and control (e.g. MEJB) or any other components that might
> > > be important for sever security.
> > > Once we have a few components identified we can start the review.
> > > Besides finding and fixing the potential security problems during the
> > > review we must also ensure that we have decent tests for these
> > > components that cover a range of inputs. For each problem that we do
> > > discover, we must write a test case to make sure it never happens
> > > again. Basically, a problem is not fully addressed until we have a
> > > test for it.
> > >
> > > For now, I created the following page where we can keep track of the
> > > components and the review:
> > >
> http://cwiki.apache.org/confluence/display/GMOxDEV/Security+Review
> > > Feel free to update it in any way.
> > >
> > > Opinions? Ideas? Thoughts?
> > >
> > > Jarek
> > >
> >
>
>

Re: basic security review

[Vamsavardhana Reddy <c1...@gmail.com>]

I think we should create JIRAs for each review activity that results in code
changes and update the wiki with the JIRA number.  This way we will be able
to track the progress on each activity in one central place.  Also, add
important points from this discussion thread to the wiki too.

++Vamsi

On 10/30/07, Prasad Kashyap <go...@gmail.com> wrote:
>
> I agree. Our strategy to make Geronimo secure should include an
> elaborate set of unit testcases, a rich set of tests in the
> security-testsuite in our testsuite framework,  along with  peer
> review of code in components that are potential security risks.
>
> We should aim to have imbricate or maybe even duplicate tests than have
> gaps.
>
> Towards this end, I created a security-testsuite in our testsuite
> framework. It contains one test now. I shall add some more soon.
> Please contribute to this testsuite with more and more tests that you
> can think of.
>
> Thanx
> Prasad
>
> On 10/29/07, Jarek Gawor <jg...@gmail.com> wrote:
> > A few security problems were discovered in Geronimo in the last few
> > months and weeks. Most of them were Geronimo-specific except one.
> > Therefore, I think we should spend a little bit of our time to review
> > our code and check for potential security problems.
> > As the first step, I think we should identify components that make
> > security decisions (e.g. LoginModules) or enable access to server
> > management and control (e.g. MEJB) or any other components that might
> > be important for sever security.
> > Once we have a few components identified we can start the review.
> > Besides finding and fixing the potential security problems during the
> > review we must also ensure that we have decent tests for these
> > components that cover a range of inputs. For each problem that we do
> > discover, we must write a test case to make sure it never happens
> > again. Basically, a problem is not fully addressed until we have a
> > test for it.
> >
> > For now, I created the following page where we can keep track of the
> > components and the review:
> > http://cwiki.apache.org/confluence/display/GMOxDEV/Security+Review
> > Feel free to update it in any way.
> >
> > Opinions? Ideas? Thoughts?
> >
> > Jarek
> >
>

Re: basic security review

[Vamsavardhana Reddy <c1...@gmail.com>]

Thanks Jarek and Prasad for getting the ball rolling.

++Vamsi

On 10/30/07, Prasad Kashyap <go...@gmail.com> wrote:
>
> I agree. Our strategy to make Geronimo secure should include an
> elaborate set of unit testcases, a rich set of tests in the
> security-testsuite in our testsuite framework,  along with  peer
> review of code in components that are potential security risks.
>
> We should aim to have imbricate or maybe even duplicate tests than have
> gaps.
>
> Towards this end, I created a security-testsuite in our testsuite
> framework. It contains one test now. I shall add some more soon.
> Please contribute to this testsuite with more and more tests that you
> can think of.
>
> Thanx
> Prasad
>
> On 10/29/07, Jarek Gawor <jg...@gmail.com> wrote:
> > A few security problems were discovered in Geronimo in the last few
> > months and weeks. Most of them were Geronimo-specific except one.
> > Therefore, I think we should spend a little bit of our time to review
> > our code and check for potential security problems.
> > As the first step, I think we should identify components that make
> > security decisions (e.g. LoginModules) or enable access to server
> > management and control (e.g. MEJB) or any other components that might
> > be important for sever security.
> > Once we have a few components identified we can start the review.
> > Besides finding and fixing the potential security problems during the
> > review we must also ensure that we have decent tests for these
> > components that cover a range of inputs. For each problem that we do
> > discover, we must write a test case to make sure it never happens
> > again. Basically, a problem is not fully addressed until we have a
> > test for it.
> >
> > For now, I created the following page where we can keep track of the
> > components and the review:
> > http://cwiki.apache.org/confluence/display/GMOxDEV/Security+Review
> > Feel free to update it in any way.
> >
> > Opinions? Ideas? Thoughts?
> >
> > Jarek
> >
>

Re: basic security review

[Prasad Kashyap <go...@gmail.com>]

I agree. Our strategy to make Geronimo secure should include an
elaborate set of unit testcases, a rich set of tests in the
security-testsuite in our testsuite framework,  along with  peer
review of code in components that are potential security risks.

We should aim to have imbricate or maybe even duplicate tests than have gaps.

Towards this end, I created a security-testsuite in our testsuite
framework. It contains one test now. I shall add some more soon.
Please contribute to this testsuite with more and more tests that you
can think of.

Thanx
Prasad

On 10/29/07, Jarek Gawor <jg...@gmail.com> wrote:
> A few security problems were discovered in Geronimo in the last few
> months and weeks. Most of them were Geronimo-specific except one.
> Therefore, I think we should spend a little bit of our time to review
> our code and check for potential security problems.
> As the first step, I think we should identify components that make
> security decisions (e.g. LoginModules) or enable access to server
> management and control (e.g. MEJB) or any other components that might
> be important for sever security.
> Once we have a few components identified we can start the review.
> Besides finding and fixing the potential security problems during the
> review we must also ensure that we have decent tests for these
> components that cover a range of inputs. For each problem that we do
> discover, we must write a test case to make sure it never happens
> again. Basically, a problem is not fully addressed until we have a
> test for it.
>
> For now, I created the following page where we can keep track of the
> components and the review:
> http://cwiki.apache.org/confluence/display/GMOxDEV/Security+Review
> Feel free to update it in any way.
>
> Opinions? Ideas? Thoughts?
>
> Jarek
>