It is known that generated/entered passwords remain in various RAM buffers. See, e.g., http://www.usenix.org/events/sec04/tech/chow/chow.pdf Since the purpose of /etc/init.d/pwgen is to disable root login, I suggest appending usermod -L root immediately after echo root:`pwgen -s 16` | chpasswd > /dev/null 2>&1 or replacing the latter altogether (I guess appending is better, since it removes the previous hash). Note that /etc/init.d/pwgen is a part of the ebuild. Reproducible: Always Steps to Reproduce:
Please, can you explain by a full scenario, why this is "unnecessarily" not secure? I have to remind you that the script is installed only when you're supposed to build/use a livecd (aka the livecd use flag).
I'm afraid that I can't provide an exploit, if that's what you mean. :) A scenario can be something like: a remote exploit gains control of one of the users on the system, runs process that allocates memory, searches that memory for generated password, finds one generated with pwgen - local root exploit. If /etc/init.d/pwgen is installed only on livecds, then I don't see the point of random password generation at all - "usermod -L root" should be enough.
Another scenario: the livecd build is used on a hardware router. Since router is a simple device, someone figures how to predict /dev/random. pwgen uses /dev/random - instant root exploit. Frankly, except for removal of previous hash (which is meaningless on livecd), I don't see any point in randomly generating root password over locking it: * chpasswd and usermod are in the same package * chpasswd leaves a theoretical possibility of root login, usermod -L doesn't * pwgen may block on random bits generation, usermod can't block * pwgen depends on /dev/random security, usermod -L doesn't
I'm not a release engineering expert, but the main reason we used to build livecds(and still do) was/is to help people *install* gentoo. I don't know the history behind pwgen or auto-srambling of root passwords(I can only assume things), but locking the root super-user is bad, from my point of view, cause you always need root, for maintenance purposes(eg. to load a module manually), and minimal cds don't support sudo by option(and something else, but important, "newbie" users may don't know much about users/passwords/unix..). From another point of view, who would bother himself in running an exploit to gain access to a machine which just loaded a livecd image. Also, what are the so insecure services of a livecd? ssh? Anyway, maybe you have a point here, I'm not the one who will decide about this. Just my two cents.
What /etc/init.d/pwgen already does is effectively locking out root, so I don't understand your point. Also, not all livecds are born equal, and not all are used to install Gentoo.
I just did some tests. A user is unlocked automatically when you run passwd to change his password. I thought that someone should unlock root again manually, but I was wrong. Maybe it's ok to do it your way.
The purpose of the script is not to disallow root access. The purpose of the script and the way livecds use it is to disable _remote_ root access. Local root access is already allowed intentionally. So privilege escalation is out of the question because the livecd is supposed to give root access anyway and physical access amounts to just that. Remote access is what sshd provides if you happen to run it (/etc/init.d/sshd start) after booting a livecd, and scrambling the password allows you to run the sshd quite safely, while you haven't set the root password through the local console yet.
Jeroen, you are talking about one specific build of livecd. Other builds with different configurations and usage scenarios are possible. Frankly, I didn't expect this bug to cause such a controversy. How is scrambling the password better than the simple "usermod -L root"? It's completely pointless.
Because we don't want to -L `lock a user's password'. We want to scramble it for use on our own livecds. Hence the line: use livecd && newinitd "${FILESDIR}"/pwgen.rc pwgen It isn't installed in any other case and if you want to build your own livecd of ours, then you would be well advised to build your own security system. Would you now leave us alone please until you have a case to build against a real target with a real angle? Thanks!
(In reply to comment #9) > Because we don't want to -L `lock a user's password'. We want to scramble it > for use on our own livecds. Hence the line: > > use livecd && newinitd "${FILESDIR}"/pwgen.rc pwgen > > It isn't installed in any other case and if you want to build your own livecd > of ours s|of|off|
Hi Jeroen, (In reply to comment #9) > Because we don't want to -L `lock a user's password'. We want to scramble it > for use on our own livecds. I really didn't expect this to become an argument over who wants what. If using "usermod -L" instead of scrambling the password would not be suitable for the primary livecd build, I would understand, but I am not sure whether you understand what "usermod -L" does. It just changes the password hash to something impossible, which is functionally equivalent to scrambling the password. There is no some external concept of "locked password" in Unix. Your resistance to this simple improvement is a mystery to me. Perhaps it is possible to have someone more competent in the discussion? Thanks.
(In reply to comment #11) > Your resistance to this simple improvement is a mystery to me. Perhaps it is > possible to have someone more competent in the discussion? Why don't you bring it up on the gentoo-dev mailing list?
Over such a trivial thing? Truth of the matter is, the whole idea of /etc/init.d/pwgen is silly, /etc/init.d/autoconfig should just have had "usermod -L root" at the relevant place. But livecd-tools in themselves are outdated and of terrible quality, so that's not surprising. It's better to write something clean from scratch if one wants a good-quality livecd.
Before we can do anything about this package, releng would need to stop shipping it.
So to sum it up for future reference: 1. The (undocumented) dependency of app-misc/livecd-tools on app-admin/pwgen is unnecessary. 2. The livecd flag of app-admin/pwgen and the corresponding /etc/init.d/pwgen script are unnecessary. 3. /etc/init.d/autoconfig can instead have "usermod -L root" instead of "/etc/init.d/pwgen start"
From looking through a recent x86 autobuild, it would appear that /etc/shadow is shipped with a locked root password ("*") already, so usermod -L would be as superfluous as is the current pwgen init.d script. Maybe it was once significant to use pwgen, but it isn't now, it seems.
That's very strange, what if the user wants to drop into single-user mode for troubleshooting, before autoconfig kicks in with chpasswd? But if the root password is not set somewhere else, you are right - usermod or pwgen are completely redundant... livecd-tools is pretty outdated.
> Your resistance to this simple improvement is a mystery to me. Perhaps it is > possible to have someone more competent in the discussion? > As I 've written earlier above, you may have a point here, but you 're thinking, being in the easiness of the outside world. Anyone who has used and still uses our installation cds(or livecds or whatever) all these years, knows very well how they work. I don't know if the technologies we use/develop are old/outdated, but I say it again, the cds work, and from my personal point of view, they work good enough. The improvement you propose, may cause more harm (people know that root is unlocked by default, suddenly root comes locked...) than good(fixing a security issue not so important). Also, I have the suspicion that there will be also other problems if we do that change (eg. I don't know what happens if you logout from a root console and root is locked, or if you want to open another tty). Someone with more technical skills than me from releng should reply here. I'm not an expert, I say again.
I can't even...
