On Sat, Feb 4, 2012 at 2:22 AM, Yasha Karant <[log in to unmask]> wrote:
> On 02/03/2012 02:43 PM, Tom H wrote:
>> On Wed, Feb 1, 2012 at 9:04 PM, jdow<[log in to unmask]>  wrote:
>>> On 2012/02/01 15:38, Tom H wrote:
>>>> On Wed, Feb 1, 2012 at 6:05 PM, Nico Kadel-Garcia<[log in to unmask]>
>>>>  wrote:
>>>>> On Wed, Feb 1, 2012 at 5:36 PM, Yasha Karant<[log in to unmask]>
>>>>>  wrote:
>>>>>
>>>>>> Back to my primary point:  the bug in accepting the root password upon
>>>>>> a
>>>>>> failed fsck during boot is from TUV and documented (please see a
>>>>>> previous
>>>>>> post nominally in this thread).  Is there any fix?  I do not care if
>>>>>> the
>>>>>> fix
>>>>>> "breaks" TUV bug-for-bug compatibility -- is there a fix to which
>>>>>> routine(s)
>>>>>> are causing the problem?
>>>>>
>>>>>
>>>>>
>>>>> This is, in fact, an option to configure in grub in the older LILO
>>>>> boot loader. Run the command "info grub-md5-crypt" for more
>>>>> information.
>>>>>
>>>>> This is not normally considered a "bug". The software is not doing
>>>>> anything that is not expected or undocumented. It's a *risk*, and some
>>>>> folks might think it's a security flaw. But the burden of storing and
>>>>> managing  separate password for deployed systems is not, hirsorically,
>>>>> taken up by default. It would have to be written into the OS instaler
>>>>> to apply on the existing boot loader software. So it's not set by
>>>>> default.
>>>>
>>>>
>>>>
>>>> It's not a bug; it's a TUV decision. Requiring the root password for
>>>> single user mode can be set through "/etc/sysconfig/init".
>>>>
>>>> As Nico's shown, you can also set a grub password to prevent anyone
>>>> from adding "init=/bin/sh"/"init=/bin/bash" to the "kernel" line
>>>> without that password.
>>>
>>>
>>> It is a bug, IIRC. The original complaint is that it claims it is ready
>>> to accept the root password and something prevents it by causing the
>>> login prompt to recycle with each character typed. That has been declared
>>> a TUV bug. I think somebody mentioned there might be a fix for it that
>>> has
>>> not percolated through yet. It'd be worth checking TUV's bugzilla.
>>
>>
>> I've just re-read the whole thread. You're right; it started out about
>> a bug entering the root password in single-user mode after filesystem
>> corruption.
>>
>> A solution was pointed to
>>
>>
>> http://listserv.fnal.gov/scripts/wa.exe?A2=ind1202&L=scientific-linux-users&T=0&P=243
>>
>> but Yasha somehow decided that it would turn off the password prompt
>> for single-user mode when all it does is turn off plymouth and allow
>> someone in his situation (according to the Fedora bug) to enter the
>> root password.
>
>
> Please excuse my obvious misunderstanding, but the URL that was mentioned
> and that you repeat contains the statement:
>
> With rd_NO_PLYMOUTH I don't get a prompt for the password for the root
> filesystem encryption, but that's a minor matter relative to the problem
> itself.
>
> End quote.
>
> Not having a prompt for the password is what is stated.  Thus, I assumed
> that under a call to fsck during boot with an abnormal exit from fsck, the
> default behavior of rd_NO_PLYMOUTH would be to allow root access without a
> password during boot.  Admittedly, a boot root password under these
> circumstances is little protection to a determined attacker who has physical
> access -- but it will deter the casual hacker.  By analogy, it is rather
> like a deadbolt lock on a wood frame and wood door without metal armor, a
> reinforced wall and door frame:  a determined attacker simply kicks in the
> door, but a casual thief finding the door locked and unwilling to break a
> window leaves.
>
> I have not done the experiment as if it fails, I do not want to have to go
> through the rescue DVD approach again unless I must.  Has anyone done the
> experiment with SL 6x and verified that rd_NO_PLYMOUTH allows for a
> successful request of a legitimate root password?

Yes. And in the same bug, someone else reports:

"I ran into this today with F14. I always remove 'rhgb quiet' from grub, and I
tried rebooting adding 's' to get to single user mode. I was shocked to find
that I was still getting the password prompt in single-user mode!"

So having a corrupt filesystem, "SINGLE=/sbin/sulogin" in
"/etc/sysconfig/init", and "rd_NO_PLYMOUTH" (and no "quiet" or "rhgb")
on the grub kernel line, _MIGHT_ allow password-less access to a
system (if this is your case, you should report it to RH as a bug!).