Re: misc/28188: Cron is being started to early in /etc/rc (potential security hole)

From: Crist Clark (crist.clark@globalstar.com)
Date: 06/16/01


Date: Sat, 16 Jun 2001 14:34:13 -0700
From: "Crist Clark" <crist.clark@globalstar.com>
To: Dima Dorfman <dima@unixfreak.org>

Dima Dorfman wrote:
>
> Brad Huntting <huntting@glarp.com> writes:
> > >Description:
> > Cron allows users to run jobs at boot time by specifying "@reboot".
> > While this is a very usefull feature, it is also a potential security
> > hole if these jobs are started before the kern.securelevel level is
> > raised.
>
> This is a general problem; cron just makes it easy to take advantage
> of. The problem is that the securelevel is raised as late as
> possible; it is the last thing to happen in /etc/rc in -stable, and
> second to last in -current (background fsck's are started after it).
> The real solution[1] is to move the setting of securelevel up, above
> the starting of most of the non-essential daemons (e.g., sshd, cron,
> et al). Anyone from -security care to comment on the feasibility of
> this? Any reason why it isn't already done like this? OpenBSD sets
> it quite early, FWIW.

Can't comment on the history of it too much, but my guess is that
the usual assumption is that all of the steps in the startup process
are trusted (the rc-scripts), so there is no need to kick up the
securelevel until the end. I am familiar with the way OpenBSD does it.
You have to watch that you start "non-essential" daemons like NTP
before you notch up the securelevel and other little things.

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). I will have a look at the -STABLE
scripts to see what we can do in the 4.x branch. As for -CURRENT,
it would be a good idea for the people working on importing the new
NetBSD rc-scripts to keep this in mind... Of course, maybe (hope, hope)
the NetBSD people already handled this intelligently? (I'll try to
peek at that too if I can bear to update my -CURRENT source over a
dial-up.)

-- 
Crist J. Clark                                Network Security Engineer
crist.clark@globalstar.com                    Globalstar, L.P.
(408) 933-4387                                FAX: (408) 933-4926
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message