https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294167
--- Comment #1 from B.S. <[email protected]> --- In particular, bsdinstall currently sets (if enabled): - in /boot/loader.conf security.bsd.allow_destructive_dtrace=0 - in /etc/rc.conf clear_tmp_enable="YES" syslogd_flags="-ss" - in /etc/sysctl.conf security.bsd.see_other_uids=0 security.bsd.see_other_gids=0 security.bsd.see_jail_proc=0 security.bsd.unprivileged_read_msgbuf=0 security.bsd.unprivileged_proc_debug=0 kern.randompid=1 - in /etc/ttys, the following diff < console none unknown off secure --- > console none unknown off insecure (These can be deduced from performing `# bsdinstall hardening` then selecting all options: somewhat contrary to my previous post, you get a bunch of .hardening files in the root directory which show the effect of enabling the measures: `% ls / | grep hardening`) There's obviously a balance to be had in how much to detail, but consider: - how to set the knob - what the knob does - what kind of attack it protects against (and how effectively?) - any disadvantages or ways to shoot oneself in the foot - anything else that must be done for the measure to be effective against an attack? E.g. marking your console as insecure means not being able to just drop into single-user mode to reset a forgotten root password, but it's still possible to use installation media instead. So if the purpose is to prevent an attacker with physical access performing this as an attack, the measure is ineffective without taking further steps, like restricting boot devices in BIOS/UEFI (and making sure that's password-protected too). I'm not sure the current coverage of the knobs in the installation chapter gets the balance right, judging from the number of confused posts about it in forums: the technical details can be intimidating to new users (especially for an installation chapter so one of the first to be read - non-technical users will have little idea what it means to randomize the PIDs of processes or disable the kernel message buffer) yet there's not enough to go on to help them decide. No guidance is given on what use cases (e.g. server vs vs home laptop) the different measures are most suitable for, whether any are such important, basic measures that it's a no-brainer for almost anyone to select, or whether they are experts-only (like the technobabble might suggest). https://github.com/freebsd/freebsd-doc/blob/main/documentation/content/en/books/handbook/bsdinstall/_index.adoc#85-enabling-hardening-security-options This is partly a consequence of the way FreeBSD presents technical choices to users they may not be equipped to evaluate. Given that the Security chapter is later in the Handbook and the expertise of readers is likely greater, the appropriate balance could be different to the Installation chapter. But the chapter as a whole would benefit from making clearer what use cases the different sections apply to, and who can skip them - do home users have to worry about Kerberos or Access Control Lists for example? Yet other advice on the page is relevant even to "casual" users, like the security advisories section (at the end of the page, so readers who reach it must have really persevered!). Directing users to appropriate parts of the page for their usage would be helpful in general for getting these important messages across. Perhaps consider reordering so most "important" or "universal" measures appear earlier? (Though the introduction and guide to securing accounts rightly go at the top.) Aside from the bsdinstall options, there may be other knobs worth covering in the Handbook that are documented in security(7) and mitigations(7). At least those man pages deserve being brought to the reader's attention. https://man.freebsd.org/cgi/man.cgi?query=security&manpath=FreeBSD+16.0-CURRENT&format=html#KNOBS_AND_TWEAKS man.freebsd.org/cgi/man.cgi?query=mitigations&manpath=FreeBSD+16.0-CURRENT&format=html Obviously system hardening is not all about tweaking knobs. The Security chapter currently only mentions "encryption" in the context of passwords and networking. It should surely at least mention and link to the sections on #disks-encrypting and #swap-encrypting in the Disks chapter ("Storage", Chapter 20). https://github.com/freebsd/freebsd-doc/blob/main/documentation/content/en/books/handbook/disks/_index.adoc I'm sure the list is endless, but two other common pieces of security/hardening advice that don't seem to be mentioned in the Security chapter are to remove unused software and disable unused systems and services. For packages this doesn't need an essay, just mention that removing unused software can help protect e.g. against supply chain attacks, then link to relevant section (#pkg-delete, #pkgng-autoremove and perhaps #ports-removing) of the Ports chapter ("Installing Applications: Packages and Ports", Chapter 4): https://github.com/freebsd/freebsd-doc/blob/main/documentation/content/en/books/handbook/ports/_index.adoc Relatedly, surely #pkgng-upgrading and #pkgng-auditing should be mentioned and linked to in the Security chapter? Some hardening standards for government departments and suchlike necessitate disabling e.g. bluetooth, webcams, microphones, media drives, USB ports and other data ports, at least when not in use. This may require physically removing ports and drives, obscuring webcam with a privacy cover when not on a call, etc - the Security chapter does briefly mention the importance of physical security so it may not be out of place to at least mention these measures. But the focus should be on the software/OS level. Frustratingly the Handbook's section on bluetooth seems to show how to turn it on but not how to disable it (the closest is "To start and stop the Bluetooth stack, use its startup script" but doesn't show how to do so): https://github.com/freebsd/freebsd-doc/blob/main/documentation/content/en/books/handbook/advanced-networking/_index.adoc#network-bluetooth Similarly for webcams: https://github.com/freebsd/freebsd-doc/blob/main/documentation/content/en/books/handbook/multimedia/_index.adoc#webcam-setup And I can't find any coverage for microphones at all (will raise a fresh PR for this). -- You are receiving this mail because: You are the assignee for the bug.
