Re: ASLR/PIE status in FreeBSD HEAD
On Wed, 20 May 2020 at 03:20, Damien DEVILLE wrote: > > Hi everyone, > > This a very good news. Thanks to Semihalf to their commitment on this subject. > At Stormshield as a security vendor using FreeBSD we are highly interested in > all subjects that enhance the security level of FreeBSD. > What is your target in term of timing ? Are there any plans to work on other > hardening subjects (like for example improving W^X) ? Do you have any roadmap > in terms of features and deadlines ? My goal is that we can test & enable these features in advance of FreeBSD 13.0 (although there's no published timeline for 13 yet). We can aim for iterating over each of the settings over the rest of this year. Basic W^X for mmap and mprotect at the system call interface is trivial - I put a(n untested) patch up at https://reviews.freebsd.org/D24933 as an illustration. There's a TODO in the description before this could be committable - adding procctl(2), proccontrol(1), and ELF tagging support. > We would be interested to take part to live discussions as a vendor if some > are planned. Sounds good. This will make a good topic in lieu of BSDCan developer summit sessions. Interested folks please email me off-list and fill in the poll of suitable times at http://whenisgood.net/qbmg72a ___ 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
Hi everyone, This a very good news. Thanks to Semihalf to their commitment on this subject. At Stormshield as a security vendor using FreeBSD we are highly interested in all subjects that enhance the security level of FreeBSD. What is your target in term of timing ? Are there any plans to work on other hardening subjects (like for example improving W^X) ? Do you have any roadmap in terms of features and deadlines ? We would be interested to take part to live discussions as a vendor if some are planned. Internally we have some plans to work on this subject with deadlines by the end of the year. Thanks to all of you for working on this subject, Damien -- Damien Deville IPS Technical Leader http://www.stormshield.eu Stormshield 2/6 Avenue de l'Horizon, Bat. 6 - FR 59650 Villeneuve d'Ascq - Le 14 Mai 20, à 10:00, Marcin Wojtas m...@semihalf.com a écrit : | Hi, | | wt., 5 maj 2020 o 12:03 Marcin Wojtas napisał(a): |> |> 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? |> | | Any thoughts about having a live discussion on the ALSR/PIE enablement topic? | | 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" ___ 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
Hi, wt., 5 maj 2020 o 12:03 Marcin Wojtas napisał(a): > > 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? > Any thoughts about having a live discussion on the ALSR/PIE enablement topic? 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
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"
Re: ASLR/PIE status in FreeBSD HEAD
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. > 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. ___ 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
On Wed, 22 Apr 2020 at 02:10, Dewayne Geraghty wrote: > > Thank-you for the pointer to elfctl. Unfortunately it looks like I need > to create the section in the image file, due to my: (for example) > > # elfctl -l /usr/bin/ztest > Known features are: > aslrDisable ASLR > protmax Disable implicit PROT_MAX > stackgapDisable stack gap > elfctl: NT_FREEBSD_FEATURE_CTL note not found > > on > FreeBSD 12.1-STABLE #0 r359973M: Thu Apr 16 amd64 1201513 1201513 Ah, yes - r340701 needs to be MFC'd to stable/12 to make this work there. ___ 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
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"
Re: ASLR/PIE status in FreeBSD HEAD
On Mon, Apr 20, 2020 at 04:21:59PM +0200, Marcin Wojtas wrote: > Hi Ed, > > pt., 17 kwi 2020 o 15:52 Ed Maste napisa??(a): > > > > On Fri, 17 Apr 2020 at 08:58, Marcin Wojtas wrote: > > > > > > Hi, > > > > > > Together with our customers, Semihalf is interested in improving the > > > status > > > of security mitigations enablement in FreeBSD. > > > > Happy to hear that there's interest in this work! > > > > > 1. Are there any hard blockers, like missing features or bugs, that > > > prevent > > > enabling ASLR by default in the kernel and building the base system with > > > -DWITH_PIE? > > > > I believe there are no showstopper issues but there are a some > > prerequisites. One is that there are some applications that may > > misbehave with randomization enabled. They would need to be > > identified, and tagged (with the elfctl tool now in the base system). > > 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. Our best bet is probably to make it easy for people to test and to try and recruit testers in the community (this is especially true for ports). -- Brooks signature.asc Description: PGP signature
Re: ASLR/PIE status in FreeBSD HEAD
Hi Ed, Any thoughts on the questions below? Best regards, Marcin pon., 20 kwi 2020 o 16:21 Marcin Wojtas napisał(a): > > Hi Ed, > > pt., 17 kwi 2020 o 15:52 Ed Maste napisał(a): > > > > On Fri, 17 Apr 2020 at 08:58, Marcin Wojtas wrote: > > > > > > Hi, > > > > > > Together with our customers, Semihalf is interested in improving the > > > status > > > of security mitigations enablement in FreeBSD. > > > > Happy to hear that there's interest in this work! > > > > > 1. Are there any hard blockers, like missing features or bugs, that > > > prevent > > > enabling ASLR by default in the kernel and building the base system with > > > -DWITH_PIE? > > > > I believe there are no showstopper issues but there are a some > > prerequisites. One is that there are some applications that may > > misbehave with randomization enabled. They would need to be > > identified, and tagged (with the elfctl tool now in the base system). > > 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? > > > > > > 2. In case the enablement becomes eventually approved, will it be better > > > to > > > do it for all archs or focus only on the selected ones? > > > > There's a general and increasing preference of avoiding different > > defaults per architecture. One issue though is that some options may > > have much larger performance impacts on certain architectures - e.g. > > position independent executables (PIE) on i386. > > Understood. If there is likely a performance trade-off, how about > doing tests e.g. on i386 and armv7? In case of a big drop or other > issues, could limiting ALSR/PIE to 64-bit-only be a considered > solution? > > > > > > 3. IMO it may be worth to benchmark/stress the system for the stability > > > verification and perf comparison purpose. Do you think it may be > > > reasonable > > > to create a kind of reference matrix (archs vs tests)? Those could be done > > > to evaluate the current state of the OS, but also for validating each > > > proposed feature. I also think engaging the FreeBSD CI might be a huge > > > help > > > in such an effort. BTW, any particular tests / benchmarks come to your > > > mind > > > as useful in this case? > > > > Yes, benchmarking and testing are very important tasks on a path to > > enabling these by default. I agree with the CI comment; we should > > start with CI build + kyua runs with options turned on, in advance of > > changing the default. > > 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? > > Even before the automation, would it be useful to perform some runs on > chosen archs? > > > > > I would be interested in seeing macro-level benchmarking with > > mitigations on/off - for example, I assume Firefox must have a > > performance test suite that they use for tracking their own > > performance changes during development, and we could use benchmarks > > like that to see the impact of mitigations. Coming up with a full set > > of appropriate benchmarks will be a useful endeavour. > > Yes, making use of something actively maintained would be great. Do > you see a need for IO stressing/benchmarking for the discussed cases? > > 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
Thank-you for the pointer to elfctl. Unfortunately it looks like I need to create the section in the image file, due to my: (for example) # elfctl -l /usr/bin/ztest Known features are: aslrDisable ASLR protmax Disable implicit PROT_MAX stackgapDisable stack gap elfctl: NT_FREEBSD_FEATURE_CTL note not found on FreeBSD 12.1-STABLE #0 r359973M: Thu Apr 16 amd64 1201513 1201513 I had a look inside # readelf -SW /usr/bin/ztest I also looked inside /usr/share/mk/bsd.prog.mk (because it has elf hardening knobs) but no clues. Perhaps if you could provide a pointer? (Though I wonder how the new section will be inserted into some of the ports that require gcc? An adventure awaits...) Kind regards, Dewayne. PS Yes Konstantin had previously provided substantial assistance to resolve the ntpd issue. On 21/04/2020 12:00 am, Ed Maste wrote: > On Sat, 18 Apr 2020 at 04:19, Dewayne Geraghty > wrote: >> >> I'm on a similar ride. We run applications in both i386 and amd64 jails >> with FreeBSD's ASLR enabled (sendmail, squid, apache, ...) and all good. > > Great! > >> On the build server, the i386 jail with aslr enabled wasn't able to >> build gcc9; so this was disabled kern.elf32.*. > > i386 has little spare address space and compiling applications as PIE > has a significant performance impact there, so enabling it only on > 64-bit seems quite reasonable. > >> ntp was the only real application that didn't play nicely with aslr. >> Fortunately, this was very helpful: >> >> /usr/bin/proccontrol -m aslr -s disable /usr/local/sbin/ntpd... > > Yes, and you can now (if using stable/12 or -CURRENT) use elfctl to > tag the binary with a note to request randomization be disabled for > the process, although we really should address the underlying issue. > ___ > 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"
Re: ASLR/PIE status in FreeBSD HEAD
On Mon, Apr 20, 2020 at 10:00:06AM -0400, Ed Maste wrote: > On Sat, 18 Apr 2020 at 04:19, Dewayne Geraghty > wrote: > > > > I'm on a similar ride. We run applications in both i386 and amd64 jails > > with FreeBSD's ASLR enabled (sendmail, squid, apache, ...) and all good. > > Great! > > > On the build server, the i386 jail with aslr enabled wasn't able to > > build gcc9; so this was disabled kern.elf32.*. > > i386 has little spare address space and compiling applications as PIE > has a significant performance impact there, so enabling it only on > 64-bit seems quite reasonable. With 4/4 i386 gained +1G for UVA, which makes i386 binaries behaviour on i386 kernel almost identical to amd64 kernel. > > > ntp was the only real application that didn't play nicely with aslr. > > Fortunately, this was very helpful: > > > > /usr/bin/proccontrol -m aslr -s disable /usr/local/sbin/ntpd... It is really -m stackgap that hurted ntpd, but I remember that the code which was causing problems, was removed since then. > > Yes, and you can now (if using stable/12 or -CURRENT) use elfctl to > tag the binary with a note to request randomization be disabled for > the process, although we really should address the underlying issue. ___ 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
Hi Ed, pt., 17 kwi 2020 o 15:52 Ed Maste napisał(a): > > On Fri, 17 Apr 2020 at 08:58, Marcin Wojtas wrote: > > > > Hi, > > > > Together with our customers, Semihalf is interested in improving the status > > of security mitigations enablement in FreeBSD. > > Happy to hear that there's interest in this work! > > > 1. Are there any hard blockers, like missing features or bugs, that prevent > > enabling ASLR by default in the kernel and building the base system with > > -DWITH_PIE? > > I believe there are no showstopper issues but there are a some > prerequisites. One is that there are some applications that may > misbehave with randomization enabled. They would need to be > identified, and tagged (with the elfctl tool now in the base system). 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? > > > 2. In case the enablement becomes eventually approved, will it be better to > > do it for all archs or focus only on the selected ones? > > There's a general and increasing preference of avoiding different > defaults per architecture. One issue though is that some options may > have much larger performance impacts on certain architectures - e.g. > position independent executables (PIE) on i386. Understood. If there is likely a performance trade-off, how about doing tests e.g. on i386 and armv7? In case of a big drop or other issues, could limiting ALSR/PIE to 64-bit-only be a considered solution? > > > 3. IMO it may be worth to benchmark/stress the system for the stability > > verification and perf comparison purpose. Do you think it may be reasonable > > to create a kind of reference matrix (archs vs tests)? Those could be done > > to evaluate the current state of the OS, but also for validating each > > proposed feature. I also think engaging the FreeBSD CI might be a huge help > > in such an effort. BTW, any particular tests / benchmarks come to your mind > > as useful in this case? > > Yes, benchmarking and testing are very important tasks on a path to > enabling these by default. I agree with the CI comment; we should > start with CI build + kyua runs with options turned on, in advance of > changing the default. 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? Even before the automation, would it be useful to perform some runs on chosen archs? > > I would be interested in seeing macro-level benchmarking with > mitigations on/off - for example, I assume Firefox must have a > performance test suite that they use for tracking their own > performance changes during development, and we could use benchmarks > like that to see the impact of mitigations. Coming up with a full set > of appropriate benchmarks will be a useful endeavour. Yes, making use of something actively maintained would be great. Do you see a need for IO stressing/benchmarking for the discussed cases? 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
On Sat, 18 Apr 2020 at 04:19, Dewayne Geraghty wrote: > > I'm on a similar ride. We run applications in both i386 and amd64 jails > with FreeBSD's ASLR enabled (sendmail, squid, apache, ...) and all good. Great! > On the build server, the i386 jail with aslr enabled wasn't able to > build gcc9; so this was disabled kern.elf32.*. i386 has little spare address space and compiling applications as PIE has a significant performance impact there, so enabling it only on 64-bit seems quite reasonable. > ntp was the only real application that didn't play nicely with aslr. > Fortunately, this was very helpful: > > /usr/bin/proccontrol -m aslr -s disable /usr/local/sbin/ntpd... Yes, and you can now (if using stable/12 or -CURRENT) use elfctl to tag the binary with a note to request randomization be disabled for the process, although we really should address the underlying issue. ___ 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
I'm on a similar ride. We run applications in both i386 and amd64 jails with FreeBSD's ASLR enabled (sendmail, squid, apache, ...) and all good. On the build server, the i386 jail with aslr enabled wasn't able to build gcc9; so this was disabled kern.elf32.*. ntp was the only real application that didn't play nicely with aslr. Fortunately, this was very helpful: /usr/bin/proccontrol -m aslr -s disable /usr/local/sbin/ntpd... And yes we started with HardenedBSD which was very successful in late 2018, and contains many good ideas. As some applications on the On 17/04/2020 10:58 pm, Marcin Wojtas wrote: > Hi, > > Together with our customers, Semihalf is interested in improving the status > of security mitigations enablement in FreeBSD. To start with, based on our > initial research it seems that after 2019 enhancements the ASLR/PIE > features are in pretty much ready state. > > Building the world using the 'WITH_PIE' flag produced proper binaries and > the sanity showed no obvious degradations. Additionally, for the ASLR we > performed a comparison of the pax tests ( > https://github.com/opntr/paxtest-freebsd) for amd64/arm64 and they indicate > the feature is working fine after setting the according sysctl knobs. I'd > be happy to present the results and discuss the details, but firstly I'd > like to ask more general questions: > > 1. Are there any hard blockers, like missing features or bugs, that prevent > enabling ASLR by default in the kernel and building the base system with > -DWITH_PIE? > > 2. In case the enablement becomes eventually approved, will it be better to > do it for all archs or focus only on the selected ones? > > 3. IMO it may be worth to benchmark/stress the system for the stability > verification and perf comparison purpose. Do you think it may be reasonable > to create a kind of reference matrix (archs vs tests)? Those could be done > to evaluate the current state of the OS, but also for validating each > proposed feature. I also think engaging the FreeBSD CI might be a huge help > in such an effort. BTW, any particular tests / benchmarks come to your mind > as useful in this case? > > I'd appreciate any feedback. > > Best regards, > Marcin Wojtas (mw@) > ___ > 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"
Re: ASLR/PIE status in FreeBSD HEAD
On Fri, 17 Apr 2020 at 09:13, Shawn Webb wrote: > > Quick note: paxtest's algorithms for measuring ASLR was meant to test > ASLR, not FreeBSD's ASR implementation. Thus, paxtest results for > FreeBSD's ASR are moot. paxtest's entropy estimate is superficial, and indeed can produce a more or less invalid result depending on the distribution of allocated objects. There are a number of other tools which perform a more rigorous or comprehensive analysis. paxtest is useful in providing basic indication of whether various things are randomized or not. ___ 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
On Fri, 17 Apr 2020 at 08:58, Marcin Wojtas wrote: > > Hi, > > Together with our customers, Semihalf is interested in improving the status > of security mitigations enablement in FreeBSD. Happy to hear that there's interest in this work! > 1. Are there any hard blockers, like missing features or bugs, that prevent > enabling ASLR by default in the kernel and building the base system with > -DWITH_PIE? I believe there are no showstopper issues but there are a some prerequisites. One is that there are some applications that may misbehave with randomization enabled. They would need to be identified, and tagged (with the elfctl tool now in the base system). > 2. In case the enablement becomes eventually approved, will it be better to > do it for all archs or focus only on the selected ones? There's a general and increasing preference of avoiding different defaults per architecture. One issue though is that some options may have much larger performance impacts on certain architectures - e.g. position independent executables (PIE) on i386. > 3. IMO it may be worth to benchmark/stress the system for the stability > verification and perf comparison purpose. Do you think it may be reasonable > to create a kind of reference matrix (archs vs tests)? Those could be done > to evaluate the current state of the OS, but also for validating each > proposed feature. I also think engaging the FreeBSD CI might be a huge help > in such an effort. BTW, any particular tests / benchmarks come to your mind > as useful in this case? Yes, benchmarking and testing are very important tasks on a path to enabling these by default. I agree with the CI comment; we should start with CI build + kyua runs with options turned on, in advance of changing the default. I would be interested in seeing macro-level benchmarking with mitigations on/off - for example, I assume Firefox must have a performance test suite that they use for tracking their own performance changes during development, and we could use benchmarks like that to see the impact of mitigations. Coming up with a full set of appropriate benchmarks will be a useful endeavour. ___ 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
On Fri, Apr 17, 2020 at 02:58:06PM +0200, Marcin Wojtas wrote: > Hi, > > Together with our customers, Semihalf is interested in improving the status > of security mitigations enablement in FreeBSD. To start with, based on our > initial research it seems that after 2019 enhancements the ASLR/PIE > features are in pretty much ready state. > > Building the world using the 'WITH_PIE' flag produced proper binaries and > the sanity showed no obvious degradations. Additionally, for the ASLR we > performed a comparison of the pax tests ( > https://github.com/opntr/paxtest-freebsd) for amd64/arm64 and they indicate > the feature is working fine after setting the according sysctl knobs. I'd > be happy to present the results and discuss the details, but firstly I'd > like to ask more general questions: Quick note: paxtest's algorithms for measuring ASLR was meant to test ASLR, not FreeBSD's ASR implementation. Thus, paxtest results for FreeBSD's ASR are moot. Link to the relevant discussion, as pointed out by the dude who coined the term ASLR: https://reviews.freebsd.org/D5603#120017 Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
