Page MenuHomeFreeBSD

bsdinstall: adjust ASLR knob to new defaults
AbandonedPublic

Authored by mw on Nov 4 2021, 3:44 PM.
Tags
None
Referenced Files
Unknown Object (File)
Oct 1 2024, 7:31 PM
Unknown Object (File)
Sep 30 2024, 5:12 AM
Unknown Object (File)
Sep 29 2024, 5:53 PM
Unknown Object (File)
Sep 27 2024, 3:41 AM
Unknown Object (File)
Sep 26 2024, 10:17 AM
Unknown Object (File)
Sep 24 2024, 8:39 AM
Unknown Object (File)
Sep 23 2024, 6:36 AM
Unknown Object (File)
Sep 7 2024, 8:36 PM
Subscribers
None

Details

Reviewers
emaste
andrew
imp
Summary

The ASLR feature is now disabled on 32- and enabled on 64-bit
architectures. Reflect these changes in the hardening dialog menu.

In order to handle both cases in a single menu tick the "enable_aslr"
option on the 64-bit platforms.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

mw requested review of this revision.Nov 4 2021, 3:44 PM
mw created this revision.
usr.sbin/bsdinstall/scripts/hardening
80

In general there is a preference for positive-sense controls - this is from sysctl(9) but I think the logic applies: "For boolean sysctls, negative logic should be totally avoided."

Can we leave this as enable_aslr defaulted to on?

usr.sbin/bsdinstall/scripts/hardening
80

In general there is a preference for positive-sense controls - this is from sysctl(9) but I think the logic applies: "For boolean sysctls, negative logic should be totally avoided."

Thanks, I'm aware of this requirement for sysctls, but what about the knobs for the controls that are actually enabled by default in the kernel? This seems to be the case for e.g. disable_ddtrace menu option.

Can we leave this as enable_aslr defaulted to on?

For 32-bit that would obviously keep the things simple, but in case https://reviews.freebsd.org/D27666 lands, enable_aslr will become useless for all 64-bit platforms. My reasoning was to allow user to optionally disable the feature during installation phase on amd64, arm64, etc. Thoughts?

New options should be positive logic always, even if the default is to set them to true. It's proven less confusing over time to do this than have the negative logic. Especially if we ever need to change the default.

In D32833#741397, @imp wrote:

New options should be positive logic always, even if the default is to set them to true. It's proven less confusing over time to do this than have the negative logic. Especially if we ever need to change the default.

Having said that, bsdinstall should have these things be a toggle based on the current setting... but that's a much bigger ask...

In D32833#741402, @imp wrote:
In D32833#741397, @imp wrote:

New options should be positive logic always, even if the default is to set them to true. It's proven less confusing over time to do this than have the negative logic. Especially if we ever need to change the default.

Having said that, bsdinstall should have these things be a toggle based on the current setting... but that's a much bigger ask...

Would you prefer then to:

  • get back to enable_aslr
  • on 64-bit systems it would appear as marked by default:

bsdinstall_64bit.png (689×899 px, 52 KB)

  • on 32-bit systems the box would remain empty:

bsdinstall_32bit.png (677×913 px, 57 KB)

Please confirm.

If yes, I can invert the proposed logic, however the script may get a bit more messy.

mw edited the summary of this revision. (Show Details)
  • Invert the logic and return to enable_aslr.
  • The option is ticked on 64-bit archs by default.
  • Take a number of arch bits into consideration in the dialog menu description and when modifying the sysctls.

@emaste Please confirm if we should just revert 020f4112559ebf7e94665c9a69f89d21929ce82a instead of this patch.

@emaste Have you decided about your preference whether we should update the menu option or remove it?

I originally made some suggestions on sense of the controls (+ve or -ve) in earlier comments but did not yet think about this holistically. We (@mw, myself, and others) discussed this on a call last week, and on further reflection I think we should just revert R10:020f4112559e. Right now (prior to ASLR default changes) that menu exists to turn on "mitigation"/"hardening" options that are not enabled by default. With ASLR defaulting to on IMO it's clearer to just remove the option from the menu - including options that are already on by default will be more confusing IMO.

To be perfectly clear, my preference is:

  1. commit D27666
  2. revert R10:020f4112559ebf7e94665c9a69f89d21929ce82a

Thanks. I will abandon this patch and I'm planning to add a following comment in the revert commit message:

Because now ASLR is enabled by default for 64-bit architectures
and the purpose of the installation menu is to allow choosing
additional 'mitigation'/'hardening' options that are originally
disabled, remove the ASLR knob from bsdinstall.

Please me know if it's sufficient.