# Setting kern.securelevel in rc.conf doesn't work?



## ShelLuser (Jul 26, 2013)

Hi gang,

Still on FreeBSD-9.1-RELEASE-p4.

The search for more security continues and this time I focussed my attention on the kernel security level (see part 15.3.5).

You can set this security level by using either sysctl or by adding a command to /etc/rc.conf, which I did:


```
# Security settings; kernel control & system accounting
kern_securelevel_enable = "YES"
kern_securelevel = "1"
#accounting_enable = "YES"
```
But the moment I had these two lines included I started to see oddities whenever checking my Apache configuration:


```
root@chihiro:/home/peter # apachectl configtest
/etc/rc.conf: kern_securelevel_enable: not found
/etc/rc.conf: kern_securelevel: not found
/etc/rc.conf: kern_securelevel_enable: not found
/etc/rc.conf: kern_securelevel: not found
Performing sanity check on apache22 configuration:
Syntax OK
```
I traced this back to the /usr/sbin/service script which is also used by apachectl (which in its turn is another script):


```
root@chihiro:/home/peter # service apache22 status
/etc/rc.conf: kern_securelevel_enable: not found
/etc/rc.conf: kern_securelevel: not found
/etc/rc.conf: kern_securelevel_enable: not found
/etc/rc.conf: kern_securelevel: not found
apache22 is running as pid 1227.
```
At first I suspected this to be somewhat of a bug in the service script because if the script would detect an error I'd expected completely different output:


```
$ tail -6 `which service`
done

# If the script was not found
echo "$script does not exist in /etc/rc.d or the local startup"
echo "directories (${local_startup})"
exit 1
```
However, I just discovered that there's much more to this than I anticipated. Although the documentation claims that the lines I added to rc.conf are correct it turns out that they're not.

After rebooting my Chihiro server to confirm my suspicions I got several errors regarding these lines during boot, and after the boot process the kernel security level remained at -1:


```
$ dmesg -a | grep secure
/etc/rc.conf: kern_securelevel_enable: not found
/etc/rc.conf: kern_securelevel: not found
/etc/rc.conf: kern_securelevel_enable: not found
/etc/rc.conf: kern_securelevel: not found
/etc/rc.conf: kern_securelevel_enable: not found
/etc/rc.conf: kern_securelevel: not found
```

My question: where is this going wrong?

My first assumption is obviously the documentation, but surely you should be able to set this up during boot as well? So right now my guess is that the author of that article could be assuming that people use a customized kernel whereas I'm not.

Yet that doesn't make too much sense either since changing the kernel security level should be something supported by the standard kernel as well (at least that's what I came to expect).

Does anyone have a clue as to what is going on here?


----------



## kpa (Jul 26, 2013)

Don't use spaces around the = signs  The /etc/rc.conf file is just a /bin/sh script and the syntax requirements for the assignments are the same as with shell variables.


----------



## ShelLuser (Jul 26, 2013)

I can't believe I missed that, but then again; with the current heat we're experiencing I guess I can.

Thanks a bunch! Problem solved.


----------



## IPTRACE (Jul 26, 2017)

I'm back with the similar issue.
	
	



```
kern_securelevel_enable="YES"
kern_securelevel="0"
```
Previously I've set "1" but changed to "0". After reboot still "1" is set.
Where is the problem?


----------



## tobik@ (Jul 26, 2017)

IPTRACE said:


> I'm back with the similar issue.
> 
> 
> 
> ...


See /etc/defaults/rc.conf

```
kern_securelevel_enable="NO"    # kernel security level (see security(7)) 
kern_securelevel="-1"   # range: -1..3 ; `-1' is the most insecure
                        # Note that setting securelevel to 0 will result
                        # in the system booting with securelevel set to 1, as
                        # init(8) will raise the level when rc(8) completes.
```
 and init(8)


> If the system security level (see security(7)) is initially nonzero, then
> init leaves it unchanged.  Otherwise, init raises the level to 1 before
> going multi-user for the first time.  Since the level cannot be reduced,
> it will be at least 1 for subsequent operation, even on return to single-
> ...



So kern.securelevel=-1 (i.e. permanently insecure mode) and kern.securelevel=0 (i.e. insecure mode) are basically equivalent except that init(8) will raise kern.securelevel before going multi-user when it's 0 and leave it alone when it's -1.


----------



## IPTRACE (Jul 26, 2017)

Thanks, I've set to "NO". I thought "YES" changes to my level set in rc.conf at every boot.


----------

