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

Richard Purdie richard.purdie at linuxfoundation.org
Thu Apr 28 16:22:16 UTC 2016


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.

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





More information about the Openembedded-core mailing list