[OE-core] [PATCH 1/2] security_flags: turn potential string format security issues into an error

[Khem Raj]

> On Apr 28, 2016, at 9:22 AM, Richard Purdie <richard.purdie at linuxfoundation.org> wrote:
> 
> On Thu, 2016-04-28 at 08:58 -0700, Khem Raj wrote:
>>> On Apr 28, 2016, at 6:27 AM, Joshua Lock <joshua.g.lock at intel.com>
>>> wrote:
>>> 
>>> -SECURITY_CFLAGS ?= "-fstack-protector-strong -pie -fpie
>>> ${lcl_maybe_fortify}"
>>> -SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong
>>> ${lcl_maybe_fortify}"
>>> +# Error on use of format strings that represent possible security
>>> problems
>>> +SECURITY_STRINGFORMAT ?= "-Wformat -Wformat-security
>>> -Werror=format-security"
>>> +
>>> +SECURITY_CFLAGS ?= "-fstack-protector-strong -pie -fpie
>>> ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
>>> +SECURITY_NO_PIE_CFLAGS ?= "-fstack-protector-strong
>>> ${lcl_maybe_fortify} ${SECURITY_STRINGFORMAT}"
>>> 
>>> SECURITY_LDFLAGS ?= "-fstack-protector-strong -Wl,-z,relro,-z,now"
>>> SECURITY_X_LDFLAGS ?= "-fstack-protector-strong -Wl,-z,relro"
>>> @@ -92,6 +95,23 @@ SECURITY_CFLAGS_pn-zlib =
>>> "${SECURITY_NO_PIE_CFLAGS}"
>>> SECURITY_CFLAGS_pn-ltp = "${SECURITY_NO_PIE_CFLAGS}"
>>> SECURITY_CFLAGS_pn-pulseaudio = "${SECURITY_NO_PIE_CFLAGS}"
>>> 
>>> +# Recipes which fail to compile when elevating -Wformat-security
>>> to an error
>>> +SECURITY_STRINGFORMAT_pn-busybox = ""
>>> +SECURITY_STRINGFORMAT_pn-console-tools = ""
>>> +SECURITY_STRINGFORMAT_pn-cmake = ""
>>> +SECURITY_STRINGFORMAT_pn-expect = ""
>>> +SECURITY_STRINGFORMAT_pn-gcc = ""
>>> +SECURITY_STRINGFORMAT_pn-gettext = ""
>>> +SECURITY_STRINGFORMAT_pn-kexec-tools = ""
>>> +SECURITY_STRINGFORMAT_pn-leafpad = ""
>>> +SECURITY_STRINGFORMAT_pn-libuser = ""
>>> +SECURITY_STRINGFORMAT_pn-ltp = ""
>>> +SECURITY_STRINGFORMAT_pn-makedevs = ""
>>> +SECURITY_STRINGFORMAT_pn-oh-puzzles = ""
>>> +SECURITY_STRINGFORMAT_pn-stat = ""
>>> +SECURITY_STRINGFORMAT_pn-unzip = ""
>>> +SECURITY_STRINGFORMAT_pn-zip = ""
>> 
>> Can we use _remove operation instead of introducing a new variable
>> and emptying it out here.
> 
> I actually suggested we do the above. The reason is that this way, the
> user can configure which flags they actually want to use. "remove" also
> has the problem that its near impossible for the user to override
> further.
> 

Thats right, and I was of the view that security flags should be one set
and not offered at combination of multiple options, we just end up increasing
the test matrix.

> I'm starting to believe that remove usage in OE-Core itself is actually
> symptomatic of a problem and that if we end up using it, it probably
> should be done differently.
> 

I believe _remove has the potential to be abused yes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160428/5065b176/attachment-0002.sig>