This is the mail archive of the libc-alpha@sources.redhat.com 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?

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


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