From nobody@FreeBSD.ORG  Wed Oct 18 19:01:31 2000
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id 1609137B4C5; Wed, 18 Oct 2000 19:01:31 -0700 (PDT)
Message-Id: <20001019020131.1609137B4C5@hub.freebsd.org>
Date: Wed, 18 Oct 2000 19:01:31 -0700 (PDT)
From: ryanm@mhpcc.edu
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@FreeBSD.org
Subject: Local scripts get run before securelevel is elevated
X-Send-Pr-Version: www-1.0

>Number:         22102
>Category:       conf
>Synopsis:       Local scripts get run before securelevel is elevated
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Wed Oct 18 19:10:01 PDT 2000
>Closed-Date:    Fri Aug 15 21:46:00 PDT 2003
>Last-Modified:  Mon Aug 18 10:50:05 PDT 2003
>Originator:     Ryan Mooney
>Release:        4.1.1-RELEASE
>Organization:
MHPCC
>Environment:
FreeBSD xxxx.xxx.edu 4.1.1-RELEASE FreeBSD 4.1.1-RELEASE #1: Wed Oct 18 10:47:43 HST 2000     ryanm@mhpcc.edu:/usr/src/sys/compile/mykernel  i386

>Description:
While hardening some systems I was examining the flow of control through
/etc/rc in regards to how that might potentially compromise my useage of
chflags schg on various system binaries/config files.  I have made 
/etc/rc* and /etc/*conf immutable as well as various system binaries 
(/bin, /sbin, etc.).  The problem arose in that the scripts in 
${local_startup} are run before the securelevel is increased.  Unless 
all of those directories (and files therein) are also immutable this 
opens a window of opportunity in that a clever hacker could use those 
initialization scripts to undo the immutable flags on my other files, 
modify them and I would be no wiser.  I started examining the potential
of making all the ${local_startup} directories/files immutable, but 
it quickly became evident that that would be somewhat of a slippery 
slope to travel down.

Moving the ${network_pass3_done} and ${kern_securelevel_enable} code
above the  ${local_startup} doesn't seem to have (?any?) side affects
and solves this problem quite nicely.  There may be a better solution
and if so I'd love to hear it :-)

>How-To-Repeat:

>Fix:

Obviously this diff won't apply after I've cut/pasted, but the 
result should be obvious enough...

*** rc.orig     Wed Oct 18 15:45:06 2000
--- rc  Wed Oct 18 15:45:17 2000
***************
*** 564,569 ****
--- 564,585 ----
        echo '.'
  fi
  
+ if [ -n "${network_pass3_done}" ]; then
+       network_pass4
+ fi
+ 
+ # Raise kernel security level.  This should be done only after `fsck' has
+ # repaired local file systems if you want the securelevel to be greater than 1

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: johan 
State-Changed-When: Thu Aug 22 18:33:19 PDT 2002 
State-Changed-Why:  
It seems like the patch did not make it 
compleatly into the PR. 

Can you please send the patch again. 

Please followup by sending a mail to  
freebsd-gnats-submit@FreeBSD.org 
with the subject of this mail intact. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=22102 

From: Johan Karlsson <johan@freebsd.org>
To: Bug followup <bug-followup@freebsd.org>
Cc:  
Subject: Re: conf/22102: Local scripts get run before securelevel is elevated
Date: Fri, 23 Aug 2002 15:55:58 +0200

 Attach to audit-trail. Ask for feedback in a few weeks
 and see if this mail server has been fix (or submitter 
 has sent a followup with a new mail address). If not
 close this PR.
 
 ----- Forwarded message from Mail Delivery Subsystem <MAILER-DAEMON@mhpcc.edu> -----
 
 From: Mail Delivery Subsystem <MAILER-DAEMON@mhpcc.edu>
 To: postmaster@littleb.mhpcc.edu
 To: <johan@FreeBSD.org>
 Subject: Returned mail: Local configuration error
 Date: Thu, 22 Aug 2002 15:32:37 -1000
 
 The original message was received at Thu, 22 Aug 2002 15:32:36 -1000
 from mx2.FreeBSD.org [216.136.204.119]
 
    ----- The following addresses had permanent fatal errors -----
 <ryanm@mhpcc.edu>
 
   --- The transcript of the session follows ---
 554 MX list for mhpcc.edu. points back to littleb.mhpcc.edu
 554 <ryanm@mhpcc.edu>... Local configuration error
 
 Reporting-MTA: dns; littleb.mhpcc.edu
 Received-From-MTA: DNS; mx2.FreeBSD.org
 Arrival-Date: Thu, 22 Aug 2002 15:32:36 -1000
 
 ----- End forwarded message -----
 
 -- 
 Johan Karlsson		mailto:johan@FreeBSD.org
State-Changed-From-To: feedback->closed 
State-Changed-By: kris 
State-Changed-When: Fri Aug 15 21:45:51 PDT 2003 
State-Changed-Why:  
Feedback timeout 

http://www.freebsd.org/cgi/query-pr.cgi?pr=22102 

From: Kris Kennaway <kris@obsecurity.org>
To: freebsd-gnats-submit@FreeBSD.org, ryanm@mhpcc.edu
Cc:  
Subject: Re: conf/22102
Date: Fri, 15 Aug 2003 22:42:23 -0700

 Testing whether the email delivery problems persist.
 
 Kris

From: Ryan Mooney <ryan@pcslink.com>
To: Kris Kennaway <kris@obsecurity.org>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: conf/22102
Date: Mon, 18 Aug 2003 06:55:11 -1000

 --45Z9DzgjV8m4Oswq
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 
 Kris,
 
 I no longer have access to the systems that I was working on this on,
 so this may not be 100% as accurate as I'd like :)
 
 Basically the idea is that all the dirs in ${local_startup} are running 
 mostly 3rd party vendor scripts - which are by nature less trusted.  
 Since in /etc/rc the securelevel is not set until AFTER they run, if
 they "do something bad" (hack apache startup, whatever) they could do 
 things to my system bypassing immutable files, etc... This COULD be
 partially solved by making all the vendor stuff immutable to, but
 when I started doing that, it ended up getting really ugly and I
 had to hit all the libraries, etc etc... as well.  
 
 A simpler solution that elevated the security somewhat without any
 noticable side effects (in most cases unless someones rc.* script 
 depended on an nfs client or a kerberos server running) was to simply
 move the local_startup code after net3 and securelevel.
 I don't know if anyone else is paranoid enough to care about this..
 
 > Testing whether the email delivery problems persist.
 > 
 > Kris
 
 -- 
 >-=-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-=-<
 Ryan Mooney          				 ryan@pcslink.com 
 <-=-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-=-> 
 
 --45Z9DzgjV8m4Oswq
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename=diffs
 
 *** rc	Mon Aug 18 06:37:32 2003
 --- rc.old	Mon Aug 18 06:37:13 2003
 ***************
 *** 685,712 ****
   	echo '.'
   fi
   
 - if [ -n "${network_pass3_done}" ]; then
 - 	network_pass4
 - fi
 - 
 - # Late pass to set variables we missed the first time
 - #
 - if [ -r /etc/rc.sysctl ]; then
 - 	sh /etc/rc.sysctl last
 - fi
 - 
 - # Raise kernel security level.  This should be done only after `fsck' has
 - # repaired local file systems if you want the securelevel to be greater than 1.
 - #
 - case ${kern_securelevel_enable} in
 - [Yy][Ee][Ss])
 - 	if [ "${kern_securelevel}" -ge 0 ]; then
 - 		echo 'Raising kernel security level: '
 - 		sysctl kern.securelevel=${kern_securelevel}
 - 	fi
 - 	;;
 - esac
 - 
   # For each valid dir in $local_startup, search for init scripts matching *.sh
   #
   case ${local_startup} in
 --- 685,690 ----
 ***************
 *** 738,743 ****
 --- 716,743 ----
   	done
   	IFS="${script_save_sep}"
   	echo '.'
 + 	;;
 + esac
 + 
 + if [ -n "${network_pass3_done}" ]; then
 + 	network_pass4
 + fi
 + 
 + # Late pass to set variables we missed the first time
 + #
 + if [ -r /etc/rc.sysctl ]; then
 + 	sh /etc/rc.sysctl last
 + fi
 + 
 + # Raise kernel security level.  This should be done only after `fsck' has
 + # repaired local file systems if you want the securelevel to be greater than 1.
 + #
 + case ${kern_securelevel_enable} in
 + [Yy][Ee][Ss])
 + 	if [ "${kern_securelevel}" -ge 0 ]; then
 + 		echo 'Raising kernel security level: '
 + 		sysctl kern.securelevel=${kern_securelevel}
 + 	fi
   	;;
   esac
   
 
 --45Z9DzgjV8m4Oswq--
>Unformatted:
