cyber-"terrorism"?

[Ben Laurie]

Peter Fairbrother wrote:
> Ben Laurie wrote:
> 
>>Brian Gladman wrote:
>>
>>>>Ben Laurie wrote:
>>>>
>>>>
>>>>
>>>>>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.
>>>>
>>>>What exactly is a "secure kernel" here? How does it help?
>>>
>>>
>>>http://www.nsa.gov/selinux/
>>>
>>>I couldn't resist posting this link on ukcrypto!
>>
> 
> I just bet you couldn't resist promoting the NSA. :)
> 
>>FreeBSD 5 has similar stuff (TrustedBSD was rolled in recently, I
>>believe), 
> 
> 
> 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).

Systrace is not what you think it is - its fine-grained control over 
system calls.

> 
> 
>>More secure is EROS (http://www.eros-os.org/).
> 
> 
> Yes but, no fault to them, EROS is unusable as yet.
> 
> 
>>And so on.
>>
>>However, none of them solve buffer overflows. They just mitigate their
>>awfulness.
> 
> 
> Rewriting "C" compilers to prevent the possibility of buffer overflows would
> be a good way to go, but Theo amongst others says it would break too much.
> Sigh.

Take a look at Cyclone.

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

My point was that it prevents attacks _on_ the BIOS.

> 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?

STO?

> None of these technologies will prevent an attacker with a (metaphorical,
> £2,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,

No you wouldn't, because if you are wrong, Pd will work. And that would 
be bad.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html