Date: Fri, 25 Jan 2019 15:30:15 -0800 From: Devin Teske <dteske@FreeBSD.org> To: Edward Napierala <trasz@freebsd.org> Cc: Devin Teske <dteske@FreeBSD.org>, rgrimes@freebsd.org, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r343440 - head/bin/sh Message-ID: <1F038D39-8869-4220-A274-F6307A4264E2@FreeBSD.org> In-Reply-To: <20190125082851.GA26199@v2> References: <201901251709.x0PH9Rc4094379@repo.freebsd.org> <201901251957.x0PJvdTL089917@pdx.rh.CN85.dnsmgr.net> <CAFLM3-oSafSxcWSJPEXQ8szLEq5N593fr=sEsup6A2%2BP_VXrgQ@mail.gmail.com> <D7EEA6BA-EAA6-4A84-A7C4-904999B0E581@FreeBSD.org> <20190125082851.GA26199@v2>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Jan 25, 2019, at 12:28 AM, Edward Napierala <trasz@freebsd.org> = wrote: >=20 > On 0125T1441, Devin Teske wrote: >>=20 >>=20 >>> On Jan 25, 2019, at 1:37 PM, Edward Napierala <trasz@freebsd.org> = wrote: >>>=20 >>> pt., 25 sty 2019 o 19:57 Rodney W. Grimes >>> <freebsd@pdx.rh.cn85.dnsmgr.net = <mailto:freebsd@pdx.rh.cn85.dnsmgr.net>> napisa=C5=82(a): >>>>=20 >>>>> Author: trasz >>>>> Date: Fri Jan 25 17:09:26 2019 >>>>> New Revision: 343440 >>>>> URL: https://svnweb.freebsd.org/changeset/base/343440 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> MFC after: 2 weeks >>>>> Sponsored by: DARPA, AFRL >>>>=20 >>>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> So far nobody had proposed any scenario where this would break >>> anything, or even affect existing users. It seems like a typical = bikeshed >>> situation. >>=20 >> It is not clear to me after reading r343416 and D18872 what this = change is trying to solve. >=20 > 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). 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) 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 >=20 >> PS1 should have a reasonable default. If that default is not = reasonable, then we should change the C code. >>=20 >> Maybe I see things differently, but I'd rather see PS1 default change = so no profile/shrc change is necessary. >=20 > 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. >=20 >> I prefer that sh, in its default configuration, not attempt to read = $HOME/.shrc, for security reasons. >=20 > 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. >=20 >> Further, it is documented that the contents of ENV may be ignored in = privileged mode, negating these changes. >=20 > 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. >=20 =46rom 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. >> 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. >=20 > 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. >=20 > 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. >=20 Rampant hand-waving. OK, that still leaves the fact that a non-static PS1 fucks with = TCL/Expect programmers. --=20 Devin=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1F038D39-8869-4220-A274-F6307A4264E2>