From owner-freebsd-security Mon Jun 18 12:49:59 2001 Delivered-To: freebsd-security@freebsd.org Received: from nsmail.corp.globalstar.com (gibraltar.globalstar.com [207.88.248.142]) by hub.freebsd.org (Postfix) with ESMTP id 005A737B401; Mon, 18 Jun 2001 12:49:55 -0700 (PDT) (envelope-from crist.clark@globalstar.com) Received: from globalstar.com ([207.88.153.184]) by nsmail.corp.globalstar.com (Netscape Messaging Server 4.15) with ESMTP id GF55QF00.7IO; Mon, 18 Jun 2001 12:49:27 -0700 Message-ID: <3B2E5B60.9405FDE3@globalstar.com> Date: Mon, 18 Jun 2001 12:49:52 -0700 From: "Crist Clark" Organization: Globalstar LP X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Brad Huntting Cc: Dima Dorfman , freebsd-gnats-submit@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: misc/28188: Cron is being started to early in /etc/rc (potential security hole) References: <200106162306.f5GN6Xx45201@hunkular.glarp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Brad Huntting wrote: > > > But you are right of course, the most secure way to go is raise > > securelevel as early as possible in the boot sequence (although > > off of the top of my head, I can't think of anything besides cron(8) > > that would run non-"trusted" code).[...] > > Sendmail (runs programs specified in .forward files), inetd (ftp, > telnet, etc) sshd (user shells), httpd (cgi-bin's).... Cron's > @reboot is just the easiest one to exploit. Right, those others would be some pretty tough races to win. But anyway, I had a look at the -STABLE rc scripts to see what is what. As for Dima's original question about the feasiblity, IMHO, it will take a lot of work to do this. Rearranging the current startup so that securelevel can be raised earlier, will _probably_ not be a huge problem. However, the for -STABLE, I would expect we would want to do _a lot_ of testing to verify rearranging something minor like the rc-scripts does not break anything before it goes prime time. That's the easy part. The harder part will be designing a new mechanism for local rc-scripts (hard as in "bikeshed alert"). It is quite feasible the local admin might have some scripts that need to run before securelevel is notched up, while most scripts do not. At present, all scripts in /usr/local/etc/rc.d, and the other local scripts, are run at once. Do we make a new directory for pre-securelevel scripts (won't break stuff, but might not appeal to many people's asthetics)? Have a naming convention in rc.d (different asthetic problems and possible back-compatibility issues)? Anyway, if we are to do this, this is how I would see partition things, Basic Startup (mounting filesystems, bringing up interfaces and network, etc.) Pre-Securelevel Daemons in Standard Startup Pre-Securelevel Daemons in Local Startup Raise Securelevel Post-Securelevel Daemons in Standard Startup Post-Securelevel Daemons in Local Startup I say "daemons" above since that is the most common thing, but it can be other code as well. One other thing that I noticed, the log_in_vain sysctl(8)s are not set until wa-ay at the end. I thought that this might be a problem since I presumed that the log_in_vain's were CTLFLAG_SECURE. However, they are not. Nor could I find any network related sysctl's that were. In fact, # cd /usr/src # fgrep -r 'CTLFLAG_SECURE' . ./sys/kern/kern_sysctl.c: ((oid->oid_kind & CTLFLAG_SECURE) && securelevel > 0))) ./sys/sys/sysctl.h:#define CTLFLAG_SECURE 0x08000000 /* Permit set only if securelevel<=0 */ # Am I not looking in the right place? I sure thought that there are some sysctl's that are locked at elevated securelevel. [Insert here the ususal disclaimer that securelevel(8) is lame and will someday be replaced by real MAC extensions to the OS so do not sweat the details of securelevel(8) too much.] -- Crist J. Clark Network Security Engineer crist.clark@globalstar.com Globalstar, L.P. (408) 933-4387 FAX: (408) 933-4926 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster@globalstar.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message