Re: CFLAGS overridden by distribution build system

[William Roberts <bill.c.roberts@gmail.com>]

On Fri, May 29, 2020 at 8:31 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Sat, May 23, 2020 at 11:59 AM William Roberts
> <bill.c.roberts@gmail.com> wrote:
> >
> > On Sat, May 23, 2020 at 5:57 AM Laurent Bigonville <bigon@debian.org> wrote:
> > >
> > > Hello,
> > >
> > > The current build system of the userspace is setting a lot of CFLAGS,
> > > but most of these are overridden by the distributions when building.
> > >
> > > Today I received a bug report[0] from Christian Göttsche asking me to
> > > set -fno-semantic-interposition again in libsepol. I see also the same
> > > flag and also a lot of others set in libselinux and libsemanage build
> > > system.
> >
> > Why would it be again? The old DSO design made that option impotent.
> > Clang does it by default.
> >
> > >
> > > For what I understand some of these are just needed for code quality
> > > (-W) and could be controlled by distributions but others might actually
> > > need to be always set (-f?).
> >
> > If you look at the Makefiles overall in all the projects, you'll see hardening
> > flags, etc. Libsepol has a pretty minimal set compared to say libselinux, but
> > they all get overridden by build time CFLAGS if you want.
> >
> > >
> > > Shouldn't the flags that always need to be set (which ones?) be moved to
> > > a "override CFLAGS" directive to avoid these to be unset by distributions?
> >
> > If you we're cleaver with CFLAGS before, you could acually circumvent
> > the buildtime
> > DSO stuff. While i'm not opposed to adding it to immutable flag, if
> > you're setting
> > CFLAGS, you're on your own. At least with the current design.
> >
> > I have no issues with adding it to override, but we would have to
> > overhaul a bunch
> > of them and make them consistent.
>
> I'm inclined to agree with Laurent here - we should always set this
> flag in order to preserve the same behavior prior to the patches that
> removed hidden_def/hidden_proto and switched to relying on this
> instead.

Theirs a lot of features that rely on particular cflags, consider hardening
options. A lot of the warnings/error stuff is not just a code hygiene, but also
spotting potential issues that could arise as security issues. If one starts
tinkering with cflags, you can really change the code quite a bit. This is why
some places only approve sanctioned builds of crypto libraries.

But one of the things to consider is that for clang builds, clang
doesn't support
this option, so we would need to move the compiler checking code into each
projects root makefile and ensure any consuming subordinate leafs add a
default, or move it to the global makefile and make sure each leaf that needs it
has a default.