[jester23947]

I really like this article about FreeBSD. One really nice feature that is not cover though is to set the immutable flags on some binaries with the command chflags. It's possible to boot your very secure system into securemode level 1 or higher. In this mode, it's impossible to delete those files.

rm -rf /* has very limited damage. chmod -R 0000 /* won't touch chmod and all kind of ooops become much less destructive.

It's probably not useful in all scenarios, but definitely some systems deserve to never be touch live. Automation, scada, super important core backbone systems.

FreeBSD is the power to serve. It deserves more credits.

[how2cflags]

Just wanted to say that in linux you have extended attributes on files, check the man page on chattr. I believe the -i option makes files immutable.

I picked this little trick up watching a red team discuss how they set themselves persistence on the target system by making /etc/shadow immutable this way.. Fun bit is, root can't even remove the file until the flag is removed, and you can't see the immutable flag on the file unless you know what you are looking for via lsattr.

[matthews2]

FreeBSD has the concept of a 'security level'. You can increase it at runtime, which disables more functionality, but you can't decrease it without a reboot.

At security level 1, the immutable and append only attributes on files can't be removed, so even chattr -i would be useless.

[znpy]

Linux has SELinux, which is enabled by default in RHEL and derivatives.

You could literally hand out root shell to people, and they wouldn’t be able to make much mess out of it.

There are SELinux policies to prevent disabling selinux too, of course.

You probably wouldn’t even need chattr.

[pxc]

SELinux is way more complex than security levels sounds here.

[_abox]

Securelevels are not just this. FreeBSD has its own SELinux equivalent called Mandatory Access Control:

https://docs.freebsd.org/en/books/handbook/mac/

It goes far beyond making files immutable. I haven't really done a deep dive to see if it's on par with SELinux but the description in this thread doesn't do it justice.

[pxc]

What I meant is that devising a sane and useful way to make use of security levels seems easier than achieving something 'equivalent' with SELinux. Sophisticated policy systems are nice, but something that kind of bundles sane defaults together and organizes them into ordered layers like security levels sounds great.

[kstrauser]

The whole securelevel mechanism is nice. You can only increase its value at runtime, never decrease it without rebooting. At higher levels, you can’t modify firewall rules. If you configure the server to boot into a high securelevel, you can make the machine effectively read-only until you boot it with console access.