Leo Sutic wrote:
>
> Berin,
>
> as I read through this reply, I realized that I have been using the name
> Avalon to refer to the Framework and Excalibur, when Avalon really refers to
> a set of projects, including Phoenix, Framework and Excalibur. What I'm
> concerned with is the application of those rules to Framework and Excalibur.
> Not Phoenix.
>
> I'll start with Rule 12: Secrets stored in your code won't protect you
>
> This rule introduces hostile JVMs. I will simply give up against those - if
> the JVM is insecure, I see no way to make Excalibur/Framework secure.
Still, I wouldn't put the secret keys in code, but in a keystore. Things
like that need to be kept in mind.
> Rule 2: Makes extension of classes and thus code reuse difficult.
> Rule 3: Makes code re-use difficult.
> Rule 8: Makes extension of classes and thus code reuse difficult.
For components, they should be the final implementation--so extention
should be limited. For the core framework, the interfaces are correct,
and the default implementations are a starting point--your own implementation
should be hardened in the end.
> Rule 9, 10: Kills application of Excalibur/Framework in a distributed
> environment.
Not Excalibur, but definitely Framework. I don't completely trust object
serialization, and prefer either proxy or some other distributed method.
Possibly even SOAP or some other Web Services protocol.
> Basically, my gripes with the article boils down to the fact that many of
> the rules will result in a non-extendable framework, which is a bit of an
> oxymoron to me. The 9th and 10th rule is especially irritating, as I mainly
> do work in a clustered environment.
Keep in mind that the mantra of Secure programming is unless there is a
documented need (i.e. for Configuration/Parameters) for an exception to
hardening rules, harden it. IOW, If you don't need it, don't provide it.
Most of the framework is interfaces and contracts--that is fine.
> The question is, is Excalibur/Framework designed for Phoenix, or as a
> general purpose library? If it is designed for Phoenix, then it should be
> hardened as described by the rules given. If not, I believe that the loss of
> extensibility caused by the rules will make Excalibur/Framework unsuitable
> for general-purpose use. Which means that we'll be back to
> each-project-having-its-own-framework-etc. and you know that kills security
> fast.
No the Framework is definitely generic.
> So - would it be possible to restrict the hardening to Phoenix, leaving the
> framework open and unsecure? I think this will save the framework from being
> commited to a very small target, and allow Phoenix to be as secure as
> possible.
We can seal the packages (something that wasn't available at the time of the
articles writing--or at least the auhtors weren't aware of it) in Framework
and all the Avalon projects without causing too many problems. That will
remove the need for some of the rules in the first place.
> > I deal with customers who are very protective of their
> > data--which makes it my business to be protective of their data too.
> > I urge you to do your own research. Security by design is more difficult,
> > but when you are developing a server framework it is mission critical.
>
> Agreed 100%. But should that go into the framework/Excalibur or into
> Phoenix?
That work needs to go into every formalized Component (final implementation)
in Excalibur (e.g. DataSources, and Component), Cornerstone, and Phoenix.
In fact, you will find that for Excalibur in the Components I wrote, this
has already been done (and this before I read the article). I didn't disable
cloning and serialization, but I knew the code was going to be used in a
web environment that is known and proven to be hostile. The Framework should
be carefully constructed, but it's primary purpose is to provide interfaces
and some default implementations.
S/MIME Cryptographic Signature
