Re: [Bloat] [Cerowrt-devel] wired article about bleed and, bloat and underfunded critical infrastructure

[David Collier-Brown <davec-b@rogers.com>]

From: Dave Taht <dave.taht@gmail.com> wrote:

>> in the 80's, we've
>> known that security-based code should not be exposed to user code and vice
>> versa.  Yet the SSL libraries are linked in, in userspace, with the
>> application code.
> I note that I am glad that they are mostly dynamically linked in -
> something that wasn't the case for some other crypto libs - because
> finding applications
> that linked statically would be even more difficult.
>
>
Arguably, one shouldn't have security-critical code in an space
addressable by the application program. In the specific case of a
complicated encryption engine, I'd wish to have a fairly stupid system
service to do the time-sensitive part,  on the other side of a system
call with limited options. A ring-crossing if I could, an ioctl if I
must (;-))  Most of the rest I'd have in a daemon, with some syntactic
sugar in a callable library, but with no privilege attached to the sugar.

Application calls sugar, sugar calls ioctl, fast but stupid service
sends data.  On certain hardware, the fast-but-stupid  stuff is a crypto
accelerator the CPU board. I'd *strongly* want using that hardware to be
privileged.

This isn't sufficient, mind you: bugs will still happen.  What I really
want is a defence in depth to mitigate the effects of bad code, bad
requirements and bad schedules. 

--dave
[One smallish part might be a funded attack team, possibly named MI5
(not 6!)]

-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net           |                      -- Mark Twain