From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <java-prs-return-5940-listarch-java-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 5081 invoked by alias); 2 Jun 2005 22:43:45 -0000
Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:java-prs-subscribe@gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/java-prs/>
List-Post: <mailto:java-prs@gcc.gnu.org>
List-Help: <mailto:java-prs-help@gcc.gnu.org>, <http://gcc.gnu.org/ml/#faqs>
Sender: java-prs-owner@gcc.gnu.org
Received: (qmail 5060 invoked by uid 48); 2 Jun 2005 22:43:44 -0000
Date: Thu, 02 Jun 2005 22:43:00 -0000
From: "tromey at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: java-prs@gcc.gnu.org
Message-ID: <20050602224341.21892.tromey@gcc.gnu.org>
Reply-To: gcc-bugzilla@gcc.gnu.org
Subject: [Bug libgcj/21892] New: gnu.* and native code security audit
X-Bugzilla-Reason: CC
X-SW-Source: 2005-q2/txt/msg00678.txt.bz2
List-Id: <java-prs.sourceware.org>

In order to be confident in our security implementation we must
ensure that calls to gnu.* code (which might bypass security checks)
are inaccessible to user code running in a secure context.
Some sort of automated testing would be ideal, so that we could reliably
re-run the audit whenever we like.  That will ensure we don't have
a (disastrous) regression here.

Likewise we must audit the CNI code for things like buffer overflows.

-- 
           Summary: gnu.* and native code security audit
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libgcj
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: tromey at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
                    dot org
OtherBugsDependingO 13603
             nThis:


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21892