# Any side effects to immutable kernel and securelevel 1?



## ShelLuser (Sep 19, 2013)

Hi gang,

I'll be honest and blunt here: I did some research on my question before asking but not as thorough as I could have (meaning: glimpsing at Google and searching this forum). I'm quite agitated at the time of writing, luckily for me messing with FreeBSD and setting up a cool VPN at my hosting provider (consisting of some of my VPS's there) made somewhat up for it. I mentioned it more often but administrating FreeBSD actually and honestly gives me a dose of satisfaction.

I'm ready to "use the source". I partially rely on freebsd-update (or maybe not at all) and leave the rest up to my checked out copy of /usr/src.

When trying to update my jail I noticed an error:


```
install: rename: /usr/jails/dogma/lib/INS@3SfO to /usr/jails/dogma/lib/libc.so.7: Operation not permitted
*** [_libinstall] Error code 71
```
Obviously FreeBSD's security scheme is too good for my own doing 

It took me a while to find out, but I know what's up:


```
root@smtp2:/usr/jails/dogma/lib # ls -lo libc.so.7
-r--r--r--  1 root  wheel  [FILE]schg[/FILE] 1367760 Sep  1 20:09 /usr/jails/dogma/lib/libc.so.7
```
As you may suspect by now: my kern.securelevel sits at 1.

Now, this isn't the problem; it only requires me to think up a specific security schema for my jail, quite frankly I love surprises like these.

My question concerns this:


```
$ ls -lo /boot/kernel
total 9247
-r-xr-xr-x  1 root  wheel  - 7447049 Sep 18 23:26 kernel
-rw-r--r--  1 root  wheel  -    6652 Sep 19 04:03 linker.hints
-r-xr-xr-x  1 root  wheel  -   13768 Sep 19 04:03 opensolaris.ko
-r-xr-xr-x  1 root  wheel  - 1946120 Sep 19 04:03 zfs.ko
```
My optimized, trimmed down _and_ secured kernel, all based on the GENERIC configuration (with an extra thanks to @wblock@ for helping me look at the obvious ).

My question: Would there be any (unwanted?) nasty side-effects from setting an immutable flag on kernel and both zfs.ko and opensolaris.ko?

I can't think of any, I also can't imagine that it would (note: I obviously do not consider "not being able to update your kernel" an 'unwanted nasty side-effect' :e) but here's hoping someone of you guys can either confirm or rebut my current conclusion.

And thanks in advance for your help. As said; I did some research, but... oh well :stud


----------



## ShelLuser (Sep 19, 2013)

And so I build and used the world on one of my machines. And even though it's not that much of an accomplishment it is pretty satisfying to know that you're not only using an Open Source operating system; you also actually compiled it from the ground up.

I answered my own question: there are no ill side effects from "locking up" /boot/kernel, apart from the fact that you cannot run a `# make installkernel` or `# make reinstallkernel` when your kern.securelevel is set to 1 or higher.

Something I should have anticipated up front. After all; it's all in the handbook.


----------



## kpa (Sep 19, 2013)

Congrats  I'm not sure if locking down the kernel executable prevents an intruder who has root privileges from changing the kernel. I'm thinking that it's still possible to rename and delete files in the enclosing directory and replace the locked kernel executable with a tampered one even with securelevel set.


----------



## SirDice (Sep 23, 2013)

kpa said:
			
		

> I'm thinking that it's still possible to rename and delete files in the enclosing directory and replace the locked kernel executable with a tampered one even with securelevel set.


Maybe add uunlnk to the mix


----------

