ASLR/PIE status in FreeBSD HEAD

[Dewayne Geraghty]

It would be palatable to have a "secure.mk" under /usr/ports/Mk/Uses
that enables  pie, relro, now, noexecstack and elfctl features.  Then
port users can enable/disable their (elfctl) default features as they wish.

I look forward to removing long lists of category/ports from my
make.conf that make these adjustments at the moment.  All of my internet
facing services use the above settings (sans elfctl).  We also have a
production system that uses these applications with aslr and stackgap=1
under i386 successfully.  :)

I'd also throw cfo into the mix, but small steps grasshopper...

To Ed, I like the notion of elfctl because it allows me to set once and
forget about how the executable should run, so setting a default at
buildtime is a good idea.  (I had to think about this for awhile as I
prefer the explicitness of proccontrol, however elfctl is akin to chmod
in that its a control that isn't set everytime a program is run.)

I supposed proccontrol will override elfctl settings?

Regards, Dewayne
PS The elfctl manpage's History states that elfctl first appeared in
FBSD 13, I'm using 12.1 Stable ;)


 that On 5/05/2020 1:11 am, Ed Maste wrote:
> On Thu, 23 Apr 2020 at 11:38, Brooks Davis <brooks at freebsd.org> wrote:
>>
>>> I was thinking if it is possible to come up with such wide test
>>> coverage to test every single application from the base system. Do you
>>> think it is achievable or should we rather follow the approach to do
>>> as many tests as possible, but rely on the community feedback to catch
>>> the corner cases (like the ntpd issue mentioned in this thread)?
>>> What about the ports?
>>
>> If we gate on full testing we'll never move forward.  We had a GSoC
>> project a few years ago to try to generate lame tests for each program,
>> if someone picked that up, we could get better coverage fairly
>> quickly, but it would still be far from complete.
> 
> Indeed, having a basic smoke test for as much of the base system as
> possible is a good initial step. I suspect it won't take very long to
> have confidence in turning on options for the base system, but ports
> will be a much longer process.
> 
> For ports I think the first thing that needs to happen is to have some
> infrastructure in ports itself to allow individual ports to indicate
> (via elfctl) that they are not compatible with certain options; with
> that in place it should be trivial to start marking individual ports.
> _______________________________________________
> freebsd-security at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org"
>