Solved secure level 3 + kernel module loading

Hello, Maybe this might be a vague question: Is it possible to load kernel modules, when in secure level 3 modus?
After reading the FreeBSD Handbook, this question still remains.

Usually to load the Intel Wireless Drivers + PF, i set in /etc/rc.conf
Code:
if_iwmload="YES"
iwm3160fw_load="YES"
wlan_ccmp_load="YES"
wlan_tkip_load="YES"
pf_enable="YES"

But after setting secure level 3 in /etc/sysctl.conf, and reading dmesg after booting the system: kldload can't load the kernel if_iwm, and also can't load PF: operation not permitted.
That actually should be expected behavior, after setting secure level3.

But in the FreeBSD Handbook, it states, that secure level 3 is in some way false sense of security, because, kernel modules can still be loading at boot time, before the secure level mechanism kicks in.
So i thought, o.k, i will enable secure level 3, and just load the Intel Wireless Module + PF at boot time, by adding the modules to: /boot/loader.conf.

So what happens, is that indeed, now the if_iwm and PF, get's started even before secure level 3 starts, however it seems that if_iwm can not read the firmware, to load the wireless module, because: the if_iwm module is loaded, before the root file system is active.. and that is where i got stuck right now.. and to be honest, after reading on the www about secure level 3, i see often that people call secure level 3 a administrative nightmare.

I have no idea if that it true, however my question remains: Is it possible to load kernel modules, when in secure level 3?
 
If you really need (or want to try) secure level 3 I'd go for custom kernel - build those modules with fw into kernel (see iwm(4)).

You are able to load modules when booting (loader does that), you can't do that after secure level kicks in. I'm assuming (haven't read the src to confirm) iwm module that loads fw requires to modify itself or part of the kernel which you can't do because you are already in secure level. It's the chicken/egg problem. Hence my advise.
 
Is it possible to load kernel modules, when in secure level 3 modus?
No. Level 1 already doesn't allow it.

Code:
     1     Secure mode - the system immutable and system append-only flags may
           not be turned off; disks for mounted file systems, /dev/mem and
           /dev/kmem may not be opened for writing; /dev/io (if your platform
           has it) may not be opened at all; kernel modules (see kld(4)) may
           not be loaded or unloaded.  The kernel debugger may not be entered
           using the debug.kdb.enter sysctl.  A panic or trap cannot be forced
           using the debug.kdb.panic and other sysctl's.
Levels 2 and 3 build on top of that. See security(7).
 
Thanks for the idea _martin, i'm building custom kernel with iwm + pf right now, i will report if it works with secure level 3.
 
Right now i am secure level3, and Intel Wireless (iwm) works ok.
Only pf output on boot is:
Code:
Enabling pfpfctl: DIOCOSFPFLUSH: Operation not permitted
pfctl: DIOCSTART: Operation not permitted
And pf is not enabled, any idea how to make pf work? I will read the manual now..

*edit*
Code:
# pfctl -e
pfctl: DIOCSTART: Operation not permitted

from the pf(4) manpage:

Code:
IOCTL INTERFACE
     pf    supports the following ioctl(2)    commands, available through
     <net/pfvar.h>:

     DIOCSTART
         Start the packet filter.

     DIOCSTOP
         Stop the packet filter.

So right now i have no clue on how to make # pfctl -e work..

*edit*
From the securelevel in FreeBSD Handbook:
Code:
 3     Network secure mode - same as highly secure mode, plus IP packet
           filter rules (see ipfw(8), ipfirewall(4) and pfctl(8)) cannot be
           changed and dummynet(4) or pf(4) configuration cannot be adjusted.
So that # pfctl -e or # pfctl -d, can not work with operation not permitted, is actually expected behavior.

However i wonder what the correct method is for enabling the PF.. (and can not be disabled or enabled after secure level 3 is set)
 
/boot/loader.conf
Code:
pf_load="YES"
pf_enable="YES"
But on boot pf is not started.
And i think /etc/rc.conf:
Code:
pf_enable="YES"
Will not work, because loading pf trough rc.conf will be after secure level 3 is set, and thus, the pfctl cannot be changed.

So right now i'm trying to find a way to enable PF, before secure level 3 starts. Any ideas?

*edit* pf works in secure level 2, so i might stay in level 2, however if someone knows how to enable PF in secure level 3, please tell me..
 
/etc/rc.d/securelevel:
Bash:
# PROVIDE: securelevel

# REQUIRE: adjkerntz ipfw ipfilter pf
If you enable both ipfw/ipfilter/pf and securelevel via rc.conf, the securelevel should not kick in until the firewall is up.
If you want to be able to disable/enable pf then you don't want network secure mode.
 
Roald: same as with the WiFi driver, build PF into the kernel:

Code:
# PF
device          pf
device          pflog
device          pfsync
options         ALTQ
options         ALTQ_CBQ        # Class Bases Queuing (CBQ)
options         ALTQ_RED        # Random Early Detection (RED)
options         ALTQ_RIO        # RED In/Out
options         ALTQ_HFSC       # Hierarchical Packet Scheduler (HFSC)
options         ALTQ_PRIQ       # Priority Queuing (PRIQ)
options         ALTQ_NOPCC      # Required for SMP build

You don't necessarily need queues but this way you have all in when needed. Then as others mentioned - once loaded you can't change it.
 
Thanks, PF now works in secure level 3.
The mistake i made was by enabling secure level in loader.conf, but like bds, said, i now enable secure level trough:
/etc/rc.conf
Code:
kern_securelevel_enable="YES"
kern_securelevel="3"

Before i mark thread solved, there is one last module i would like to enable while in secure level 3:
I installed xf86-video-intel + drm-kmod, and usually to use drm-kmod i have to put in /etc/rc.conf:
Code:
kld_list="/boot/modules/i915kms.ko"

Any idea how to use the drm-kmod in secure level 3?

*edit* nevermind..
/etc/rc.conf:
Code:
kld_list="/boot/modules/i915kms.ko"
works fine, Thread Solved, Thanks, _martin and bds
 
I unmarked the thread as solved, because there is one last question:
Secure level 3 is designed for servers, and not for Desktop system using X, correct?
When secure level 3 is enabled, i can't start Xorg (with secure level -1 Xorg starts ok)
So i now boot in secure level -1, then $ startx, and then switch to another TTY and: # /sbin/sysctl kern.securelevel=3

That way i can have secure level 3 + have X, but is not that convenient.
So just to make sure; Question: is there a method of enabling secure level 3 on boot and then start X?
 
Secure level 3 is designed for servers, and not for Desktop system using X, correct?
You can use it wherever you want, be it a server or a desktop. Re-read what SirDice told you: each securelevel is built on previous ones. Particularly speaking of X: it should not start because since securelevel 1 the system prevents access to /dev/io; but IIRC, X does not need it on start anymore (and if it still needs access to /dev/io, just install a display manager that will start before securelevels kick in).

What securelevel 3 does is just preventing you (even as root, of course) from changing your firewall configuration. So the 3rd securelevel is a "nightmare" only if you misconfigured your firewall, or if you need to change its settings for whatever reason.
 
Particularly speaking of X: it should not start because since securelevel 1 the system prevents access to /dev/io; but IIRC, X does not need it on start anymore (and if it still needs access to /dev/io, just install a display manager that will start before securelevels kick in).
So when booting with in rc.conf:
slim_enable="YES"
kern_securelevel_enable="YES"
kern_securelevel="3"

On boot, first slim get's started, then secure level get's raised -1 -> 3
But i stay at the tty1 login promt, and slim does not start.

So honestly i have no idea if booting with secure lvl 3 and automatically starting X is even possible, at least i don't know how.
At this moment, i just boot with secure level -1, then login, start X, then raise the secure level -1 -> 3.
 
Let me ask a basic question: What are you trying to accomplish? Why are you trying to set securelevel? What threat are you worried about? Can you explain how setting securelevel will actually accomplish defending your system against those threats?

This whole thread has the taste of an "XY question": We're here helping you doing a specific task, but without knowing what your goals are.
 
ralphbsz I was wondering basically the same thing. Maybe it's a slightly different direction, as I believe I know the motivation: "make my system secure" :) So, not exactly an "XY problem". But it looks a lot like throwing some "security feature" in without taking the time to even think about the actual threat, very much as you say, which reminds me of a good decade ago when windows users installed "zone alarm", because, hey, it's a firewall, so this makes the system more secure ...

I chose not to touch securelevel even on my dedicated firewall (virtual) machine. Simple reason: I want to reconfigure my ruleset without rebooting, and, as I don't run any network services besides ssh on that machine, and no regular user has access to it, I see the risk of someone becoming root there as small enough not to worry about :)
 
I know this is a late reaction but...
If you really need (or want to try) secure level 3 I'd go for custom kernel - build those modules with fw into kernel (see iwm(4)).
Not a great idea IMO, there's no need for this. And it's kinda pointless too (from a security point of view) if you don't follow up and set (for example) MODULES_OVERRIDE in /etc/make.conf.

But as I said: this only unnecessary complicates stuff. Just put the modules you need to load in /boot/loader.conf and you're done. Works with the kernel secure mode enabled.

The other reason why I think this is a bad idea is because... what's going to happen when some hardware fails and you need another driver... which so happens to clash (not very likely but... can you rule it out?) with a module you embedded?

Just keep things set in /etc/loader.conf, then you'd only need to edit the file to load the appropriate module(s) and you're done.
 
But as I said: this only unnecessary complicates stuff. Just put the modules you need to load in /boot/loader.conf and you're done. Works with the kernel secure mode enabled.
Original OP's question was about firmware not being loaded properly even though they are specified in /boot/loader.conf. Hence my suggestion.
 
ralphbsz,
Let me ask a basic question: What are you trying to accomplish? Why are you trying to set securelevel? What threat are you worried about? Can you explain how setting securelevel will actually accomplish defending your system against those threats?
I'm trying to learn how to harden FreeBSD. So after reading the FreeBSD handbook, i thought that raising the securelevel will harden the system. I'm not worried about any threat in general, just learning how to harden the system.
 
OK. Good starting point. So let's think it through. Securelevel prevents certain actions (list is in the man page), and some of those actions can indeed be used by attackers. But all the actions that it prevents can only be taken by root. So securelevel only starts helping once you have an unauthorized and unwelome actor who has already become root on your machine (and that includes setuid, doesn't require a login process). But if you have an unauthorized root on your machine, you have already lost the war completely. Are you seriously worried that they could change the packet filter configuration? Given that at that point, they can find out what your passwords are, can look at all your documents (like the most recent bank statement), can send and receive mail on your behalf, and can empty out your bank account? In the modern world of IoT, they could probably even kill your cat (a friend of mine has a computer-controlled cat feeder, although in reality he would clearly notice if his cat is hungry, and the cat could probably survive by going outside and finding mice and gophers).

As an educational exercise, playing with securelevel is fine. As a way to actually harden the system it is a waste of time; other things are much more important.
 
Back
Top