Hi,
Sorry for the top-post. Just to Amplify a but if what Niels has already
said——
Yes, in Fedora, the glusterfs.spec file has a line
%global _hardened_build 1
at the top. This enables PIE and RELRO in Fedora and EPEL builds.
This line exists in the glusterfs.spec.in file in the Gluster source
tree too.
Debian-based builds have something analogous. (We don't have the Debian
packing pieces in our source as we do for RPMs. I wanted it, but the
community dictated otherwise.)
Using hardened builds gives us the "belt and suspenders" model. IOW we
fix things that Coverity finds as fast as we can, and then hardened
builds (i.e. PIE + RELRO) close any gaps that Coverity hasn't found or
that Coverity has found but haven't been fixed yet. We have a long list
of Coverity issues that remain to be worked through.
I'm not aware that compiling with PIE and RELRO provide anything of
value for mainline development. There are no exra warnings or errors —
nothing that the developer would have to change or fix as a function of
their ordinary development practices. The executables that a developer
produces are meant for development and debugging. PIE and RELRO don't
get in the way, but they don't help either.
I don't see any reason to enable this in the autoconf config or build.
And, BTW, Coverity isn't the end-all solution to code quality and
application security. Things like cpp-check, clang-analyze, even just
using the Intel, AMD, Clang, and `gcc -pedantic` compilers will find
lots of potential bugs just by compiling with them — bugs that gcc
doesn't even warn about.
Thanks,
--
Kaleb
On 04/02/2015 07:58 AM, Venky Shankar wrote:
On 03/31/2015 12:45 PM, Niels de Vos wrote:
On Tue, Mar 31, 2015 at 12:20:19PM +0530, Kaushal M wrote:
IMHO, doing hardening and security should be left the individual
distributions and the package maintainers. Generally, each distribution has
it's own policies with regards to hardening and security. We as an upstream
project cannot decide on what a distribution should do. But we should be
ready to fix bugs that could arise when distributions do hardened builds.
So, I vote against having these hardening flags added to the base GlusterFS
build. But we could add the flags the Fedora spec files which we carry with
our source.
Indeed, I agree that the compiler flags should be specified by the
distributions. At least Fedora and Debian do this already include
(probably different) options within their packaging scripts. We should
set the flags we need, but not more. It would be annoying to set default
flags that can conflict with others, or which are not (yet) available on
architectures that we normally do not test.
Niels
I echo the same. But, just for educational purposes it would be good to
know what kind of attack(s) [buffer/heap overflows] GlusterFS is
vulnerable as of now and probably fix them if possible (Coverity does
the job for us to some extent, correct?). Are there any tools for this
out in the open?
~kaushal
On Tue, Mar 31, 2015 at 11:49 AM, Atin Mukherjee<amukh...@redhat.com>
wrote:
Folks,
There are some projects which uses compiler/glibc features to strengthen
the security claims. Popular distros suggest to harden daemon with
RELRO/PIE flags. You could see [1] [2] [3]
Partial relro is when you have -Wl,-z,relro in the LDFLAGS for building
libraries. Partial relro means that some ELF sections are reordered so
that overflows in some likely sections don't affect others and the local
offset table is readonly. To get full relro, you also need to have:
-Wl,-z,bind_now added to LDFLAGS. What this does is make the Global
Offset table and Procedure Lookup Table readonly. This takes
some time, so its only worth it for apps that have a real possibility of
being attacked. This would be setuid/setgid/setcap and daemons. There
are some security critical apps that can have this too. If the apps
likely parses files from an untrusted source (internet), then it might
also want to have full relro.
To enable PIE, you would pass -fPIE -DPIE in the CFLAGS and -pie in the
LDFLAGS. What PIE does is randomize the locations of important items
such as the base address of an executable and position of libraries,
heap, and stack, in a process's address space. Sometimes this is called
ASLR. Its designed to make buffer/heap overflow, return into libc
attacks much harder. Part of the way it does this is to make a new
section in the ELF image that is writable to redirect function calls to
the correct address (offsets). This has to be writable because each
invocation will have different layouts and needs to be fixed up. So,
when you have an application with PIE, you want full relro so that
these sections become readonly and not part of an attacker's target areas.
I would like to hear from the community whether we should introduce
these hardening flags in glusterfs as well.
[1]https://fedorahosted.org/fesco/ticket/563
[2]https://wiki.debian.org/Hardening
[3]https://wiki.ubuntu.com/Security/Features#relro
--
~Atin
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
