Hi Thorsten
I don't know of good reasons not to build with those options (there hasn't been 
a recent discussion I'm aware of), it was probably just an oversight.  The 
equivalent to fPIE has be on by default since VS 2010 on Windows.  Now may be a 
good time to enable these (just after the 16.04 release).  I created 
https://jira.allseenalliance.org/browse/ASACORE-2938, it will be discussed at 
the next triage meeting. 

Also, have you tested building with these options, and run the unit tests?

Greg

-----Original Message-----
From: [email protected] 
[mailto:[email protected]] On Behalf Of Thorsten 
Alteholz
Sent: Sunday, May 8, 2016 2:25 AM
To: [email protected]
Subject: [Allseen-core] compile options

Hi,

in Debian there are several QA tools that check whether packages comply with 
the Debian policy or have a technical problem.

Some of these complaints for the Alljoyn package are related to compiler 
options and are somewhat security related. I am aware that the framework builds 
on several platforms. I am referring to gcc on Linux here, but all modern 
compiler should have similar options.

- Is there a reason why the alljoyn-daemon is not compiled/linked with "-fPIE"?

   PIE is required for fully enabling Address Space Layout Randomization
   (ASLR), which makes "Return-oriented" attacks more difficult.

- Is there a reason why "-z relro" and "-z now" is not used while linking?

   During program load, several ELF memory sections need to be written to
   by the linker, but can be turned read-only before turning over control
   to the program. This prevents some GOT (and .dtors) overwrite attacks,
   but at least the part of the GOT used by the dynamic linker (.got.plt)
   is still vulnerable.

   During program load, all dynamic symbols are resolved, allowing for the
   complete GOT to be marked read-only (due to -z relro above). This
   prevents GOT overwrite attacks. For very large application, this can
   incur some performance loss during initial load while symbols are
   resolved, but this shouldn't be an issue for daemons.

- Is there a reason why "-D_FORTIFY_SOURCE=2" is not used?

   During code generation the compiler knows a great deal of information
   about buffer sizes (where possible), and attempts to replace insecure
   unlimited length buffer function calls with length-limited ones. This is
   especially useful for old, crufty code. Additionally, format strings in
   writable memory that contain '%n' are blocked. If an application depends
   on such a format string, it will need to be worked around.

   Note that for this feature to be fully enabled, the source must also be
   compiled with -O1 or higher.

In case this stuff has been discussed before, I would be glad to get a pointer 
to that discussion.

Best regards
Thorsten



_______________________________________________
Allseen-core mailing list
[email protected]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2flists.allseenalliance.org%2fmailman%2flistinfo%2fallseen-core&data=01%7c01%7cgregz%40microsoft.com%7cf5a64ff9fda34008a08308d377235d17%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=OVqcswQa56RIKNG3odqRNRlJAqBUsFA%2fFn2831mEdd8%3d
_______________________________________________
Allseen-core mailing list
[email protected]
https://lists.allseenalliance.org/mailman/listinfo/allseen-core

Reply via email to