Re: Wish for 2002 ...

[Francois Leclerc <leclerc at austin dot sns dot slb dot com>]

Alan Cox wrote:
> 
> > So in fact this is not an example of a program which needs these entry
> > points to be present in the library, which tends to explain why it
> > actually runs.
> 
> In _a_ library
> 
> Nothing stops you collecting together these functions into your own
> personal libunacy.so.1. At that point its simply a matter of adding -lunacy
> to the link line

Indeed I agree with you Alan.
I will try to respectfully argue
	1.why I'm cross posting 
	(security architecture, remediation, implementation)
	2.what the debate is and is not about
	3.why I prefered to propose glibc to libunacy
	4.why I considered strlcat/strlcpy
	(USENIX, performance, residual risk, code access)

1.why I'm cross posting 

The "Wish for 2002" is about providing one more portable common tool
to fight buffer overflow in the USENIX community.
The strlcat/strlcpy is one more tool is to help "security personnel" 
[1] or ISSE [2] in their policy, procedures, code audit and remediation
work.
In effect there are 3 OpenSource communities interested:
-Glibc-alpha, where IMHO it would best fit for the interest of the 
GNU/Linux community.
-Security-audit where GNU/Linux afficionados are working on code audit.
-Open-source where very qualified Open Source people are debating
pros & cons of security architectures.
-None of each is more important than the others.

I wish to know if there is better way to address these issues than 
cross-posting.


2.what the debate is and is not about

I wish the debate is not about us versus them, about our libc 
versus their libc. I wish to get focused on our USENIX / OpenSource
best response to source code auditing and remediation.

I wish the debate is not about bad names and hard feelings,
I wish it to be centered about security process and certification
needs meeting GNU software processes and how they can/could work
together.

I wish we all understand the debate is around a security policy 
questions for secure coding. Spaf, Viega and McGraw address secure 
coding as guidelines (SHOULD in IETF jargon) in their books [3][4].
I'm trying to address them as policy, procedures & tools 
(SHALL in IETF jargon).
When you consider SSE-CMM[5] and Common Criteria[6] for an organization
to meet your customer's certification, you have to define
security policies, procedures, roles, documents ... such that
your organization does produce the evidences to be evaluated
then certified.
SSE-CMM looks at the security & engineering processes you put in place,
their outputs, and how mature is your organization.
Common Criteria formalizes how to look at the output of your processes
to state if your product is trustworthy of its Security Target claims.

To gain SSE-CMM level, you have to perform a well understood, 
repeatable process by different people, over time: 
define a policy and enforce it by procedures and automated tools &
reviews.
It does affect your software providers.

To gain Common Criteria Level, you have to show how your developers,
then your third party security auditors, are thorough in their 
security work.
As RATS & ITS4 come from "third party security auditors" workbenches,
they are prime candidates in my process and toolbox.

This is where the differences of opinions are: 

First school: The current position from glibc maintainers
run "gmake"
run "its4", "rats" & "flawfinder" 
review one by one the strcat/strcpy ... (and others mentioned [3][4])
by hand if they are dangerous.

Second school: My humble, radical view point.
run "gmake"
run "its4", "rats" & "flawfinder" 
Eliminate all references to strcat/strcpy ... (and others mentioned
[3][4])
Eliminate all references to strncat/strncpy as they have residual
risks[7] "strncpy() doesn't null terminate when src parameter is at 
least as long as the destination buffer" "One problem with strncat is 
that you do need to keep track of how much room is left in the 
destination buffer..."
Introduce strlcat or use alternate constructs.
Repeat this cycle in each build.
Update ./configure.in to check for its4, rats, flawfinder presence...
Train the developers

The first school is OK for some markets. But be careful, some security
folks are asking for a CC certification before accreditation.
w2k is under CC EAL4 certification supposedly.
The Open Source mouvement may not have the financial resources
to pay a lot for product certification, but it has shown the best 
tooling one person can afford.
This process is not constraining on the individual participants but
will hardly help in a SSE-CMM or CC certification higher than level 1.

The second school is to be prepared to evaluate at a higher SSE-CMM 2-3
& CC 3-6 levels by formalizing policy and procedures and putting a bit
more constraints on developers and tying up more GNU tools.
So I started by step 1:"wishing to get strlcat/strlcpy accepted in
glibc".
There are more wishes for 2003, 2004, 2005 ... 8^})

The big question is: Can both school approaches coexist in the GNU 
environment without feud, schisme, bloodshed, names, bruises and ...
forking ... ?

3.why I prefered to propose glibc to libunacy

If you accept the second school of thought is a valid way of thinking,
to CC certify a daemon executable or subsystem, you need to include
the all shared libraries involved in your risk analysis, code audit
and remediation work. So eventually you wish for -lunacy when you
build your libc.

4.why I considered strlcat/strlcpy

I guess I'm not as good a programmer as you all are so I made
a conscientious	decision to reuse code better than insert broken code,
 read and seek to understand before bitting my lips.
I thought to USENIX paper [8] did address
	= strn* / strl* performance questions
	= strn* residual risk issues
	= code access & license issues
	= size issue (~20 lines of codes)

So it would be a good technical base for proposal, small to 
make the wish achievable. The rest is history.

[1] "Building Secure Software" by Gary McGraw & John Viega -
(also involved in RATS & ITS4) page 32 "The Role of Security Personnel"

[2] NSA Information Systems Security Engineering Handbook terminology 

[3] "Practical Unix and Internet Security"
chapter 23 "Writing Secure SUID and Network Programs"

[4] "Building Secure Software"
chapter 7 "Buffer overflows"

[5] www.sse-cmm.org
[6] www.commoncriteria.org
[7] "Building Secure Software" p 142/144
[8]
http://www.usenix.org/events/usenix99/full_papers/millert/millert_html/index.html


Regards,
--FL, CISSP