This is the mail archive of the
mailing list for the glibc project.
Wish for 2002 ...
- From: Francois Leclerc <leclerc at austin dot sns dot slb dot com>
- To: Kaz Kylheku <kaz at ashi dot footprints dot net>
- Cc: Security Audit <security-audit at ferret dot lmh dot ox dot ac dot uk>, Andrew Josey <a dot josey at opengroup dot org>, Tiemann <tiemann at redhat dot com>, libc-alpha at sources dot redhat dot com, Robust Open Source <open-source at csl dot sri dot com>
- Date: Thu, 10 Jan 2002 16:25:49 -0600
- Subject: Wish for 2002 ...
- Organization: Schlumberger
- References: <Pine.LNX.4.33.0201091840140.23184-100000@ashi.FootPrints.net>
Kaz Kylheku wrote:
> > Given that the function is necessary for some programs, the fact of
> Can you name some of these programs?
b-GNU rsync mentioned in the USENIX 99 paper, page 5.
I did check recently the code: It has autoconf to detect the presence
of strlcat/strlcpy and provide it if needed. IMHO, this is a correct
approach from the application view point, but an incomplete one from
a system engineering view point.
c-I'm looking at strlcat/strlcpy as I try to review the code for
the low-level daemon which manage state and communications between the
smartcard and its reader on one side, and the computer applications on
the other side.
By the way this is the first piece of the puzzle to securely integrate
smartcards and crypto-aware applications in opensource. Some say "1
is an isolated event, 2 are many events, 3 are patterns".
The commonality of these applications is: They are Network Programs
[cf Spaf's Practical Unix and Internet Security chapter 23,
Writing Secure SUID and Network Programs]
So far I have in my policy & guidelines library:
-Books from Spaf, Gary McGraw & Viega, Ross Anderson, Tipton ...
-Security Standards like BS 7799, ISO 15408, ISO 13335
-Community based reference documents : SSE-CMM, CISSP's CBK
-online code review references
So far I have in my toolbox:
GNU RATS [vulnerability]
GNU flawfinder [vulnerability]
I'm looking to add cqual [vulnerability] and
cxxrefs [documentation from code].
I created none of these, I'm just learning from the secure coding
community. I'm sure I missed useful tools somehow. Please let me know.
I wish to set a code review process to satisfy ISO 15408
(aka Common Criteria) EAL3 to EAL6 [EAL/Evaluation Assurance Level].
In my learning experiment, I set the Target of Evaluation (TOE) to the
daemon (which is small but includes glibc).
In the definitions of EAL3 to 6 in ISO/IEC 15408-3:1999, page 59-65
I'm looking at the "Vulnerability assessment" "assurance class".
The assurance component AVA_VLA "Vulnerability Analysis" has got
AVA_VLA page 180
EAL3 AVA_VLA.1 Developer vulnerability analysis page 181
EAL4 AVA_VLA.2 Independant vulnerability analysis page 181
EAL5 AVA_VLA.3 Moderately resistant page 183
EAL6 AVA_VLA.4 Highly resistant page 184
here are some extracts for EAL3 :
AVA_VLA.1.1D The developer shall perform and document an analysis
of the TOE searching for obvious ways in which a user can violate the
AVA_VLA.1.1C The documentation shall show, for all identified
vulnerabilities, that the vulnerability can not be exploited in the
intended environment for the TOE.
AVA_VLA.2.2C The documentation shall justify, that the TOE, with the
identified vulnerabilities, is resistant to obvious penetration attack.
AVA_VLA.3.3C The evidence shall show that the search for
vulnerabilities is systematic.
AVA_VLA.4.4C The analysis documentation shall provide a justification
that the analysis completely addresses the TOE deliverables.
As for my interest in GNU/Linux & glibc, it is also motivated by the
SELinux distribution. I'm talking business.
I wish to tell you, that I appreciate your opinion in the debate as
I'm learning from you all, and try to respectfully share my point of
I wish to hear from the glibc maintainers and those with the
respectable "NO." opinion what alternate strcat/strcpy vulnerability
remediation they propose:
1-What is the unit cost of their remediation for
strcat (b , a);
2-Remediation Process (policies, guidelines and procedures)
they intend to define and use.
3-What remediation tools they intend to use.
I wish to get at least some middleground statement from glibc
like "These strlcat/strlcpy functions are only available under
--enable-XYZ configure option, for the purpose of helping some security
researchers document their possible security benefits for the GNU
community at large. Until proper ANSI C or OpenGroup standard
validates these functions, they will stay under a configuration option.
In this proposed statement, I try to express that:
-There is still doubt in the mind of the GNU libc maintainers of
the security benefits provided by strlcat & strlcpy.
-There is a community of interest in favor of strlcat/strlcpy in GNU
-This is libc-alpha, for security research only.
-The GNU libc maintainers require strlcat/strlcpy in standard ANSI C