Re: Linux, BSD, and Unix are fundamentally insecure.
From: The Ghost In The Machine (ewill_at_aurigae.athghost7038suus.net)
Date: 09/13/04
- Next message: The Ghost In The Machine: "Re: Linux, BSD, and Unix are fundamentally insecure."
- Previous message: Philip Paeps: "Re: how to allocate 512M physically contiguous memory in my driver?"
- In reply to: Hamilcar Barca: "Re: Linux, BSD, and Unix are fundamentally insecure."
- Next in thread: cmad: "Re: Linux, BSD, and Unix are fundamentally insecure."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 13 Sep 2004 14:38:07 GMT
In comp.os.linux.advocacy, Hamilcar Barca
<hamilcar@tld.always.invalid>
wrote
on Thu, 09 Sep 2004 23:25:43 -0600
<20040910012529.204$2Z@news.newsreader.com>:
> In article <3d6111f1.0409092000.60888c43@posting.google.com> (Thu, 09 Sep
> 2004 21:00:34 -0700), Mike Cox wrote:
>
>> When Scott rebooted the machine, he typed in the new root password and
>> was in. The consultants jaw dropped, my boss laughed, and will now
>> trust my MCSE's judgement in all things related to IT in the company.
>
> Your story is surprisingly uninteresting and, to top it off, amazingly
> fictitious.
>
I doubt it's fictitious in the sense that one can easily do the above.
It's mostly a matter of compromising physical security with
something along the lines of a Knoppix disc -- pop it in,
mount, edit, and presto ... the machine's 0wn3d.
However, there are a number of defenses, some of them rather simple.
[1] BIOS password. It takes a bit of work to get around that,
although it's not all that strong as a defense, if one
has a screwdriver handy.
[2] LILO/GRUB password. Not quite as general as [1], but that
screwdriver won't help, either; the best one can do is
some judicious disk sector editing -- and that of
course requires root access.
[3] Encrypted volumes. If one's serious about security one should
at least consider these. Thankfully, Linux supports these
without too much hassle -- although I'd have to look up
the details.
[4] BIOS bootorder. You can forget about booting that Knoppix disk
if this is done right. (You can forgot about booting the machine
at all if done wrong, of course. :-) )
[5] UML/virtual machines. This rather esoteric variant
would work reasonably well; the idea is that the
overlayer (the native Linux kernel) would have no idea
as to what the underlayer (the emulated machine) is
doing; all the overlayer sees is a "linux" executable
running, disk I/O (which goes through the overlayer's
file system, like any good app), and the virtual packet
(TAP/TUN) network traffic. The underlayer could
combine this with SSL and encrypted volumes, plus an
image backup. There is a price to pay, admittedly
-- a small performance penalty for single processor
machines, an unknown performance penalty for multiple
processor machines, mostly because I don't know if
the underlayer threads can use overlayer processor
resources.
[6] Linux BIOS. This interesting variant basically loads the
kernel on the BIOS chip -- and is reminiscent of good old
Amiga Kickstart from days gone by, albeit with a more
sophisticated operating system (though not much more
sophisticated; the main failing of the Amiga Exec was that
its scheduler didn't have dynamic priority adjustment
or virtual memory management -- and the latter was added
by add-on products, although the results were of questionable
reliability, mostly because each app had to be registered
with the software, for some reason).
[7] Diskless CD-boot. A system image is placed on CD
or DVD, and sufficient RAM is on the system so that
no swap is needed for the application. The temporary
file system is stored on a ramdisk. Such a machine
might be compromisable but a reboot would usually
"fix" the compromisation (although some of the more
sophisticated viruses might hide in a secretive RAM
spot during the reboot!) and no damage could be
done to the machine itself, although depending on the
application (which presumably transmits requests to
a back end), things could get slightly muddled elsewhere.
An alternative is some sort of PXE or PXE-like boot
capability, using GRUB and a central file server.
Since this requires the network there's a possibility
of jamming or hijacking, though -- although with modern
switches this appears far less likely than with the
old hubs, at first blush. (It may depend on the switch.)
[8] Self-firewalling. This weird capability basically means that
a box can't talk to itself, and might be next to useless
unless combined with [5]. There are also possibilities
such as transparent NAT, blacklists, and whitelists -- all
done with iptables. Such a box would do as a firewall,
though more specialized hardware is presumably out there
by now.
I'll admit to some curiosity as to what Windows has that can
compete with these, although it is possible for Windows
to run Linux (www.colinux.org or .com; I forget which), run
virtual machines (using VMWare), and support encrypted volumes.
There is also an Embedded XP variant, which suggests [7].
And of course Windows touts a firewall. (How good it is, I
can't say. A firewall won't be much of a defense against,
say, the old Anna K. virus, if someone's stupid enough to
open it.)
-- #191, ewill3@earthlink.net It's still legal to go .sigless.
- Next message: The Ghost In The Machine: "Re: Linux, BSD, and Unix are fundamentally insecure."
- Previous message: Philip Paeps: "Re: how to allocate 512M physically contiguous memory in my driver?"
- In reply to: Hamilcar Barca: "Re: Linux, BSD, and Unix are fundamentally insecure."
- Next in thread: cmad: "Re: Linux, BSD, and Unix are fundamentally insecure."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
