No, it's not insecure.
Standard UNIX security model permits root user and processes running under root account to do anything. While it's very convenient for somebody that knows how to operate his system, it also imposes some security issues. It's not only that someone can do a system-wide damage or theft if your root account gets compromised, he can also hide his tracks pretty easily, wipe logs, install stealth kernel rootkits that will hide his malicious software running on system, you get the point.
Still, by same UNIX philosophy, you shouldn't really "disable" any functionalities of root account. Follow the standard security procedures, don't do normal work under root account, never run internet software (irc clients, web browsers) under root account, don't run daemons under root account, keep your password strong and watch logs if you have listening daemons open to the internet. Configure your system firewall, or any other firewall between that machine and internet. There's plenty of material around regarding securing standard services (sshd, ftp, apache...). If you absolutely need to run daemons or internet programs under root account, jail them.
Increased kern.securelevel represents higher security for the sake of certain functionality. The higher it goes, it will be tougher to do some tasks on the system. For instance, I'll assign immutable flags to both log files and logging software. Then I'll raise securelevel to 1 by adding appropriate entry in
rc.conf and reboot. After the system boots, root cannot delete log files and he cannot plant a false logging software, because they're system immutable. And he can't tear down the flags because the securelevel is raised to 1. However, he can stop the running log process. There are also ways around that if securelevel is in place. But :
- if you want to upgrade that logging software, or clear old logs, you'll need to reboot, enter single user mode and disable raised securelevel in
rc.conf.
- userland processes can't access
/dev/mem,
/dev/kmem, or
/dev/io. A lot of software depends on that functionality, X11 for example. There are workarounds, but those are workarounds.
- you can't load kernel modules. Desktop usage suffers.
If securelevel is raised to 2, include stuff in 1, plus you can't write directly to disk descriptors. You can still mount drives and do normal I/O on mounts, but you can't go low-level on them. Securelevel 3 includes disabled run-time tweaking of firewall configuration.
FreeBSD is really secure as-is. Keep in mind that security of the system is often limited by administrator's capability and knowledge. Securelevels, IMHO, should only be used in paranoid security environments on server machines that will be configured and left alone to work. I've yet to hear about securelevel usage inside production environments.
I strongly suggest you read
security(7)().
