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 <bro...@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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org" > _______________________________________________ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
