we should set a grub password by default
Sven
sven.lug-dorsten at gmx.de
Tue May 15 19:56:03 UTC 2007
Am Dienstag, den 15.05.2007, 18:52 +0100 schrieb Scott James Remnant:
> On Tue, 2007-05-15 at 19:23 +0200, Sven wrote:
>
> > With the actual Ubuntu default settings anyone can easily gather
> > root-privileges by rebooting and pressing e to enter edit mode in grub
> > and add a init=/bin/bash kernel option.
> >
> Since the cracker was able to use the GRUB menu, they have physical
> access to the machine. This means that they can pop open the case, take
> the hard drive out, and mount it in another machine -- gaining root
> access to the files on that disk.
Modifying hardware is very different quality of impact than just
pressing 2 keys to gain root access.
> Frankly, they can pick the machine up and walk off with it; subjecting
> it to any manner of abuse until they break into it.
Say i setup a pc in the childrens room, do i want my children to gain
root access without a password?
Say i setup 10 pcs in the public library, i dont think they want to
steal those old heavy computers, but do i want anyone to gain root
access without any problem?
Compare it to windows, you can not gain root access during reboot,
without a medium.
> Where physical "console access" security is a requirement, all the tools
> to try and improve that are made available; as you note, GRUB has the
> facility to password its boot menu, and one would assumedly select
> computers that had difficult to penetrate cases and BIOS passwords, etc.
Your answer is, "the tools you need are there". My answer is, they are
to difficult to use for most of your users.
Matt bishops principles of secure programming includes beeing kind to
your users, otherwise they will not use your security features.
I am asking to include a wizard style installation feature to enable the
feature in KISS principle for users.
> However as a default configuration, this would likely cause more
> problems than it would solve. Since users would now need *another*
> password to:
>
> * dual boot
I do not see dual boot problems, i do not see usability problems. The
grub password feature does not ask for a password to boot usual menu
entries. You do not stuck users every day work.
It only asks for the password if you want to modify boot parameters, use
the grub shell or start menu entries with the lock command.
> * enter recovery mode
We have to make clear from what point the system is responsibility for
the security
1. Does security start from the moment the kernel is startet?
2. Does security start from the moment the boot-loader is startet?
If you say one is your choice, okay implement grub without a password,
implement recovery mode without a password. This mean no security at all
if one can switch on the computer. Not stealing the pc is the barrier,
booting is the barrier.
My opinion is, from the moment the CPU's instruction pointer runs into
ubuntu's code you need to protect the system. That means from the
boot-loader up.
People would need a boot medium and BIOS access to reset totally lost
passwords. Is this that bad? Is it different with Windows?
You might say a grub password is useless if people do not further
protect the system from booting external mediums or even protect
physical access. You are right but BIOS boot protection and physical
access simply is not your job. But you can tell users about it during
the grub password setup wizard.
> * help debug problems
The only difference is a password and a different scenario when it is
lost.
My vision would be a additional page in the ubuntu installer named
security level.
The user can choose from several security features:
[ ] password protect the boot-manager grub
[ ] encrypt home partitions
[ ] encrypt root and swap partitions
Sven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20070515/e47a079d/attachment.sig>
More information about the Ubuntu-devel-discuss
mailing list