[Gluster-devel] Security hardening RELRO & PIE flags

[Venky Shankar]

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 <amukherj at 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 at gluster.org
>>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://www.gluster.org/mailman/listinfo/gluster-devel
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20150402/fdbdf679/attachment-0001.html>