This is the mail archive of the
libc-alpha@sources.redhat.com
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?
a-OpenSSH
b-GNU rsync mentioned in the USENIX 99 paper, page 5.
http://www.usenix.org/events/usenix99/full_papers/millert/millert.pdf
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
pcsc-lite,
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.
http://www.linuxnet.com/middleware/files/pcsc-lite-1.0.1.tar.gz
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
http://www.sse-cmm.org/Papers/SSECMMv2Final.pdf
http://www.isc2.org/cgi/content.cgi?category=8
-online code review references
-bugtraq
-http://www.linuxhelp.org/lsap.shtml
-http://www.openbsd.org/security.html#process
So far I have in my toolbox:
ITS4 [vulnerability]
GNU RATS [vulnerability]
GNU flawfinder [vulnerability]
lclint [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
pcscd
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
several level
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
TSP.
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.
EAL4:
AVA_VLA.2.2C The documentation shall justify, that the TOE, with the
identified vulnerabilities, is resistant to obvious penetration attack.
EAL5:
AVA_VLA.3.3C The evidence shall show that the search for
vulnerabilities is systematic.
EAL6:
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
view.
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
maintainers,
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
libc.
-This is libc-alpha, for security research only.
-The GNU libc maintainers require strlcat/strlcpy in standard ANSI C
or OpenGroup.
Regards,
--FL, CISSP