Re: security audit

There is no need to split Velocity into two JARs. As a person who wrote
several security-aware apps (this is not to say that I'm a security expert
by any means, just a security-aware coder), I can tell you that this isn't
true. If you want to allow Velocity internal code to access class loaders
etc. all you need to do is execute such code inside a
java.security.PrivilegedAction code *and* give the velocity.jar the
appropriate permissions inside the security policy file. That way, you
ensure that Velocity code is able to call sensitive methods *regardless* of
whether its callers (that is, the methods before it on the call stack)
themselves have the permission.
If you fail to do the two steps above, Velocity code might be prevented from
calling sensitive methods if its callers don't have sufficient privileges.

You see, when Java security infrastructure checks a permission, it checks if
*all classes* in the current stack trace have the permission. The rationale
behind this is that this way malicious code can't obtain permissions by
invoking some security-hole method in otherwise trusted code - it needs to
have the permission itself. Actually, not the whole stack is examined - if
an instance of java.security.PrivilegedAction.run() is encountered, checks
stop there. By using PrivilegedAction, the programmer says "I know what I'm
doing in this code and there's no need for my callers to have the
permission". An example of this might be a logging component that logs to a
file - it needs a permission to write to a file, but its caller (which can
be a remote code or an applet, in a word anything with a more restricted
permission set) needn't. The developer knows that security can't be
compromised as the caller code can't affect what file it writes to.

So, you needn't break Velocity into separate JARs. You just need to extract
carefully selected regions of code into PrivilegedAction.run() methods, and
then document to sysadmins what permissions are required for velocity.jar to
function properly in security-restricted environment.
As for finding out what permissions are required by which part of the code,
I refer you to Stuart Halloway's excellent Permission Sniffer:
http://staff.develop.com/halloway/code/PermissionSniffer.html

Now (and this is a completely separate issue), to prevent code in classes
that are invoked through a template to execute sensitive methods, simply run
the VM with a security manager enabled with a policy that simply doesn't
give these classes the permissions to access these sensitive methods.
Whatever permission isn't explicitly granted in a policy file is denied (a
healthy approach).

Whew. I didn't write so long a message to any public list in a long while.
Has to do something with the fact that wife and kids aren't home today :-)

Attila.

----- Original Message -----
From: "Will Glass-Husain" <wglass@xxxxxxxxx>
To: <velocity-user@xxxxxxxxxxxxxxxxxx>
Sent: Thursday, May 29, 2003 7:45 PM
Subject: Re: security audit


Ed,

Thanks for your comments (below).  I'd be happy to write a note for the docs
after a bit of discussion here.

Re: the SecurityManager.  That was suggested earlier this spring on the dev
list.  I've looked into it.  It's complex, and requires knowledge of the
Velocity source code.  Essentially, you have to split the files that execute
the methods on the Java classes into a separate JAR file, then designate
that jar file as not have permission to call getClassLoader.  This requires
that you (A) know what those Velocity classes are (B) understand how to work
with the security manager, which is quite complex, and (C) have to modify
the Velocity package every time there is a new release.