Hi there,
Erm, before this gets out of hand - there's a perfectly logical reason that you
can easily, with physical access to the machine, get root access without a
password. That reason is because you already have physical access to the disk so
you could easily boot your own system and mount the physical disk inside your
OS. (eg. boot your own linux OS off a floppy, mount the hard-drive, and you can
do anything to it). Making attacks difficult or undocumented does not secure you
against attacks - it just makes it far less clear which attacks you are actually
exposed to and which you are not.
Only closed-source (security by crossed-fingers) operating systems would
actually try to obscure a method of access that you can already get if you
understand your the system. The security you get in Linux tends to be more
independant of the skill of the attacker than certain other operating systems -
those others maybe don't provide a clickable icon to give you a root console,
but physical access to the machine in those cases means exactly what it means
in a standard Linux system.
If you don't want anyone, even with physical rather than network access to the
machine, to be able to have any access except via their assigned user account,
then you have to address the host environment itself rather than just the OS
configuration. Eg. lock the machine physically so that they cannot get to the
disk, password-lock the BIOS setup so they can't re-enable booting off CD or
floppy (if they still have access to those), and seal up your lilo so there is
no user control over bootup without the requisite password.
It's one thing for a system to try and block a certain class of attack simply by
failing to provide a graphical interface and user-manual for the attack, and
it's another thing for that certain class of attack to be blocked implicitly by
a clear security model. If you can get to the machine, the BIOS, and/or lilo,
then according to any sane security model that machine is *yours*. And no amount
of file permission nonsense or kernel configuration is going to change that.
This scenario shows very well what you need to do to *really* secure against
this sort of physical compromise (if such a compromise is considered a threat in
your situation) - systems that pretend to be otherwise are not more secure
against such a compromise, they're just less obviously insecure to
administrators and auditors who are trying to secure their systems.
If it's already possible to do something, doesn't it make more sense just to
expose that functionality in a clear way rather than trying to tuck it away out
of sight?
Cheers,
Geoff
> ** Reply to message from Mark Weaver <[EMAIL PROTECTED]> on Sun, 18 Feb 2001
> 22:14:34 -0500
>
>
> > Bill,
> >
> > I would have to agree. I can't believe it would be THAT easy to get into
> > even one's own machine so easily when the root user's password has been
> > forgotten. Seems to me that's an incredibly HUGE security hole, and find
> > the possibility very unlikely. At least I would hope that it is.
> > --
> > Mark
