Mailinglist Archive: opensuse-security (228 mails)

< Previous Next >
Re: [suse-security] Problem with second user with uid 0?
  • From: Helio Leonardo Mota <HMota@xxxxxxxxxx>
  • Date: Fri, 11 Mar 2005 12:45:36 -0300
  • Message-id: <200503111245.37104.HMota@xxxxxxxxxx>
On Friday 11 March 2005 10:57, nick wrote:
In my paranoid/humble opinion, the root account renders a weak spot, as long
as security concerns. Having one weak spot is BAD, having two... you get the
point.

In this specific case I have came out with this simple security model.

1) The BIOS password should be set , and known only by the boss or revealed
with its prior authorization;
2) There should be a Rescue CD locked down in a secure locker;
3) Day-to-day administrative work should be controlled using sudo;
4) Audit everything

The Disaster Plan process would be:

ALERT: HOST DeltaFox CRASHED !
if ( CALL host Admin ) {
Execute Disaster Recovery Procedure
} else {
CALL Boss
CALL Second host Admin
Boss unlocks BIOS
Second host Admin Executes Recovery Procedure
}

BIOS password should be considered an OTP, specially in the case the boss
reveals it to the Second Host Admin.

HTH,
HLM
> security is not really the issue here, otherwise you would just change the
> password when you get back (which should be done regularly anyway), its
> more the convenience of not having to do so. Your best bet is to take a
> test pc and try set up 2 uid 0's and run whatever you think might need to
> be run.
>
> Nick
>
>
> On Friday 11 March 2005 13:22, Mike Tierney wrote:
> In an ideal world of course you would:
> 1) Use only server cases with padlocks and fasten those with steel cable to
> rings set into the walls or floor.
> 2) Password the BIOS
> 3) Set the server to not boot from CDROM by default
> 4) Encrypt the hard drives via a loopback device
> 5) Maybe abandon using the SUSE kernal and use something ultra secure like
> LIDS :)
>
> But seriously, you have to draw the line somewhere!!
>
> If anyone is *REALLY* determined they can
>
> 1) Cut the padlock
> 2) Pop the case and clear the BIOS password via jumpers
> 3) Change the BIOS back to booting from CDROM and pop in a boot disk
> 4) Not sure how they'd deal with the encrypted disks! Maybe get a job as a
> cleaner and install a keystroke logger on the keyboard a few weeks
> beforehand...?
>
> So all of a sudden leaving the root password in a sealed envelope that's
> stored in a locked filing cabinent doesn't sound so bad after all!!!!
>
> > -----Original Message-----
> > From: miguel gmail [mailto:miguel.listas@xxxxxxxxx]
> > Sent: Friday, 11 March 2005 11:23 p.m.
> > Cc: SuSE Securitylist
> > Subject: Re: [suse-security] Problem with second user with uid 0?
> >
> > > Though in the fsck case there is an alternative I have just thought of,
> >
> > but
> >
> > > the solution may be WORSE than the problem! If you want people to be
> >
> > able to
> >
> > > do a fsck in an emergency, then you could always leave a "Rescue CD"
> >
> > with
> >
> > > your boss... Then if anyone needs to actually do a fsck on a crashed
> >
> > server
> >
> > > they can use the rescue disk to boot up and fsck the filesystem in
> >
> > question,
> >
> > > and then reboot the server.
> > >
> > > The drawback to this is that you have to leave the server bootable from
> >
> > CD
> >
> > > :(, which is in itself a security hole. On a positive note though,
> >
> > people
> >
> > > don't just have the root password "on tap" and are hopefully less
> >
> > inclined
> >
> > > to obtain the rescue disk and boot up as root "just for the hell of
> > > it".
> > >
> > > It's always good to have rescue disks handy anyway, just incase the
> > > root/boot file system gets corrupted/damaged. Like I experienced last
> >
> > week
> >
> > > during a routine outage...
> >
> > But, in this case, you can leave the boot cd to your boss, and protect
> > either the BIOS and the Bootloader with a password that only you and /
> > or boss know. If somebody needs to run a fsck, he will need to enter
> > the BIOS pwd and the booloader password.
> >
> >
> > --
> > Saludos,
> > miguel
> >
> > --
> > Check the headers for your unsubscription address
> > For additional commands, e-mail: suse-security-help@xxxxxxxx
> > Security-related bug reports go to security@xxxxxxx, not here
>
> --
> Check the headers for your unsubscription address
> For additional commands, e-mail: suse-security-help@xxxxxxxx
> Security-related bug reports go to security@xxxxxxx, not here

< Previous Next >
References