Date: Mon, 18 Jun 2001 12:50:21 -0700 (PDT) From: "Crist Clark" <crist.clark@globalstar.com> To: freebsd-bugs@FreeBSD.org Subject: Re: misc/28188: Cron is being started to early in /etc/rc (potential security hole) Message-ID: <200106181950.f5IJoLL10522@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR misc/28188; it has been noted by GNATS.
From: "Crist Clark" <crist.clark@globalstar.com>
To: Brad Huntting <huntting@glarp.com>
Cc: Dima Dorfman <dima@unixfreak.org>,
freebsd-gnats-submit@FreeBSD.ORG, security@FreeBSD.ORG
Subject: Re: misc/28188: Cron is being started to early in /etc/rc (potential
security hole)
Date: Mon, 18 Jun 2001 12:49:52 -0700
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-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106181950.f5IJoLL10522>