svn commit: r343440 - head/bin/sh

Fri Jan 25 23:56:37 UTC 2019

On 0125T1530, Devin Teske wrote:
> 
> 
> > On Jan 25, 2019, at 12:28 AM, Edward Napierala <trasz at freebsd.org> wrote:
> > 
> > On 0125T1441, Devin Teske wrote:
> >> 
> >> 
> >>> On Jan 25, 2019, at 1:37 PM, Edward Napierala <trasz at freebsd.org> wrote:
> >>> 
> >>> pt., 25 sty 2019 o 19:57 Rodney W. Grimes
> >>> <freebsd at pdx.rh.cn85.dnsmgr.net <mailto:freebsd at pdx.rh.cn85.dnsmgr.net>> napisał(a):
> >>>> 
> >>>>> Author: trasz
> >>>>> Date: Fri Jan 25 17:09:26 2019
> >>>>> New Revision: 343440
> >>>>> URL: https://svnweb.freebsd.org/changeset/base/343440
> >>>>> 
> >>>>> Log:
> >>>>> Comment out the default sh(1) aliases for root, introduced in r343416.
> >>>>> The rest of this stuff is still to be discussed, but I think at this
> >>>>> point we have the agreement that the aliases should go.
> >>>>> 
> >>>>> MFC after:  2 weeks
> >>>>> Sponsored by:       DARPA, AFRL
> >>>> 
> >>>> Please just revert this and the prior commit out, and when
> >>>> the path forward is clear commit it.  I would not want any of this
> >>>> merged to 12/ or 11/ until the time that it is all settled.
> >>> 
> >>> Oops, my bad - neither this nor the previous commit is supposed
> >>> to be MFC-ed; the "2 weeks" above comes from my default Subversion
> >>> config.
> >>> 
> >>> Regarding the backoff - just a few hours ago you said you don't have
> >>> any problem with this, except for aliases and the default ENV.  The
> >>> aliases problem has been addressed, and you hadn't yet responded
> >>> to my explanations regarding the ENV.  Another committer asked for
> >>> backoff, because "sh is not an interactive shell", while in fact sh(1)
> >>> is FreeBSD's default interactive shell except for root.  Finally, there's
> >>> one person who asked for revert, but without giving any reasons
> >>> whatsoever.
> >>> 
> >>> So far nobody had proposed any scenario where this would break
> >>> anything, or even affect existing users.  It seems like a typical bikeshed
> >>> situation.
> >> 
> >> It is not clear to me after reading r343416 and D18872 what this change is trying to solve.
> > 
> > The idea is to make it easy to replace the default root shell - which
> > many people consider broken, due to not supporting basic shell syntax - with
> > something that actually works.
> 
> How exactly does changing PS1 or adding 6 aliases fix the "basic shell syntax" which you claim to be unsupported?
> 
> If the number of aliases added to a shell are a measure of its brokenness, then bash must be hella broken (I have 43 aliases in my bash_profile).

The aliases are gone.  Human-friendly PS1 is considered a standard feature
nowadays.  But the way it fixes things is that it makes it easy to replace
csh with a shell which actually groks shell syntax and is reasonably useful
out of the box, with ~/.shrc you can customize etc.  Think of it as a POLA,
but horizontally, for folks coming from other systems, instead of the usual
one.

> Also, the perhaps anecdotal consideration of brokenness is nearly laughable -- these can largely be lumped into one of three categories:
> 
> a. Considered broken because it doesn't support bashisms
> b. Considered broken because lack of syntactical knowledge
> c. Considered broken because (no reason given)

It's broken because it doesn't accept what people call the shell syntax.
Sure, some folks do realize there used to be something called 'csh',
and people kept using it even into the nineties.  But most users aren't
actually that much into computing history; they expect the system to just
work like they expect.

> Other languages might fit that description as well, and so we should take this anecdote of "many people consider broken" with a grain of salt.
> 
> I personally have written more than 50,000 lines of shell for the FreeBSD base OS -- all utilizing /bin/sh

And that's one of the reasons why I really apprieciate your response.

> >> PS1 should have a reasonable default. If that default is not reasonable, then we should change the C code.
> >> 
> >> Maybe I see things differently, but I'd rather see PS1 default change so no profile/shrc change is necessary.
> > 
> > Thank you, that's actually a valid argument.  I believe that's also what
> > bash does.  It would be more intrusive, though, and I kind of don't like
> > the idea of hardcoding things that can easily be dealt with with in a more
> > "high-level" way.
> > 
> >> I prefer that sh, in its default configuration, not attempt to read $HOME/.shrc, for security reasons.
> > 
> > Can you elaborate?  It already reads $HOME/.profile; how is $HOME/.shrc
> > different?
> 
> If you read "The Cuckoo's Egg" by Clifford Stoll, you'll understand the importance of "one place to exploit versus two."
> 
> (situation)
> 
> Say you've been running FreeBSD for 20 years (it turned 25 years old last year, so this is not only possible, but plausible).
> You know all the areas of interest where an attacker could inject code.
> You take care to lock down each one.
> But come to your surprise ...
> 
> (hypothetical)
> 
> 6 months after you upgraded from 11.2 to the latest 12.x, you find that you didn't take into account that $HOME/.profile (which you perhaps locked down with a "chflags" command) now branches out to a new file which you've never taken steps to lock down, keep an eye on, or audit (e.g., by using DTrace remote-logging, tripwire, or other means). You only found out 6 months after the upgrade because someone exploited it. At that point, the security event has already occurred.
> 
> When I worked at "the banks" shit like this was always on our radar. Changes like this were often cited for the reason why one bank moved to BoKs for security.

The change we're discussing doesn't affect upgrades at all - it's only
for new installs.  And it only affects root, for whom the answer to
'where an attacker could inject code' question is 'literally everywhere,
including the firmware'.  And it doesn't affect root by default, you
need to change their shell from csh(1) to sh(1).

> >> Further, it is documented that the contents of ENV may be ignored in privileged mode, negating these changes.
> > 
> > True - so if someone finds the idea of having a suid shell useful - from
> > what I undestand that's what the privileged mode boils down to - this
> > change will be a no-op.  I seriously hope nobody does, though.
> > 
> 
> From the manual:
> 
>      -p privileged
>              Turn on privileged mode.  This mode is enabled on startup if
>              either the effective user or group ID is not equal to the real
>              user or group ID.  Turning this mode off sets the effective user
>              and group IDs to the real user and group IDs.  When this mode is
>              enabled for interactive shells, the file /etc/suid_profile is
>              sourced instead of ~/.profile after /etc/profile is sourced, and
>              the contents of the ENV variable are ignored.
> 
> So as you can see, it's suid *or* sgid.
> 
> I can think of plenty of places where sgid is common.

Okay.  I've never seen an sgid shell myself, but I believe you.  Still,
for that case the change we're discussing is a no-op.

> >> If you wanted your new shiny default PS1 to actually have an effect in all modes (including privileged mode, where you probably want it), you would have put it in /etc/profile and not in a file that is wholly ignored by some modes (e.g., privileged mode).
> >> So the solution is not even the right one for the desired result.
> > 
> > I would, if only it didn't break zsh, and perhaps others.  The
> > problem here is that zsh uses different syntax for PS1, _and_
> > it also parses /etc/profile.
> > 
> > And no, I don't care at all about privileged mode, I can't imagine
> > a situation when using it would be a good idea.
> > 
> 
> Rampant hand-waving.
> 
> OK, that still leaves the fact that a non-static PS1 fucks with TCL/Expect programmers.

True, that's a valid argument.  Question is, is the number of FreeBSD
systems (others already use more complicated PS1 by default) to be deployed
(the change doesn't affect existing installations) with root shell changed
to sh(1) (the change doesn't affect situations when sh(1) is not your login
shell) that have to interface with Expect scripts that can't handle more
complicated prompts, large enough to actually care?