Mel Flynn mel.flynn+fbsd.questions at
Mon Jun 22 01:39:31 UTC 2009

On Sunday 21 June 2009 12:30:26 Tim Judd wrote:
> On 6/21/09, Lowell Gilbert <freebsd-questions-local at> wrote:
> > Tim Judd <tajudd at> writes:
> >> Something dawned on me.  FreeBSD/Open/Net are all well secured
> >> systems.  On an Internet-facing router, would applying a higher
> >> kern.securelevel provide any better, tighter, higher security if the
> >> machine was broken into?  Given you need to lower the securelevel
> >> before multiuser, it is a reasonable to think raising the securelevel
> >> will give higher comfort feeling?
> >
> > I can't understand your last sentence.
> Let me try to rephrase it.
> When securelevel is raised, to lower it to accomplish a task such as
> installworld or something, you have to comment/lower the level in the
> rc.conf and reboot in order to reach the lower level.

Actually, securelevel is often used to prevent editing of /etc files during 
service time, as mounts cannot be set to write once marked read-only. So one 
would first have to reboot, go into single user mode and then do installworld.
The reason to prevent access to /etc is to prevent exploits on next reboot, by 
starting a service or modifying the path to a service.
You would have to see how much you change files in /etc and whether the 
application in question can be configured without editing, like for pf using 
tables and anchors. That's one aspect of what Lowell Gilbert means with 
"getting in the way of operations you need".

> I dunno, this is a new idea I had on internet-facing routers (not
> necessarily for secured servers or anything).  Just trying to get the
> public's feel of who might be using it, why they're using it, and if
> they feel safer using it.

For pf there's an additional advantage for const tables: they cannot be 
modified at all, if securelevel is 2. I use such a table for the private 
networks that cannot enter $ext_if.
Overall, securelevel should be seen as reinforced doors inside the house: they 
slow down or prevent more disaster, once a thief is already inside.

More information about the freebsd-questions mailing list