Request for Review - Fedora Security Basics

[Eric Rostetter]

Quoting Tom Diehl <tdiehl at rogueind.com>:

> Well, I will admit I had not thought of that case. :-) In that case they can
> still play with grub and bypass the root passwd at boot time, so how does
> that help?
> 
> I am sure we could argue different corner cases on this forever. :-) I hope
> you will agree this is a corner case though.

Since there are likely to be multiple such cases, why discount them?

> How does a grub passwd not solve the problem. As someone else already
> mentioned
> if you can modify the bootloader you can run init=/bin/sh from the grub
> command
> line and bypass the passwd checks anyway.

If you want to limit the discussion to only machines running grub, then
the argument becomes somewhat easier.  But maybe some people want the
docs to pertain to alternative boot loaders also?  Maybe not...  I don't
know the scope of the doc myself.

But, there is of course always the defense in depth argument.  Always use
as many layers of defense as you can.  Say they manage to somehow know
your grub password (they watched you type it, it was easy to guess, they
used to be an employee of yours and you didn't change it since they left, 
etc).  But if they don't also know the root password, then the defense in
depth strategy stops them.  Your strategy (rely only on grub) does not
stop them.

> But in a data center environment you already control who is sitting in front
> of the console.

No, you don't.  Someone can come in (janitor, repair man, someone who was
able to social-engineer his way in, someone who broke in, etc) who isn't
supposed to.  And can you really trust all your employees anyway?

> If you do not then you have other problems.

We all have problems...

> My whole point to this goes back to the original concept of "If you have
> physical access to the machine it is not secure" I will argue that a grub

My whole point is we can make it as secure as possible by using the
security in depth principal, to cover all cases.  Sometimes (a university
computer lab) we let people have physical access to the machine, but
we still want to keep them from playing with it as root, to the best
extent possible.

So, we disable the power button, put on a bios password, disable booting
from external media, put a grub/lilo/milo/etc. password on, put a single
user password on,  put an alarm on the system that prevents opening the
case without the alarm going off, etc.

Now, what if you *forget* to do one of those? Don't you want a backup
to be there?  I'm not perfect, and it is possible someday I might make
a mistake and accidently leave one of the above security features disabled
after working on a machine.  I'd like to think that I've got additional
backup security methods in place to help protect me even if I do mess
up one of them.  (yeah, if I mess up too many, I'm hosed, but...)

> passwd does more to protect from the casual user trying to gain root access,
> than requiring a passwd for RL-1. It is just too easy to bypass. If as others
> have argued the would be cracker only has access to the console but no access
> to the physical machine then a grub passwd or simply disabling
> <ctrl><alt><del>
> is the way to go.

But what if an upgrade, or a new admin who doesn't know better, accidently
enables <ctrl><alt><del> on it?  What then?

> If they can't reboot it they will never see grub to play
> with
> it.

Uhm, what if they just pull the power cord?  Or trip the breaker?  Or find
a way to short it out.  Or there is a power outage in the building. Or...
 
> Regards,
> 
> Tom Diehl		tdiehl at rogueind.com		Spamtrap address mtd123 at rogueind.com

-- 
Eric Rostetter