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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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@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.

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.

Cheers,

Richard