Date: Fri, 25 Sep 2020 10:42:00 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: Warner Losh <imp@bsdimp.com> Cc: Stefan Esser <se@freebsd.org>, "Rodney W. Grimes" <rgrimes@freebsd.org>, Kyle Evans <kevans@freebsd.org>, Alan Somers <asomers@freebsd.org>, Mateusz Guzik <mjguzik@gmail.com>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r365643 - head/bin/cp Message-ID: <202009251742.08PHg0nD051549@gndrsh.dnsmgr.net> In-Reply-To: <CANCZdfpHfRK6Hm8H6%2BUcSyo-jVaTYXjpF7M1NRNqoJmQ4w5xJA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Thu, Sep 24, 2020 at 12:41 AM Stefan Esser <se@freebsd.org> wrote:
>
> > Am 23.09.20 um 19:23 schrieb Warner Losh> But for this issue, we're not
> > mounting devfs early enough. We should
> > > fix that. Removing /dev/null from the boot process likely is never going
> > > to happen because we use it all over the place to discard output...
> > > There's ~200 instances of it in the boot rc scripts, so getting rid of
> > > it there would also be quite the effort, with the same question.
> >
> > Removal of /dev/null from rc.d scripts should be quite simple,
> > since most cases could just use ">-" (close file descriptor)
> > instead. Other usage could be substituted with ":>" followed
> > by chown.
> >
>
> So closing fd1 and fd2 doesn't cause them to be available for these
> programs to get as an fd on open, causing other issues?
>
> But >- isn't documented in sh(1) as doing the close thing. On a whim I did
> the following:
> $ echo fred >-
> $ ls -last ./-
> 4 -rw-r--r-- 1 imp imp 5 Sep 24 00:50 ./-
> $ cat ./-
> fred
> $
> which suggests maybe you now have a lot of files named - instead...
>
>
> > I'd be willing to generate patches for review, if there is any
> > chance such a change might be accepted into -CURRENT.
> >
> > I could not find any use of /dev/zero,
>
>
> Yea, I'd thought we used it in libc, but I can't find any evidence of that
> with grep now that I've gone looking for it. For get that specific one :)
>
>
> > but e.g. rc.d/syscons
> > uses ${kbddev} (i.e. /dev/ttyv0) and rc.d/zvol performs swapon
> > on /dev/zvol/${name}, rc.d/random uses /dev/random and so on.
> >
>
> So those interactions should be disaled by rc variables... Or we should be
> failing the operation...
I believe there are several cases in the rc scripts of failure
to fail, and I have experinced at least one that left a firewall
wide open that I would of just rather had it fail and drop to
single user. I have repeatedly heard the argument, "but you
want it to continue so you can get into it" NO, not if that
failure leads to a security risk.
Most modern systems have out of band management so the story
of "but you cant get to the system if it stops" no longer
holds water with me.
I have worked around these locally.
>
> > But those further references to /dev nodes will in general be
> > NOPs if /dev is not available (some test for existence of the
> > node they rely on, other just fail trying to access them, but
> > without negative effect on going multi-user).
> >
>
> Yea, that's more minor, but if /dev/ isn't there, they likely should fail,
> or shouldn't proceed... But in a way that allows the rest of the rc scripts
> to continue...
This notion that "must boot at all cost" leads to security risks.
> Warner
--
Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202009251742.08PHg0nD051549>