cyber-"terrorism"?

[Peter Fairbrother]

Ben Laurie wrote:
> Brian Gladman wrote:
>>> Ben Laurie wrote:
>>>=20
>>>=20
>>>> I think their point, and I'm inclined to agree, is that of the things
>>>> you say we need to be secure, the least important is the trusted boot =
-
>>>> and if I have a security kernel running, I need it even less.
>>>=20
>>> What exactly is a "secure kernel" here? How does it help?
>>=20
>>=20
>> http://www.nsa.gov/selinux/
>>=20
>> I couldn't resist posting this link on ukcrypto!

I just bet you couldn't resist promoting the NSA. :)
>=20
> FreeBSD 5 has similar stuff (TrustedBSD was rolled in recently, I
> believe),=20

Last time I looked TrustedBSD was more insecure than plain Linux - but that
may have changed.

> and all the BSDs have systrace. And a pile of related things.

Great, but no use until after you're rooted, when the logs can be deleted
(I've seen this actually happen, or rather I've inferred it must have
happened, in a rooted OpenBSD box not secured against the SSH
vulnerability).

> More secure is EROS (http://www.eros-os.org/).

Yes but, no fault to them, EROS is unusable as yet.

>=20
> And so on.
>=20
> However, none of them solve buffer overflows. They just mitigate their
> awfulness.

Rewriting "C" compilers to prevent the possibility of buffer overflows woul=
d
be a good way to go, but Theo amongst others says it would break too much.
Sigh.

However, this doesn't answer my original question of how a "security kernel=
"
prevents BIOS-based attacks.



The "secure boot" patented by someone (Intel/ M$?) (it claims a patent on
using undefined cryptographic means to secure a connection between just
about anything! See US patent 5,937,063) doesn't really help by itself, as
it just encrypts the connection between the BIOS and the microprocessor.

Fine, but that just puts the onus on protecting the system calls that write
to the BIOS instead of being able to write to the BIOS directly (through a
system call?). Nah, and I don't believe in "nubs" either, though STO in
digital content creator's proprietary 'nubs" might give them a few months
extra. Should I have posted that last idea?




None of these technologies will prevent an attacker with a (metaphorical,
=A32,000) pair of crocodile clips and access to the inside of a running box
from copying "digital content", and I know of little that will. They're
about stopping 'file-sharing", not stopping serious attackers, as far as
distributed "digital content" is concerned.

As for your secret files, against a serious attacker, afaik if someone can
get access to your box's hardware and not be detected, and you later input
your password, you can be screwed all the way. A BIOS write-only jumper is
enough for most ordinary uses (assuming a secure BIOS with no warm reboots
etc.; there was a project to write a secure universal open-source BIOS, but
I don't know how or if it's going); because you just can't protect against =
a
determined attacker who has physical access.

I'd love to be proven wrong here,

-- Peter Fairbrother