On Fri, 18 May 2001, Paulo Gaspar wrote:

> In the case of DoS, I don't believe a bit on "trusted tags" and such
> stuff. Why monitoring the tags at all if "while(true)" is so easy.
> 
> I mean, the front door is wide open, why care about that little
> window?

Well, what I said was "trusted tags" and "only pure jsps, no
user code". That means a webapplication will be allowed only if it has no
libraries, no servlets, no user tags - and only JSPs that are not using <%
%>, but only a limited set of tags.

All the above is equivalent with what Jon described ( except syntactic
sugar ). It'll be <foreach> instead of #foreach, etc - so at least you'll 
use the JSP syntax, and your app will work in "normal" containers as well.
It will be a valid JSP in a valid webapp - but of course the container
can't be called a servlet container ( it doesn't run even servlets :-)

I doubt too many installations of Velocity are set up to disallow user
code - it's not too much you can do. It'll be secure - probably because
nobody will care to use such a thing :-) And if you allow any user code -
all the #foreach prevention of DOS goes away.

( it's like the famous "thin air" firewall - it's the most secure, but
pointless ).


> The only way to close everything is by monitoring the Servlets and
> allow setting some limitation on time per request. And that does not
> look so hard to do since Servlets are passive entities (meaning
> that they do NOT call Tomcat, Tomcat calls them) and their basic
> implementation (base class) belongs to Tomcat.

I agree.

With a security manager you control almost everything - except the amount
of CPU and memory. It is possible ( and not very difficult ) to monitor
the CPU amount used by a servlet - just a trivial interceptor that will
log the moment of entry and exit in servlet code. You'll need a thread
that periodically checks if a servlet/jsp is "hunged" or takes too much
time, and disable the whole app if it is the case.

It is also possible to periodically check the amount of memory used by
each thread. ( it's much harder - but I think you can hack a bit with JPDA 
and do it ). ( like OptimizeIt work for example ).


Both will be far more usefull than "security by removing all usefull
features". 

> BTW, I am not the first person talking about JMX in this list.

JMX is great - I like it a lot, it can be added easily by a module - but I
don't think it's a big priority for now. After 3.3 is released we can
discuss new features as add-on modules ( I have a few ).

Costin

Reply via email to