To promote some of very useful but less known system security settings I've added new bsdinstall step with few carefully picked options to be enabled there by default, thus increasing the security of default installation and promoting usage of these technologies and features.
Details
Details
Apply the patch, build bsdinstall, run installer in a VM using built bsdinstall, review the end result /etc/sysctl.conf and /etc/rc.conf settings.
Diff Detail
Diff Detail
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
| usr.sbin/bsdinstall/scripts/hardening | ||
|---|---|---|
| 42 | I think this would read better as "Disable process debugging facilities for unprivileged users" | |
| 45 | I think enabling this by default is a POLA violation. I would rather not enable this by default | |
| 47 | It might make more sense to move this one to the 'services' menu. | |
Comment Actions
@allanjude See my comments inline.
| usr.sbin/bsdinstall/scripts/hardening | ||
|---|---|---|
| 45 | Since its just an bsdinstall option, that wont change default system behaviour for users upgrading their existing systems and those not using bsdinstall for OS installation, and is in plain sight for those that are, I think this is not a POLA violation, so I'd keep it here. | |
| 47 | This is strictly related to system hardening in this context, that's why I kept it here. | |
| usr.sbin/bsdinstall/scripts/hardening | ||
|---|---|---|
| 45 | I agree not a POLA violation. | |
Comment Actions
This is a nice piece of code. However, we should make the defaults for everything be off: if you press enter all the way through the installer, you should get the same results as if you had run make installworld installkernel distribution DESTDIR=/whatever. Put another way, bsdinstall is one of several legitimate ways to install the operating system and the default settings for FreeBSD should not depend on your choice of installation mechanism.
You may also want to include some subset of these for jail installations (scripts/jail).
Comment Actions
@nwhitehorn I kindly disagree on making all options off by default, on several grounds:
- the idea is to promote existing technologies for securing the default FreeBSD installation, so once disabled by default, they wont have any real impact on security of 'default' installation since they'll become merely useful shortcuts for enabling some of the options. The idea is that once these settle down in 'defaut' installations thanks to that bsdinstall menu and proposed set of options, they will get turned on by default for 'real' and removed from bsdinstall (as they'll be obsolete by then).
- if someone is blindly pressing enter while doing a new installation of new major OS version, then he's doing it wrong in first place, and all unexpected changes are on his account (same goes for ZFS being default, as an example)
Could you please elaborate a bit more what you meant about adding these options to scripts/jail? When/how's that being used, which subset you'd like to see added?
Comment Actions
Can you clarify something, if a user never clicks into the Hardening menu, will these new defaults be applied? Or are they only applied if they click into the Hardening menu and opt-in?
Comment Actions
@bdrewery This is how it works: its a new installer menu that will appear every time, just right after the services menu (and in the same way that services menu appears each time and for everybody). This menu looks exactly like services one, there's a list of options, out of which most are marked by default (and one is not). The user then can either mark/unmark as he sees fit, or accept proposed defaults and hit enter to have them applied to the installation. After that, the next steps of usual installations are performed, whatever they were right after services menu. The user can't ever 'not click into Hardening menu' just as he can't ever 'not click into services menu'.
Comment Actions
At the end of each line in the menu part of the diff, they are set to 'on' or 'off' by default. All are on by default except entirely disabling sendmail.
I will leave it to others to decide if enabling all of these options by default is a good idea or not.
Comment Actions
@bdrewery It's hard to answer to such question. In my opinion, they are not - they will only be applied if following conditions are met:
- user uses bsdinstall to perform fresh installation (so users of freebsd-update or customized isntallation methods, like scripts for jails unpacking base.txz and other, wont be affected)
- user goes through the installation steps of bsdinstall, automatically goes via hardening menu and accepts the proposed defauls - at this point user can freely mark/unmark every single option proposed to disable its application to the installation
If those are not met, then in every other case, those options wont be applied. The only way is via bsdinstall and acceptance of proposed defaults (just as with services menu and sshd for example) so, again, I think they're not forced on users - they're strongly proposed ;)
Comment Actions
My question is only about using bsdinstall. I don't feel I'm getting the right answer yet. If I use bsdinstall and just click install and never go into the services/hardeneing sections will these be enabled by default? I see that the options are coded as default on, but does it require going into the hardening section to actually activate the defaults on them?
You say 'conditions not met' and 'not forced on users' but also say they have to 'accept the proposed defaults', of ON right?
Comment Actions
Surely, showing the options is enough for that: having a small set of things presented with clear descriptions is quite a recommendation already. Much of the point of bsdinstall, as opposed to sysinstall, was also to reduce magic in the installer. If we want these things really on by default, then they should really be on by default in the base system. As an example, all of the services in the services menu are off by default since that matches the outcome of having a blank rc.conf.
- if someone is blindly pressing enter while doing a new installation of new major OS version, then he's doing it wrong in first place, and all unexpected changes are on his account (same goes for ZFS being default, as an example)
ZFS isn't the default. A major design goal of the installer is that you should get a sane working system by pressing Enter repeatedly. This makes it much easier for new users.
Could you please elaborate a bit more what you meant about adding these options to scripts/jail? When/how's that being used, which subset you'd like to see added?
Whichever apply to jails (I don't know whether some of these sysctls can be set per-jail, for instance).
Comment Actions
The current patch brings up this menu in the standard installation with these set to on. If the user does nothing in particular and accepts the defaults on all screens in the installer, these options will be set ON. You don't need to specifically choose the hardening menu.
Comment Actions
@bdrewery I don't really understand - its not possible to 'just click install and not go to services menu' at least as far as I am aware. And just in the same way, it is not possible to not get (because 'go to' is a wrong word here) hardening menu, as it is not possible not to get services menu (and network configuration menu, and others).
Also, they don't 'have to' accept these options, they can press space to disable all/any of them as they wish before proceeding. But that's true, that blindly pressing enter will apply the options that are ON by default, but as I said, blindly pressing enter in a installed of new major release of the OS is very wrong in my book.
Comment Actions
Simple questions beg simple answers. Yes, hardening on by default.
I would prefer this was all gated by a 'Harden' option before enabling them. I do agree with Nathan that the defaults from the installer should match what other installation means provide. I think having something like an rc.conf setting of system_harden=on gate the addition of sysctl.conf.hardening (from /etc/rc.d/sysctl, not appended in sysctl.conf), and apply any other settings for hardening such as securelevel. In short I think a lot more discussion and design is needed around this. I have for a long time hated that these sysctls were on insecure defaults, but if we are going to change them we should do so in a more obvious way and ensure users know the impact of them. Upon a second look this patch seems like a backdoor attempt to fix the defaults rather than doing it properly in the kernel and providing services for activating/deactivating hardening and selection of system profiles like desktop/server/development which could chose reasonable defaults based on the profile.
Comment Actions
Surely, showing the options is enough for that: having a small set of things presented with clear descriptions is quite a recommendation already. Much of the point of bsdinstall, as opposed to sysinstall, was also to reduce magic in the installer. If we want these things really on by default, then they should really be on by default in the base system. As an example, all of the services in the services menu are off by default since that matches the outcome of having a blank rc.conf.
I am more than happy to get them enabled in base. But here's the thing - I will have 10 times larger issues in convincing larger set of people to do so (that's required to get things changed in base) than I already have in such 'safe' place as the installer of next major OS version. ;)
And by the way, services has dumpdev option on by default.
Whichever apply to jails (I don't know whether some of these sysctls can be set per-jail, for instance).
Sorry, but I still dont understand your request.
Comment Actions
Here's the thing.
I think it's a bit late to introduce new defaults for installing 11.0 right at the end of the dev cycle. I think we risk a big backlash and our user community is already hesitant to change enough.
I think we should put this stuff in but have it not enabled by default, and /then/ the moment 11 is branched we flip the switch on in -head. People can then complain about -head being different and we can say "it's -head! welcome to the new world."
I think we can aim to have this flipped on by default for say, 11.1.
Comment Actions
It's also not good that these defaults are maintained only in bsdinstall. If we want to add more or modify them then we have no means to do so from freebsd-update or installworld or package updates since the build is not managing this file, but only bsdinstall is. Users will only get benefits from a reinstall (or bsdconfig if it shares code with this).
Comment Actions
Simple questions beg simple answers. Yes, hardening on by default.
I would prefer this was all gated by a 'Harden' option before enabling them. I do agree with Nathan that the defaults from the installer should match what other installation means provide. I think having something like an rc.conf setting of system_harden=on gate the addition of sysctl.conf.hardening (from /etc/rc.d/sysctl, not appended in sysctl.conf), and apply any other settings for hardening such as securelevel. In short I think a lot more discussion and design is needed around this. I have for a long time hated that these sysctls were on insecure defaults, but if we are going to change them we should do so in a more obvious way and ensure users know the impact of them. Upon a second look this patch seems like a backdoor attempt to fix the defaults rather than doing it properly in the kernel and providing services for activating/deactivating hardening and selection of system profiles like desktop/server/development which could chose reasonable defaults based on the profile.
You are correct here in some way - this may be seen as a 'backdoor' but it is not intended to be something like that. Its a result of a reality check - these things were in insecure defaults *exactly* because its so hard, near to impossible, to convince people they should be on, and the most loud argument is about not changing 'the default system behavior'.
Since reality looks like it looks, my plan, and intention of this patch is to provide safer default OS installation, where it hurts least - in the installer of new major OS version, where changes like that *can be expected*. Once these are in, and we're in 11.1 or 11.3, we can then raise discussion on changing them in base and introducing them as real defaults, and we'll have a major argument in hands - that they are in the default installer options, and, hopefully, users are not complaining, and, again hopefully, we've won some positive PR by 'increasing system security'. One argument we dont have today.
Comment Actions
I would approve a patch that added this screen, but in such a way that it was accessed only from the menu at the end (like the "docsinstall" step) rather than something that comes up by default. It would also need a banner that the defaults on the screen are not the defaults for the system and so opening the menu and then pressing "OK" without modifying anything will change the configuration of the installed system.
Having it a part of the main installer flow requires a lot more discussion than this review and we are too far along with the 11 release for changes to default system behavior anyway, so is not something I would be comfortable approving at present.
Comment Actions
I think it's a bit too late to throw this stuff into 11 right at the last minute. I think it's fine to have as an off-by-default thing for 11, and then we flip them on-by-default in 12 after it branches.
Comment Actions
For the sake of getting things done and even smallest improvements having value, I've changed the defaults to "off" for all settings. Can I have approval now to raise Change Request to re@?
Comment Actions
yup! you can commit this to -head and then request re@ for stable/11 mfc.
we can flip on the defaults in -head soon.
thanks!
Comment Actions
@adrian I don't have src commit bit, mind committing that, so I could send the PR request to re@?
Comment Actions
As long as you have approval, you can commit to the src tree
Here are the instructions on how to request permission from re@
https://wiki.freebsd.org/Releng/ChangeRequestGuidelines
However, now that stable/11 is branched, the procedure is:
Commit it to head, using the 'Approval By' line
Set the 'MFC-After' to some amount reasonable amount of testing time (minimum 3 days)
Once that MFC time has passed, email re@ and request permission according to the instructions above.
When you get approval, merge it to the stable/11 branch.
Comment Actions
Committed in 302897. Thanks! Once the MFC passes, and re@ agrees to commit it (hopefully), will it get into the 11.0-RELEASE?