Inclusion of an item in the wishlist does not mean it will happen, merely that it was suggested during brain-storming on the freebsd-security mailing list. A more extensive discussion of securelevels can be found here and here.
Isolate the config files and binaries that occur in low securelevels and require that they can only be changed in that securelevel. (i.e., a seperate rc.0, rc.1 for each securelevel? Would this also apply to binaries required at each level?)
At a sufficiently high securelevel, disallow remounting, mounting, and umounting. All change the security policy implemented on the machine. For example, read-only partitions remounted read-write is allowed at high securelevels currently. Similarly, if restricted mounting is allowed (from entries in fstab), enforce nosuid and nodev (etc) on the file systems? Protect fstab from changes at higher securelevels? (see above)
schg is set on a number of system binaries, including the kernel, in the current make installworld and buildworld. These settings are insufficient to produce any higher degree of security in most cases, and should be reconsidered.
There is debate over the usefulness of restricting read access to various files in the system, including the kernel. Some argue that read-access for this type of file should be need-to-know only. Others argue that this is an attempt at security through obscurity, and does not represent a useful security policy. However, the unnecessary leakage of system information occurs in many places, and should be reviewed (and possibly stopped at a sufficiently high security policy level).
Using secure-levels, read- and append-only flags can be enforced even on uid 0 behavior. One possible policy for improving security would be to apply this to all binary and library directories on the system. Depending on ones choice, this would prevent changes in higher securelevels from compromising lower securelevel-behavior, and also prevent the installation of trojans on a compromised system.
IPsec is clearly desirable. However, this seems more like a decision that must be made with the main FreeBSD distribution, and not a hardening issue (other than possibly to restrict further the abilities of local users under the chosen system).
Install a restrictive packet-filtering system, and through a configuration system, allow the specific enabling of other services. Through the use of securelevels, prevent changes to this policy using ipfw or the config files. This will require adding securelevel checking to the configuration interface for ipfw in the kernel. This would also be used to restrict outgoing connections, limiting the ability of an attacker to use the system to attack other systems, either remotely or local to that machine. For example, if a firewall system was compromised, it could be prevented from making arbitrary connections to the protected network.
Existing syscalls will be auditted to discover whether they should also be limited in a highly secure environment.
/proc will be auditted to determine if the information is "need-to-know". At higher securelevels, the data in proc might be restricted (at the highest level, this might include limiting listing access to /proc, and allowing users to only access information on their own processes). (Similar auditing should occur for sysctl, kernfs)
At installation of the hardening patch (and at arbitrary other times while in a sufficiently low securelevel), require the specific enabling of any network services offered to the world. This would remove a number of default daemons from inetd.conf, for example. Similarly, enabling these services via our configuration system would also add permission to the ipfw configuration, and warn the user if this requires more access to the machine than might be advisable.
Some system directories need to be writable during a particular FreeBSD run, but the data written is largely for the sake of that run (pid files, status files, locks, etc). Rather than allowing this information to persist across runs, use of an MFS file system would allow a reduction in the writable partitions on the system. Also, careful auditing of writable system areas would be performed (/usr/tmp, etc).
Use of the append-only flag to prevent changes to system logs would greatly improve the security of the system. If a root-compromise could not affect logging information prior to the compromise, this would be of enourmous advantage.
Verify that all existing setuid programs need to be setuid (or setgid). Provide an easy interface to allow the system administrator to determine whether they use these programs, and disable them easily (for example, UUCP).
Suggested options that could be applied to each suid category:
For each sgid category:
Many log files and accounting files have lax permissions that may result in the leaking of security information about the system (incorrect passwords, etc). Also, the default configuration does not use the highest possible level of auditing.