[C-safe-secure-studygroup] portability

[Robert Seacord]

There are various references to "safe" and "unsafe" throughout the
standard, but I would not attribute this as direction from WG14 on what
constitutes safety in C language programming.

Annex K sort of mentions both safety and security (see below).  To a
certain extent I believe that given more consideration by WG14, some of
this language might be eliminated, so I might describe this as discussed in
a "cursory manner".

K.1 Background

While it is possible to write safe, robust, and
error-free code using the existing library, the library tends to promote
programming styles
that lead to mysterious failures if a result is too big for the provided
array.

...

Worse, this style of programming has compromised the security of computers
and
networks.

...

This annex provides alternative library functions that promote safer, more
secure
programming.

K.2 Scope
1 This annex specifies a series of optional extensions that can be useful
in the mitigation of
security vulnerabilities in programs, and comprise new functions, macros,
and types
declared or defined in existing standard headers.

On Fri, Sep 1, 2017 at 8:03 AM, Fulvio Baccaglini <
fulvio_baccaglini at programmingresearch.com> wrote:

> I cannot think of any specific points to raise on the paper at the
> moment, I think that it is a good introduction, especially because it
> puts things into an overall context.
>
> Here are some rough thoughts that came to my mind when reading it.
>
> I feel that "portability" is in a different category with respect to
> "safety" and "security".
>
> We could consider two perspectives, maybe roughly:
>
> . system (in this context, say: the requirements at system boundary as
> visible to the user)
> . software (in this context, say: the C source code and additional
> configuration options, as visible to a static analysis tool)
>
> The concept of "portability" can be relatively easily expressed in terms
> of software. For instance in terms of C11 Annex J "portability issues":
>
> . undefined behaviour
> . unspecified behaviour
> . implementation-defined behaviour
> . locale-specific behaviour
> . common extensions
>
> Instead, mapping the definitions of "safety" and "security" from a
> system to a software perspective looks much more complex and subjective.
>
> Looking at the C11 standard, it does not refer to "safety" anywhere, but
> it refers to "security" in Annex K "Bounds-checking interfaces", in
> particular in this sentence: "this style of programming has compromised
> the security of computers and networks. Buffer overflows can often be
> exploited to run arbitrary code with the permissions of the vulnerable
> (defective) program."
>
> This would pretty much relate to one of the undefined behaviour items:
> "an array subscript is out of range".
>
> In this case there appears to be an implicit underlying criterion, of
> the type: if one of the potential issues with the source code is
> generally being exploited more than other issues to compromise systems'
> security, then security enforcement should include preventing that issue
> from arising.
>
> My initial impression is that the paper could remain self-contained, as
> capturing the existing definitions, and then a separate document could
> be worked on, to express some principles/approaches on how to relate
> those definitions to a software perspective.
>
> Fulvio
>
> On 31/08/17 19:46, Robert Seacord wrote:
> > I wrote and attached a very rough draft of a paper describing safety,
> > security, and portability concerns (as well as legacy code issues)
> > when determining the criteria for including rules in one profile or
> > the other. I think this is still at the conceptual level, but perhaps
> > once we have some agreement at the conceptual level we can
> > operationalize it a bit more.
> >
> > Best if you can make your comments directly in the attached document.
> > Please use track changes for any edits you make.
> >
> > The paper is a bit fancy because I'm planning on publishing this also
> > as an NCC Group whitepaper so that I can kill two birds with one
> > stone. 8^)
> >
> > Thanks,
> > rCs
>
>
> ------------------------------
> This email has been scanned for email related threats and delivered safely
> by Mimecast.
> For more information please visit http://www.mimecast.com
> ------------------------------
>
> _______________________________________________
> C-safe-secure-studygroup mailing list
> C-safe-secure-studygroup at lists.trustable.io
> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-
> safe-secure-studygroup
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/c-safe-secure-studygroup/attachments/20170905/c515525f/attachment.html>