From: Dave Taht <[email protected]> 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 [email protected] | -- Mark Twain _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
