Re: Moving rc.d scripts to base.tgz

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Fri, Apr 15, 2011 at 09:37:25PM +0200, Michael van Elst wrote:
> On Fri, Apr 15, 2011 at 12:38:10PM -0400, Thor Lancelot Simon wrote:
> 
> > > Actually that's exactly your statement. Moving scripts out of the
> > 
> > Sure -- those are some of the words I said.
> > 
> > As I pointed out in the text you snipped, and saw little purpose to
> > pointing out a second time in my second response (since, after all,
> > what's the point, if you're just going to snip it again) interpreter
> > input for a Turing-complete programming language just falls into a whole
> > different category
> 
> ... than reading a config file that specifies a script for a
> turing-complete programming language to be run.

No, of course not!  Clearly, you cannot allow daemons which can be
configured in such way to be dynamically configured.  Anything that
lets you feed new input to that Turing-complete interpreter cannot be
allowed.

Let me try to offer a concrete example.  For reasons to do with other
people's proprietary information, I'm going to have to handwave more
of this than I'd like.

Let's say you have a system -- like many embedded NetBSD systems I've
built -- where the system runs at security level 2 (so filesystems
cannot be remounted while the system's up), and all filesystems are
mounted either "noexec nodev" or read-only.

One principal aim is to backstop other security measures in case of
either design or implementaton level failures, by attempting to ensure
that even if an attacker can alter the system's runtime configuration
in unauthorized and transient ways, it is very difficult for him to
actually compromise the system executables in order to make that
compromise survive a reboot and a configuration restore.  Pretty
garden-variety TCB stuff, really: ensure there is a trusted set of
executables you can use to bootstrap the rest of the system back to
a known good state.

The problem becomes preventing any modification to the system which
could cause filesystem contents to be modified early in the boot
process while the system is at securelevel 0.

There are daemons that are really troublesome in this context.  You
have pointed out inetd as one.  Fortunately, most systems these days
can get away without inetd, or with an unmodifiable inetd configuation.

Another is syslogd, which I'll use as an example.  How to arrange to
not need to modify the main syslogd configuration -- which can contain
syntax allowing arbitrary files to be overwritten, and executables to
be run, at boot time -- without completely eviscerating syslogd?  But
most embedded systems do need to be able to network-log.

This turns out to be pretty simple.  Just add a command line flag to
syslogd which specifies a second configuration file, read after the
first, which has an extremely restricted syntax and can only add new
network endpoints for logging.  The main syslog configuration file goes
somewhere that isn't writable, and (this particular example of) the
problem is solved.

Similar approaches can be quickly and efficiently taken with the other
daemons a particular system requires, and the other daemons usually
invoked at boot time simply removed by manipulating the setlists
when building product images.

The shell, as a general purpose command interpreter, is not so easily
beaten into submission.  You don't want to let it get run early in the
boot process unless you know *exactly* what the input will be and
know that no more can be added.

This is why I want the shell programs run at securelevel 0 during the
boot sequence moved to somewhere I can easily mount read-only, like
the other filesystems on which executables run at securelevel 0 are
mounted.  As a practical matter, it makes life easier and makes it
possible to continue to leverage the flexible NetBSD 'rc' system
rather than replacing /etc/rc with an actual executable or with a
single old-style read only shell script.  Having been down this road
many times, it's my opinion that it'd save time and make life more
convenient for people trying to do the same kind of thing I often do.
Go ahead, mock me for trying to offer the benefit of my experience with
this issue.  That's certainly your right.

Why you're so upset about this that you find it necessary or productive
to do so, however, I honestly do not know.

Thor