[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: to allow root logins or not?



On Sun, 2007-04-22 at 01:37 +0300, Linas Žvirblis wrote:
> Greg Folkert wrote:
> 
> > Okay. then, do a test install with root disabled, Then try to login from
> > the console as root.
> > 
> > Won't work.
> 
> Yes, with "normal" runlevels.

Yes, but isn't that the NORMAL way of using machines? You are sort of
doing a "I understand... but" kind of things here. Physical access is
required to do anything else. Physical Access means, me being in very
close proximity to the machine... able to make physical contact with the
machine, able to apply said screwdrivers to said machine.

> > What you are trying to intimate is that when booting into single user
> > mode you just get right in.
> 
> Well, yes. I recently did a clean install with root logins disabled.
> When I booted into single user mode it said something about root account
> being disabled and gave me a root prompt. Is this not the expected behavior?

It was the default behaviour for a long time on most Linux distibutions.
It is the same with current commercial *NIX systems.

Again, it comes down to Physical Access. If I have physical access to
your machine, it a mere matter of minutes for me to *HAVE* it and you
being none the wiser. Have screwdriver, bootable CD media, will travel.

> > Okay, so if you *ARE* at the console and you
> > are booting... what is to stop you from doing a modified boot where
> > "init = /bin/sh"
> > 
> > Hmmm. Didn't think about that huh?
> 
> I did. I have grub password-protected.

Trivial to bypass, only keeps honest people honest. Again, physical
access, bootable media and screwdriver.

> > And the analogy about a car and its locks... If the person is really
> > interested in your car and it is behind bars or in a cage/locked down
> > facility... what really matters is the physical access being removed.
> > But once in there he/she only has a limited amount of time before the
> > "authorities" take measures.
> 
> Maybe my analogy is not the best one. But this is a security concern. So
> is passwordless BIOS setup, and so is passwordless bootloader. From what
> I understand, we both agree on this.

If you are in a locked down facility, with proper access control in
place and proper access tracking with proper visual recordings of said
access doors... passwordless BIOS and Bootloader are a needless step. If
the person gets by the very impressive access control system, the actual
booting and changing of your system would be trivial in comparison.

> My point is that the installer option does not do what it says. It makes
> machine more secure once running, but makes it more vulnerable at boot
> time, and it is not obvious that this will happen.

Boot time, once again... these locks are unimportant when physical
access is compromised. It is a matter of using a a screwdriver or
bootable media or both, to achieve the ends. The methods in which you
provoke me, by uselessly trying to prevent me from getting access when I
am standing AT and TOUCHING the machine, are not going to stop me for
more than a few moments, if not seconds. Though they might cause me
think of new and deviant ways to really make you look bad.

> > Come on, think with me on this, don't let those piss-green colored
> > glasses color your thinking habits.
> 
> Green does not really suit me.
> 
> I realize that it is trivial to fix. I can password-protect grub, and
> remove single user mode from the menu. I can also set an insanely
> complex password for root user, and never use it.
> 
> I never fully understood why Debian does not default to most secure, but
> this is not what I am talking about right now. I am merely pointing out
> what I consider to be a problem with the installer.

There is no such thing as "most secure". There is only "secure enough"
ever. Secure enough does not stop me from subverting the guards at the
doors, or securing a door-card or even just ramming a hi-lo through the
wall. Once again, if I have physical access, I have your machine. There
is no way to prevent it. That is, unless you have a Windows server, to
which I'll just sit, point and laugh, probably get caught due to rolling
on the floor laughing.

> Please do not take my words as a personal attack. That was never my
> intention.

Never did, I hope you don't take what I am trying to point out as a
GAPING HOLE in theory on machine security as an attack on yourself.

IOW, take all the methods, practices, proposals, theories, standards you
want. If they are implemented on a machine basis and FACILITY SECURITY
is ignored or very bad, it is money and time poorly spent.

Now, if your facility is in good hands and you have reactionary
mechanisms in place, to combat a breach and you have have these methods,
practices, proposals, theories and standards in place. Then and ONLY
THEN are they worth the time and effort. Then they are a tool to slow
the spread or corruption or compromises.

Until Physical security is handled first and foremost and dealt with
properly, all the other methods are just going to slow the attacker down
by a few moments and maybe not at all.
-- 
greg, greg@gregfolkert.net

That was as boring as a performance of "Richard the 3rd" with potatoes for
actors. They're all eyes.

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: