recovery from stupid error

Martin Meredith martin at sourceguru.net
Thu Jul 14 19:24:20 CDT 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Well said Judd, if you think about security you can't think about
security simply on the SOFTWARE side of things, if you want proper
security, you need physical security too. Anyone can miniroot a comp
given physical access, it's the same as having a safe, telling someone
what's inside it, not concealing it and telling them if they decide not
to drill it, they can just turn the handle.

If you want the recovery option to not be there, simply remove it, just
edit /boot/grub/menu.lst . But, that won't neccessarily stop them,
unless you of course set a password for grub ... but - that can still be
bypassed depending on your BIOS settings.

Simple thing  is, putting something in a cabinet and restricting
physical access is a lot simpler than trying to restrict access via
software, and makes it impractical for someone to fix a system if thy
say, for example, forget the root password.

Regards,
Martin Meredith

Judd Pickell wrote:
> Brett,
>
> It is apparent in the responses above, that they get what you mean,
> but you seem to be missing their point. I will attempt to show you by
> presenting your own arguments:
>
> 1) A person (other than valid user) sits down at the computer and
> enters recovery mode.
> 2) A person stumbles into a server room (other than a valid admin),
> sits down at the computer and enters recovery mode.
>
> First, we need to throw out the second example. I don't know of many
> server rooms (atleast for operations bigger than a a few users) where
> you have a machine with direct monitor and keyboard access to make
> this possible. If you know how to operate the KVM setup you might get
> to it, but if your servers are automatically that accessible, you are
> just begging for someone to break your servers. (Not to mention that
> your servers would need to be rebooted to access Grub to get to
> recovery, which if they can do that from a KVM or direct access to the
> server hardware, you are screwed).
>
> But the first case makes sense, you wouldn't want someone to sit down
> at your computer reboot it, and access root. However, you fail to miss
> the most obvious point of your whole scenario. IF someone has managed
> to get that much access without your knowledge, and their intents were
> so malicious as to seek out to access root without your knowledge, a
> password on the root access will not protect you.
>
> Anyone who can sit down at a computer has all or most of these options
> available to them:
> 1) they can set a boot password at bios, preventing you access period
> to your computer.
> 2) They can insert a LiveCD (ie Knoppix) and access your entire drive
> at their leisure, and without a root password.
> 3) They can enter a win98 floppy and reformat your HD for the hell of
> it. No password needed.
> 4) If your boot options allow it (which generally these days they do)
> they can throw in an install cd, reinstall Linux/windows/etc and lock
> you out of your system. Again without needing root access.
> 5) They just grab the box, run, and you never see your computer again.
>
> Options 1,3 and 5 completely prevent them from accessing your data,
> and would put you in a very bad spot. Options 2 and 4 would provide
> them access to your data without your knowledge and didn't require
> root access, and worse they could lock you out of your own system.
>
> So to put it bluntly, root only protects you while your machine is
> already in its operational phase, and only prevents you from doing too
> much harm via a connection to the machine (even X is just a connection
> to the machine at it's techinical level).
>
> I hope I have put into reality the false-reality you have about
> accessing root. Anytime you allow someone else physical access to your
> machine, you are just asking for root to be busted. If you really want
> to prevent users from doing what has been described above is to not
> give them access to the machine at all (yeah, like we ever have that
> kind of option) or set them up with Dumb terminals that use all the
> resources on a central server.
>
> If you really don't want people messing with your system in a way that
> you do  not want, please make sure you lock in a sturdy vault before
> you leave the room. Otherwise, learn how to minimize the damage by
> decentralizing where you keep information you deem important or
> secret.
>
> Sincerely,
> Judd Pickell
>
> On 7/14/05, Brett Profitt <brett at narnarnar.com> wrote:
>
>>You are quite mistaken.  I am not making a point to favor security
>>through obscurity at all, nor do I think that practice should be
>>encouraged.  I again remind you of the correlation between physical
>>locks and security measures.  There is a general opinion, unless I am in
>>the minority, that blatantly advertising full access is in no way secure.
>>
>>Once again, the point, which I obviously have failed to make clean, is
>>that this is an insecure default setting.  Ubuntu, being a "newbie
>>friendly" installation, should take this into consideration, as many new
>>users will not have the experience to know to change such a setting.
>>
>>Brett
>>
>>Jay R. Wren wrote:
>>
>>>On 7/14/05, Brett Profitt <brett at narnarnar.com> wrote:
>>>
>>>
>>>>But how many people KNOW that as opposed to the number of people who
>>>>might see "Recovery" and think "hrm...I wonder..."
>>>>
>>>
>>>
>>>Your point is now in favor of security through obscurity.  I didn't
>>>think this was a generally accepted security practice.
>>>
>>>You can always reconfigure ubuntu to your liking post install.
>>>--
>>>Jay
>>>
>>
>>
>>--
>>ubuntu-devel mailing list
>>ubuntu-devel at lists.ubuntu.com
>>http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>>
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC1wI0JATtOmqqpWkRAjZCAJ97DSUKoLvZP6YcWFqxbxOGXGqtuQCgnn62
QmG3RYcSoFxeXIwgdBHWANw=
=2hov
-----END PGP SIGNATURE-----



More information about the ubuntu-devel mailing list