Date: Sat, 16 Jun 2001 14:40:04 -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: <200106162140.f5GLe4047081@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: Dima Dorfman <dima@unixfreak.org> Cc: Brad Huntting <huntting@glarp.com>, 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: Sat, 16 Jun 2001 14:34:13 -0700 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-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106162140.f5GLe4047081>