Excuse my brevity; I'll address the rest after getting some sleep, but I'd like to clarify one crucial thing. I think that's actually _the_ point where I screwed up: I didn't expect people to actually care for what I considered a cosmetic change, and I didn't realize the need to explain what this commit does _not_ affect.
(And I've been reminded by rgrimes@ more than once that I should pay more attention to my commit messages. Oh well. Perhaps I'll learn this time.) On 0125T1647, Devin Teske wrote: > > > > On Jan 25, 2019, at 1:13 AM, Edward Napierala <tr...@freebsd.org> wrote: [..] > >>>> 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. > > mergemaster, iirc, will merge in changes to etc files after an upgrade. > So this would effect anybody that goes through an upgrade and performs > mergemaster. No, it won't - it doesn't affect files in /etc at all. It doesn't affect stuff that's being installed by mergemaster(8), nor stuff installed by 'make install'. It only affects the default /root/.profile and /root/.shrc, as installed by bsdinstall(8) or shipped as VM or SD card images. [..] > > And it doesn't affect root by default, you > > need to change their shell from csh(1) to sh(1). > > By your own commit messages admission, this is for the toor account, so it > does affect a user (and as you were keen to point out, users with the default > shell). Yes, but it only affects the toor account for new installs, and the account is locked by default. _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
