Introduction to the Paranoid Framework for Perl

Rationale | Design | Deep Dive | Beyond Paranoid

Rationale

There is a tremendous amount of vulnerable code in existence. I prefer to believe that this is not due to developer incompetence as much as most developers are focused, understandably, on solving a specific problem. Depending on the urgency of the problem, they may not have the liberty of spending the time trying to anticipate how the solution can be used against them. How many times have each of us created a solution to a pressing problem as a throw-away solution, only to have that code recycled for future incidents? What worked the first time for a specific set of data, with known constraints and provenance, is suddenly vulnerable to abuse when the constraints are changed or, worse, when provenance of the data is unknown.

So much of the code we adopt is based on a mountain of assumptions, and we rarely take the time to implement safety and consistency checks because it can be time consuming and tedious. In practice, writing robust and secure code can often be magnitudes more time intensive than solving the core problem itself. This was the conundrum I was faced with two decades ago. As a member of the open source community, I never wanted to be responsible for a vulnerability that would impact someone else's application, but at the same time, I also wanted to focus on the more recreational aspect of coding, the opportunity to solve fun problems.

It was at that point that I decided to make building a secure programming framework the problem I wanted to solve. Finding a way to build more interesting programs without incurring the constant tedium of manually reimplementing safety and consistency checks to protect the operation of sensitive programs.

This is the core rationale for Paranoid's existence. To make it possible for a programmer to write software that doesn't need to spend time protecting itself. Rather, it should use APIs and a framework that are designed to protect themselves.

I can make no promises as to how successful Paranoid is at achieving this goal. The reality is that all code is vulnerable. Any program of a reasonable level of complexity will always have attack surfaces that can be exploited. All the security-minded developer can do is try to minimize that exposure. It is impossible to anticipate every permutation of code invocation or input to process, but what we can anticipate, we should. Secure code is ultimately about risk management. It is my hope that the Paranoid framework can be a useful tool for reducing that risk.

Design Goals

The Paranoid framework hasn't covered all security-related problem domains, but it will grow over time, as it already has. As of now, however, it should make the following areas more safe:

execute with less vulnerability to process environment poisoning (see Paranoid(3))
execute programs in taint mode, as well as strict/warnings
work safely with deeply nested data structures (see Paranoid::Data(3))
manage quad integers on both 32 and 64 bit platforms in a unified way that preserves 32 bit access for quad values that remain expressable with longs (see Paranoid::Data(3))
provide real-time debug tracing that is digestible even in forked process applications (see Paranoid::Debug(3))
perform I/O in multiple process concurrent access environments (see Paranoid::IO(3))
perform I/O safely in a forked multiprocess application with inherited file handles (see Paranoid::IO(3))
perform transactional read/write I/O patterns with non-degradable flocks (see Paranoid::IO(3))
perform file system operations (see Paranoid::Filesystem(3) and Paranoid::IO::Glob(3))
perform line-based file access w/o potential memory overruns (see Paranoid::IO::Line(3))
unifed logging architecture (see Paranoid::Log(3))
process signal handling dispatching for multiple handlers (see Paranoid::Process(3))
child/parent bi-directional process communication (see Paranoid::Process(3))
system calls (see Paranoid::Process(3))
process forking w/max children limitations (see Paranoid::Process(3))

There is more to the suite of modules provided in the Paranoid framework, of course, but the remainder are either convenience functions or analogs of existing functions, but with the integrated debugging capabilities.

Deep Dive Topics

With the core rationale and design goals out of the way, we can now start diving into deep dives in each of the topics broached above. Those will be additional posts that will be linked to below:

Secure Perl Programming 101: Things you should know before using Paranoid...
Coming soon...