Dear All,
I just frightened the life out of myself by selecting this option from my grub menu:
title Gentoo Linux (rescue) root (hd0,4) kernel /boot/bzImage-2.6.28-tuxonice-r10 root=/dev/sda5 real_root=/dev/sda5 init=/bin/bb
and finding it dropped me straight to a shell with root privileges, with no need to enter a password. Since the machine sometimes gets left unattended in areas other people have access to, I'd really like this not to be a possibility. But I would still like the possibility of a minimal-services, non-GUI boot. Any ideas, please?
Hi,
2009/9/7 Dan Hatton vi5u0-alug@yahoo.co.uk:
Dear All,
I just frightened the life out of myself by selecting this option from my grub menu:
title Gentoo Linux (rescue) root (hd0,4) kernel /boot/bzImage-2.6.28-tuxonice-r10 root=/dev/sda5 real_root=/dev/sda5 init=/bin/bb
bb? :-O as in the funky aalib demo from 2001 (ish)?
That's an old kernel - I expected better from a Gentoo user ;) Do you not emerge --sync often?
and finding it dropped me straight to a shell with root privileges, with no need to enter a password. Since the machine sometimes gets
Yes... what did you expect? ;)
left unattended in areas other people have access to, I'd really like this not to be a possibility. But I would still like the possibility
Take out the option - comment it out?
of a minimal-services, non-GUI boot. Any ideas, please?
Erm. Setup the correct services to run on some other run-level other than default? I don't know enough about Gentoo's runlevel system, but the handbook states you add services to the default runlevel by:
rc-update add service_name default
So I'd look at the rc-update docs to figure out what other runlevels you can use there directly. Then setup your grub to run into your special runlevel if you select one of the options.
You *want* to read this (change appropriately for your architecture): http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=2&chap=4#d...
(I should start using Gentoo - some of the features are darn neat)
Srdjan
Hi,
2009/9/8 Steve Fosdick lists@pelvoux.nildram.co.uk:
On Mon, 2009-09-07 at 23:56 +0100, Srdjan Todorovic wrote:
bb? :-O as in the funky aalib demo from 2001 (ish)?
Presumably busybox, the shell with many of the usual commands built in?
lrwxrwxrwx 1 root root 7 Aug 22 14:10 /bin/bb -> busybox
I stand corrected. :)
Srdjan
Many thanks, Srdjan, Steve, and Wayne.
On Mon, 7 Sep 2009, Srdjan Todorovic wrote:
That's an old kernel - I expected better from a Gentoo user ;) Do you not emerge --sync often?
I do my updates with emerge --update --newuse --deep world. I was starting to suspect that this omitted the kernel.
it dropped me straight to a shell with root privileges, with no need to enter a password.
Yes... what did you expect? ;)
Same (or very similar) shell, but with the usual username/password prompt to get into it.
Take out the option - comment it out?
Already done - hopefully temporarily, until I make the necessary changes to the option. But presumably I also need to do something to stop anyone getting to a menu entry editor or grub command line - although actually I think I've now sussed out how to do this, with a password entry in the header of the grub configuration, from the grub manpage.
of a minimal-services, non-GUI boot. Any ideas, please?
Erm. Setup the correct services to run on some other run-level other than default? I don't know enough about Gentoo's runlevel system, but the handbook states you add services to the default runlevel by: rc-update add service_name default
Had already got that far... persuading grub to choose a runlevel other than default was my trouble.
You *want* to read this (change appropriately for your architecture): http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=2&chap=4#d...
Thanks, that (particularly section 5.4) helped a lot.
On Mon, 7 Sep 2009, Srdjan Todorovic wrote:
2009/9/7 Dan Hatton vi5u0-alug@yahoo.co.uk:
/boot/bzImage-2.6.28-tuxonice-r10
That's an old kernel - I expected better from a Gentoo user ;) Do you not emerge --sync often?
On further investigation, it turns out this is still the current stable version: http://packages.gentoo.org/package/sys-kernel/tuxonice-sources.
Or was the "better" you expected using a testing version?
Hi,
On 09/09/2009, Dan Hatton vi5u0-alug@yahoo.co.uk wrote:
On Mon, 7 Sep 2009, Srdjan Todorovic wrote:
2009/9/7 Dan Hatton vi5u0-alug@yahoo.co.uk:
/boot/bzImage-2.6.28-tuxonice-r10
That's an old kernel - I expected better from a Gentoo user ;) Do you not emerge --sync often?
On further investigation, it turns out this is still the current stable version: http://packages.gentoo.org/package/sys-kernel/tuxonice-sources.
Or was the "better" you expected using a testing version?
I was joking :) And also was referring to sys-kernel/gentoo-sources
Glad you got the problem sorted though. I really should try to use Gentoo more often - it seems very powerful and neat.
Srdjan
In my experience once someone with malicious intent has physical access to the hardware regardless of platform or OS all bets are off regarding security.
However you can password protect grub entries in a way that would require it before loading that specific entry by adding a new line after the title line for each entry you want to protect.
password yourpasswordhere
Or a better way is to hash your password by entering the grub shell and then issuing the md5crypt command and following the interactive prompts to generate a hash and then adding that as above but with the hash in place of the plain password preceded with the -md5 flag
so
password -md5 generated password hash
I'd recommend the latter method so that your grub passwords aren't discovered if someone views menu.lst
As well as on the boot line for single user mode you need to add the same string in the first section of the grub config to prevent people entering the grub interactive shell and modifying the default entry to give them single user mode etc.
As usual all disclaimers apply when editing your bootloader config, read the manpages first !
This still doesn't prevent the machine being booted from removable media unless you also lock down the bios and/or the boot disk could still be mounted on a different machine and the grub config edited to remove/change the passwords but it is a step in the right direction.
On Tue, Sep 08, 2009 at 01:13:02AM +0100, Wayne Stallwood wrote:
In my experience once someone with malicious intent has physical access to the hardware regardless of platform or OS all bets are off regarding security.
Exactly what I was going to say. Apart from anything else they can walk away with the machine under their arm! :-)
Even without taking the machine away it's pretty trivial to boot from a CD (or memory stick, or floppy even) that they've brought with them and get to single user/root.
If the *data* is really confidential then lock the machine up and encrypt the filesystem.
On Tue, 15 Sep 2009, Chris G wrote:
Exactly what I was going to say. Apart from anything else they can walk away with the machine under their arm! :-)
Yes - although that would at least be readily detactable.
Even without taking the machine away it's pretty trivial to boot from a CD (or memory stick, or floppy even) that they've brought with them and get to single user/root.
Not entirely trivial - I have the boot order password-protected in the BIOS. The sunk cost I'd put into achieving that is partly why it came as such a shock to find grub behaving like this.
If the *data* is really confidential then lock the machine up and encrypt the filesystem.
One of the many things I have to be thankful for in my life is that I don't have to handle "really" confidential data.
On Tue, Sep 15, 2009 at 11:37:17AM +0100, Dan Hatton wrote:
On Tue, 15 Sep 2009, Chris G wrote:
Exactly what I was going to say. Apart from anything else they can walk away with the machine under their arm! :-)
Yes - although that would at least be readily detactable.
Even without taking the machine away it's pretty trivial to boot from a CD (or memory stick, or floppy even) that they've brought with them and get to single user/root.
Not entirely trivial - I have the boot order password-protected in the BIOS. The sunk cost I'd put into achieving that is partly why it came as such a shock to find grub behaving like this.
Presumably all that's needed to circumvent that though is to reset the BIOS isn't it?
If the *data* is really confidential then lock the machine up and encrypt the filesystem.
One of the many things I have to be thankful for in my life is that I don't have to handle "really" confidential data.
Quite! :-) My security and backups are aimed more at keeping my data safe if either my main machine catches fire (or other less spectacular but equally destructive disaster) or some malicious attacker gets at it somehow. To that end all important data is copied to more than one 'off site' store.
Chris G wrote:
Not entirely trivial - I have the boot order password-protected in the BIOS. The sunk cost I'd put into achieving that is partly why it came as such a shock to find grub behaving like this.
Presumably all that's needed to circumvent that though is to reset the BIOS isn't it?
That isn't always true, bios passwords don't always get reset by using the clear cmos jumpers etc, although in those cases there is usually a way of doing it but it may require a lot of effort (some IBM kit for example needs a new flash chip, or at least access to a programmer to modify the old one)
In any case a lid lock would make resetting the bios that all the bit harder if you were concerned, most cases have the ability to do this via a little tab on the back which you can pop a padlock through. Tin snips would circumvent most of them but it's all about adding barriers. Also at the point someone is going inside the machine and moving the clear cmos jumper they may as well just pull the drives and plug them into something else.
The real solution when this is a concern is to use the purpose built computer safes if the machine room isn't secure. You can get tower sized total enclosure ones that would prevent physical tampering including plugging in/inserting removable media and once bolted to a concrete floor with good capture bolts would make removal/theft of the machine pretty difficult (or at least very noisy). We have a client where use of these on a database server is enforced by a regulatory body.
I suspect that Dan's concern may not fall into the realms where such things are justified as I am guessing his aim was to stop inquisitive tampering rather than a full scale attempt at data theft, otherwise the box would already be physically secure.
On Tue, 15 Sep 2009, Wayne Stallwood wrote:
I suspect that Dan's concern may not fall into the realms where such things are justified as I am guessing his aim was to stop inquisitive tampering rather than a full scale attempt at data theft, otherwise the box would already be physically secure.
What he said.
OK. I've now replaced the offending grub menu entry with this
title Gentoo Linux (rescue) root (hd0,4) kernel /boot/bzImage-2.6.28-tuxonice-r10 root=/dev/sda5 real_root=/dev/sda5 vga=0x315 video=vesafb:mtrr:3 console=tty1 softlevel=nonetwork
and added this line
password --md5 somethinggeneratedbymd5cryptingrubshell
to the header of the grub config file. Things are much better now.
When I read the title I expected an email about getting food at the ALUG meet. I think I'd better go get something to eat... Bill
-
Bill Hill -
Chris G -
Dan Hatton -
Srdjan Todorovic -
Steve Fosdick -
Wayne Stallwood