On Sat, Aug 8, 2015 at 1:28 PM, Mick <michaelkintz...@gmail.com> wrote:
> On Saturday 08 Aug 2015 18:02:00 Neil Bothwick wrote: > > On Sat, 8 Aug 2015 16:00:29 +0000 (UTC), Grant Edwards wrote: > > > Yep, I find it infuriating that by default all distros seem to go to > > > great effort to hide as much information about the boot/startup > > > process as possible. WTF? Do they think that stuff is top secret or > > > something? Are they afraid they'll lose their jobs if that info gets > > > out? > > > > No, they think that the type of user they are trying to attract is likely > > to be scared off by all that cryptic text scrolling by. They are probably > > right. > > > > Gentoo doesn't hide it, it merely clears the screen once the boot has > > completed successfully. If the boot halts, you can see where and, > > usually, why it stopped. Try that with openUbundora. > > > Also on a server console you may not want anyone walking by to see what > services you're running, what your IP address is, what NFS it's connecting > to, > etc. > > Of course, for a home PC with a single user these concerns do not apply. > -- > Regards, > Mick > There's no viable security benefit from not having it visible. On a server console, there shouldn't be anyone with physical access to the display, the rack it's mounted in, and for that matter, the data center itself, that can't be trusted with being aware of a general sense of what a given server runs. If someone can stand and read your server console without garnering any notice, they can plug a USB in, reboot to it, and have half your files before you figure out why your web server stopped answering. For that matter, all they *have* to do is plug that in, reboot to it, and have it built to load *their* kernel and *your* user space, with patched kernel that slowly siphons off data at a rate you don't notice, from within the kernel. If you don't trust the people who have physical access to your systems, you cannot trust your systems, period. Yes, there are ways to prevent even that attack, but the most viable one is a locked door, requiring more authentication than a simple mechanical lock, between them and the system. If it's shared hosting, lock your rack when you're not in front of it, padlock the server case itself closed (and buy a server that has a proper, functional, user-space watchable chassis intrusion switch), run uefi/secureboot with only your key white-listed, lock down booting to only your privately signed kernel, and for the sake of paranoia... turn off your monitor when you're not in front of it. Hiding warnings and errors from yourself during boot that might tip you off to a real security issue does more to cause risk than mitigate it. Since shared hosting means the network itself (unless you have a completely captive network within your, locked, rack) is uncontrolled, details like what services you're running and what NFS shares you're connecting to are as good as public knowledge anyhow. As for when/where/why it was introduced, it showed up in agetty in the util-linux github in May 2011 [1], and included in the release of agetty 2.20 or so, and there's a mention of it in a mailing list [2], to which the reasoning is given as: "I've backported this from our mingetty due to several bug reports from data protection officers of our customers." - Dr. Werner Fink | 2 Sep 12:43 2011 So it was prompted by a perceived security issue, but I would happily sit down with any of the DPOs involved in that to hear just how that little bandaid fixes any of the real security issues involved ;) [1] https://github.com/karelzak/util-linux/commit/e85281a8ac887a35a78f4b43e4755a44aecc2fb7 [2] http://comments.gmane.org/gmane.linux.utilities.util-linux-ng/4685 -- Joshua M. Murphy
