[C-safe-secure-studygroup] portability

Fulvio Baccaglini fulvio_baccaglini at programmingresearch.com
Fri Sep 1 12:03:56 UTC 2017


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
---------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/c-safe-secure-studygroup/attachments/20170901/a2be9500/attachment.html>


More information about the C-safe-secure-studygroup mailing list