Re: ASLR/PIE status in FreeBSD HEAD
On Mon, 4 May 2020 at 19:39, Dewayne Geraghty wrote: > > 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. The general intent for elfctl isn't to have a lot of knobs to worry about, either user- or developer-facing, and they'll generally be opt-outs. Ports with known incompatibilities will be tagged at build time (regardless of whether mitigations are enabled), and mitigations should be able to be turned on system-wide. We should be able to address non-executable stack in a similar way - virtually all ports should have a RW GNU_STACK segment indicating that the stack is not executable, so a ports build stage could check for that and produce an error if not, with some sort of override for any exceptional cases. We definitely want some global infrastructure for pie, relro, and bind_now. ___ 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"
Re: ASLR/PIE status in FreeBSD HEAD
pon., 4 maj 2020 o 17:24 Ed Maste napisał(a): > > On Mon, 20 Apr 2020 at 10:22, Marcin Wojtas wrote: > > > > Indeed I thought of kyua and measuring buildworld execution time for > > stressing the DUT and having the first comparison numbers for the low > > price. > > > > Do you think it is possible to get help here, i.e. is there a FreeBSD > > devops team, maintaining the Jenkins CI whose spare cycles could be > > used for this purpose? Or is this a field requiring external help from > > interested parties? > > There aren't a lot of spare cycles to go around, but putting > automation in place so that tests like this can easily be performed is > certainly something that's in the Jenkins team's domain. Of course the available bandwidth is a limitation, but IMO we should start with defining the requirements so that eventually it could be added to the backlog. > > > Yes, making use of something actively maintained would be great. Do > > you see a need for IO stressing/benchmarking for the discussed cases? > > In the fullness of time I think it's important, but my opinion is that > it's really functional tests that we need, for enabling features in > -CURRENT; we can work on benchmarking before and after changing a > default. Understood. Since there seem to be no blockers / major objections at this point, how do you suggest proceed with the topic? How about having a live discussion with interested parties, so that we can establish at least a rough plan allowing to achieve the enablement of this (and possibly other) feature in a foreseeable perspective? Best regards, Marcin ___ 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"
Re: ASLR/PIE status in FreeBSD HEAD
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 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"
