Bug 22102
| Summary: | Local scripts get run before securelevel is elevated | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | ryanm <ryanm> | ||||||
| Component: | conf | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Only Me | ||||||||
| Priority: | Normal | ||||||||
| Version: | 4.1.1-RELEASE | ||||||||
| Hardware: | Any | ||||||||
| OS: | Any | ||||||||
| Attachments: |
|
||||||||
State Changed From-To: open->feedback 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. 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 Feedback timeout Testing whether the email delivery problems persist. Kris
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
<-=-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-=->
|
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 :-) Fix: Obviously this diff won't apply after I've cut/pasted, but the result should be obvious enough...