Date: Tue, 5 May 2020 09:38:44 +1000 From: Dewayne Geraghty <dewayne@heuristicsystems.com.au> To: Ed Maste <emaste@freebsd.org>, Brooks Davis <brooks@freebsd.org> Cc: freebsd-security@freebsd.org, Marcin Wojtas <mw@semihalf.com>, Rafal Jaworowski <raj@semihalf.com> Subject: Re: ASLR/PIE status in FreeBSD HEAD Message-ID: <9ad00dc0-b9d5-525a-9d5d-b65dac60f0d4@heuristicsystems.com.au> In-Reply-To: <CAPyFy2DGh8sa=VYuHF8aC2NU5LkpMLsBv1kQ-zkEbPyz_z9JzA@mail.gmail.com> References: <CAPv3WKfYyVnfNDTPOEN6TF_GjJr=ThdNeB1yMtTEoQoxEdHMDg@mail.gmail.com> <CAPyFy2Cis6mKP%2BtRqEG8CwODgLXVBpQsxQ4FJX6wrpiPODr=Bg@mail.gmail.com> <CAPv3WKdQrS4oAcUcNn_mQOUJCmKm88LWhv62yf5B0BkmnyGpaA@mail.gmail.com> <20200423153835.GF42225@spindle.one-eyed-alien.net> <CAPyFy2DGh8sa=VYuHF8aC2NU5LkpMLsBv1kQ-zkEbPyz_z9JzA@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
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@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-unsubscribe@freebsd.org" >help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9ad00dc0-b9d5-525a-9d5d-b65dac60f0d4>