Re: installing kernel with securelevel set to 2

I think I answered my own question. The kernel isn't installed with  
immutable flags to begin with -- So, my question is, why is this? I  
thought the advantage of making the kernel immutable was to better  
protect the system if root was compromised? I searched the archives  
regarding this, but found nothing that related to it.

-rory

> From: Rory Arms <rorya_at_TrueStep.com>
> Date: Sun Jun 1, 2003  17:07:53 US/Eastern
> To: freebsd-current_at_freebsd.org
> Subject: installing kernel with securelevel set to 2
> X-Mailer: Apple Mail (2.552)
>
> FreeBSD-current_at_
>
> I just tried installing a kernel after compiling May 31st source and  
> figured I would have to reboot to a lower securelevel, as I'm running  
> with kern.securelevel set to 2. However, it slipped my mind and i've  
> noticed it installed anyhow. Has this behavior changed? I thought that  
> the kernel file (/boot/kernel/kernel) and its modules could not be  
> replaced at that securelevel? Note: I'm currently running an April 6th  
> -CURRENT. Also, all filesystems are UFS1, currently.
>
> As you can see, it installed kernel just fine for some reason. In the  
> past, if the machine was running in secure mode it would stop at this  
> point:
>
> [...]
> cd /usr/obj/usr/src/sys/TSERVER;  MAKEOBJDIRPREFIX=/usr/obj   
> MACHINE_ARCH=i386  MACHINE=i386  CPUTYPE=i686   
> GROFF_BIN_PATH=/usr/obj/usr/src/i386/legacy/usr/bin   
> GROFF_FONT_PATH=/usr/obj/usr/src/i386/legacy/usr/share/groff_font   
> GROFF_TMAC_PATH=/usr/obj/usr/src/i386/legacy/usr/share/tmac  
> PATH=/usr/obj/usr/src/i386/legacy/usr/sbin:/usr/obj/usr/src/i386/ 
> legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games:/usr/obj/usr/ 
> src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/ 
> usr/games:/sbin:/bin:/usr/sbin:/usr/bin  make KERNEL=kernel install
> thiskernel=`sysctl -n kern.bootfile` ;  if [ "$thiskernel" =  
> /boot/kernel.old/kernel ] ; then  chflags -R noschg /boot/kernel ;  rm  
> -rf /boot/kernel ;  else  if [ -d /boot/kernel.old ] ; then  chflags  
> -R noschg /boot/kernel.old ;  rm -rf /boot/kernel.old ;  fi ;  mv  
> /boot/kernel /boot/kernel.old ;  if [ "$thiskernel" =  
> /boot/kernel/kernel ] ; then  sysctl  
> kern.bootfile=/boot/kernel.old/kernel ;  fi;  fi
> kern.bootfile: /boot/kernel/kernel -> /boot/kernel.old/kernel
> mkdir -p /boot/kernel
> install -p -m 555 -o root -g wheel kernel /boot/kernel
> cd /usr/src/sys/modules;  
> MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/TSERVER/modules  
> KMODDIR=/boot/kernel MACHINE=i386 make  install
> [...]
>
> Looks like it was able to remove the immutable flag w/o a problem,  
> which isn't supposed to be allowed at securelevel 1 or 2.
>
> From securelevel(8):
>
>      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; kernel modules (see
>            kld(4)) may not be loaded or unloaded.
>
>      2     Highly secure mode - same as secure mode, plus disks may  
> not be
>            opened for writing (except by mount(2)) whether mounted or  
> not.
>            This level precludes tampering with file systems by  
> unmounting
>            them, but also inhibits running newfs(8) while the system  
> is multi-
>            user.
>
> Here's how I checked the securelevel:
> # sysctl kern.securelevel
> kern.securelevel: 2
> #
>
> Also, checking the flags on "/boot/kernel/kernel" after the "make -j2  
> kernelinstall" there appears to be no flags set on the kernel file or  
> any of its modules:
>
> # ls -lo /boot/kernel/kernel
> -r-xr-xr-x  1 root  wheel  - 3553557 Jun  1 16:24 /boot/kernel/kernel
> #
>
> Odd, no? Is there a new sysctl(8) directive that I'm missing? Maybe  
> its a bug that's been fixed since Apr. 6th.
>
> Thanks,
>
> -rory
>
>