Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 87844 invoked from network); 6 Nov 2007 02:00:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 6 Nov 2007 02:00:55 -0000 Received: (qmail 83646 invoked by uid 500); 6 Nov 2007 02:00:41 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 83591 invoked by uid 500); 6 Nov 2007 02:00:41 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 83580 invoked by uid 99); 6 Nov 2007 02:00:41 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Nov 2007 18:00:41 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [69.147.95.64] (HELO smtp101.plus.mail.sp1.yahoo.com) (69.147.95.64) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 06 Nov 2007 02:01:12 +0000 Received: (qmail 32045 invoked from network); 6 Nov 2007 02:00:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer; b=y7lf4xZL2bW4QHdXNmWIMXQ/4WE0bSiczucLGY3nlLKfLpE+ksLqYp9n4uPCTVMlXOiqBUy7Ou6b6E4TpJi/hMMNeP0EPqE/rOs4b7Pma9lfH+ekojOtJZ4H5scUfeZ5wUk0n6mMLRUPMn+z7d+S5jLbPsQ9Ics5c04k9lOV7yA= ; Received: from unknown (HELO ?192.168.1.101?) (david_jencks@67.102.173.8 with plain) by smtp101.plus.mail.sp1.yahoo.com with SMTP; 6 Nov 2007 02:00:17 -0000 X-YMail-OSG: dUYctuUVM1mZZgXzKiFTDyqqZMP0EO8uJMoOxqc3ybOoTsB8porHlemUfM_NkiyGPYPJxZIj05hfND7myBlV9UbxWz5Q7HLP.wcyzWdyTP676wBoOQfynPtxbZWH Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <5eb405c70711010959l513dd268i71778d2b3c452979@mail.gmail.com> References: <5eb405c70710291056v482c601bpb46b1a6def60cce4@mail.gmail.com> <22d56c4d0710310044y2cf9cb68w7465cd0a3c73e91d@mail.gmail.com> <5eb405c70711010959l513dd268i71778d2b3c452979@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5946D666-0D5C-4AB2-8034-25DFAC4EDBD7@yahoo.com> Content-Transfer-Encoding: 7bit From: David Jencks Subject: Re: basic security review Date: Mon, 5 Nov 2007 18:00:02 -0800 To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.752.3) X-Virus-Checked: Checked by ClamAV on apache.org 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 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 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 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 >>>> >>> >> >>