I've read about securelevel in the mailing list archive, and found some pitfalls (and seems to me to be discarded soon). But According to me, the following configuration should offer a good security: - mount root fs read only at boot; - set securelevel to 3; - do not permit to unmount/remount roots fs read-write (now it is possible by means of "mount -uw /"); - the only way to make change at the file system is to reboot in single user, before the securelevel is set to 3, and make the changes needed (this means the administrator should use only the console); Any comments about? Bye, Roberto
Hi Did you look at securelevel manual # man securelevel regards On Wed, Feb 11, 2004 at 10:29:46AM +0100, roberto@redix.it wrote:> > I've read about securelevel in the mailing list archive, and found some > pitfalls (and seems to me to be discarded soon). > > But According to me, the following configuration should offer a good > security: > > - mount root fs read only at boot; > - set securelevel to 3; > - do not permit to unmount/remount roots fs read-write (now it is possible > by means of "mount -uw /"); > - the only way to make change at the file system is to reboot in single > user, before the securelevel is set to 3, and make the changes needed > (this means the administrator should use only the console); > > Any comments about? > > Bye, > Roberto > > > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"-- Ismail YENIGUL http://www.acikkod.com - Acikkod Yayinlari http://www.EnderUNIX.org GnuPG Key: http://yenigul.net/ismail.gpg It takes longer to lose 'x' number of pounds than to gain 'x' number of pounds.
> Hi > Did you look at securelevel manual > # man securelevel > regardsYes, I did. But I do not understand what you means: could you explain? regards Roberto
I want to discuss securelevel and whether it's a good or bad thing. Now, I do not need help to get it working (but never say never ...). I'll try to explain my idea. Suppose I'm trying to setup a packet-filtering firewall based on FreeBSD, and I want to harden it (I heard about TrustedBSD, but here I want to speach about securelevel). I made the assumption that the console (of my BSD) is in a safe place, so I can exclude any hack from it. It should be the only place where the administrator can access the O.S. with securelevel disabled (i.e.=0, by means of a single user mode). In normal condition, O.S. is running on securelevel=3 so nobody can: - kernel module connot be loaded or unloaded; - packet filtering rules connot be altered; - /dev/mem and kmem cannot be write; - immutable and sys flags cannot be turned off; In addition (this is my idea), suppose to configured the root filesystem read-only and there is no way to change this (remount it rw) when securelevel is == 3. Could this configuration be considered secure, according to you? There are any weakness of securelevel still present? Any comments are welcome... Regards, Roberto
> > you do not need to go single user to change it. just remove the > securelevel lines from /etc/rc.conf and reboot. > > greetings, > tilo >As said, the root filesystem is read-only and the command "mount -uw /" should be in disabled when securelevel==3, in my ideal kernel. Actually the command "mount -uw /" will succeded when the securelevel==3, but supposing should be not so difficult to change the FreeBSD kernel, this (securelevel+readonly filesystem) could address the weakness of securelevel+non-read-only filesystem. Regards Roberto
> > Change the "console" line in /etc/ttys from "secure" to "insecure", that > will make your administrator enter the root password when booting to > single user. > > When using securelevel, you might also want to use a script to set the > immutable flag on various parts of the file system. > > There's also much more to securing a box than just using securelevel. >1- OK I've already set console to insecure, I do not like the single user mode offer a shell without password. 2- But instead of set the immutable flags over several files, seems to me more simple (and not error prone) to set the root file system read-only (simple to do) and to find a way it could not be remounted rw while securelevel == 3! 3- OK agree with you: there's also much more to securing a box than just using securelevel, but using a securelevel+readonly file system, is a step foreward in security? Regards Roberto