On 02/01/2012 12:22 PM, jdow wrote:
> On 2012/02/01 09:28, Yasha Karant wrote:
>> On 02/01/2012 09:03 AM, Konstantin Olchanski wrote:
>>> On Wed, Feb 01, 2012 at 08:47:28AM -0800, Yasha Karant wrote:
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=636628
>> [snip]
>>> Anyone with physical access to the machine can walk away with your
>>> disks,
>>> or boot their own OS from a USB disk or from the network, and have
>>> root access
>>> to all files without having to get root access. So you can safely assume
>>> that for unfriendly purposes, having physical access is the same as
>>> knowing
>>> the root password.
>>>
>>
>> It is my understanding that if the BIOS on a standard IA-32 or X86-64
>> machine is
>> protected by a boot password, then there is no access to the boot
>> procedure of
>> the BIOS and thus the media you suggest cannot be booted unless these
>> are in
>> BIOS boot order preceding the physical internal hard drive.
>>
>> Am I an in error?
>>
>> Yasha Karant
>
> Only two things provide security as far as I know. The first is a FULLY
> encrypted file system. The other is not permitting other people physical
> access to the machine. "Case opened" detection can tell you if you've been
> compromised. It can't protect the disks. BIOS passwords are bypass-able in
> some cases by simply shorting the coin for a couple seconds. They can be
> worked around by simply removing the disks. If there is time they can be
> copied with dd and worked upon at leisure.
>
> At the very least keep critical files fully protected with encryption. It
> slows the machine down somewhat. But that is a worthwhile tradeoff
> methinks.
>
> {^_^}

I fully understand that physical access to a machine with tools to open 
a case and remove a hard drive allows any system to be compromised, 
although with an encrypted hard drive it is more difficult to access the 
information (depending upon the cipher and a number of other factors).

However, all I stated was that:  if the BIOS password is set and the 
boot order does not start with any form of removable media or network 
boot, but only the hard drive, then simply attempting to power cycle the 
machine to get root access (or any access) through the use of removable 
media will fail without knowledge (or cracking) of the BIOS password.

If one makes changes inside a machine (removal of the hard drive) or has 
the necessary equipment to communicate with the mother board or certain 
specialized hardware controllers once the machine is open, all bets are 
off.  Obviously, without a BIOS password, power cycling most machines 
will allow one to boot from removable media and then access (possibly 
compromise) the hard drive.

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?

Yasha Karant