This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Wish for 2002 ...

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:
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
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

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
or OpenGroup.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]