tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Beikov <christian.bei...@gmail.com>
Subject Re: Policy files
Date Wed, 24 Apr 2013 17:51:44 GMT
Yes we are talking about security manager policies.

So there is no possibility to just push the policy file to the 
WebappClassLoader? As stated in the reply to Matrin Gainty there do 
exist methods to restrict the webapp, but unfortunately no method for 
supplying a policy file.

So this means I have to parse the policy file myself and add the 
permissions manually to the classloader?
Are there any options in the context.xml I could set for specifying a 
webapp local policy so that I don't have to fiddle around with how 
tomcat is called? I know how to apply a policy at runtime, but don't 
know how this affects tomcat when I apply it e.g. in a 
ServletContextListener. Would be cool if there was an option to do that 
kind of stuff.

Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 24.04.2013 19:13, schrieb Christopher Schultz:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Christian,
>
> On 4/24/13 2:29 AM, Christian Beikov wrote:
>> I am using tomcat as an embedded container for a while now, it is
>> really amazing, but now I got stuck on a topic. I am implementing a
>> testsuite for automatic testing of uploaded solutions by students.
>> The deployment works like a charm, I also found your
>> StuckThreadDetectionValve very useful to kill threads of the
>> students applications. The next assignment will involve some areas
>> where I would like to specify a policy file so that the students
>> can't do anything they aren't supposed to. Now to my problem.
> Cool.
>
>> One thing is that I want a policy file to be in the students
>> projects, so that they actually get the exceptions when they are
>> doing something wrong. What do I have to configure in these student
>> web projects so that they can e.g. deploy the project directly from
>> netbeans to tomcat and have the policy applied?
> I assume you are talking about SecurityManager policies.
>
> Unfortunately, the SecurityManager applies to the entire JVM, so you
> can't do something cool like allow one ClassLoader to run amok while
> classes loaded from another one are constrained. Instead, you can
> place limits on the entire JVM (e.g. no System.exit) and then poke
> holes in those protections for trusted content -- usually a specific
> JAR file, etc.
>
> If you are going to do that, you need to attempt privileged "actions"
> everywhere your driver code is going to do something that requires
> such privileges. If the student code tries to do something forbidden
> (e.g. System.exit), they'll get a SecurityException. If you try to do
> it without a privileged action, you'll also get an exception.
>
>> The other thing is that I want the policy file to be in my
>> testsuite project and configure it on demand when deploying the
>> student solutions. Currently I create an instance of
>> StandardContext for each student web application, then I configure
>> the context and finally add it to the host of the server. What do I
>> need to configure, to apply the policy in this case?
> You have to apply the policy when you launch the JVM via system
> properties on the command-line. Fortunately, all of your privileged
> code should be known in advance, so you shouldn't have to adjust
> anything for student-submitted code: all their stuff is limited by
> your policy.
>
> Remember that you have to give Tomcat all the privileges *it* needs as
> well as your own code. Check the catalina.policy file to see what
> privileges are necessary to properly run Tomcat under a SecurityManager.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJReBLUAAoJEBzwKT+lPKRYzOAP/iEB1IPyKjSSY/74IjYqR31G
> wzF6/HuEzwauYgdCxugxFhiogskUsHGnbgKtd4I0hGRtXwfLQf02c5foR6pV04F3
> dy4ViYvXTvTLgM6YqcqDEClFigfJdRZdqb26bRUvbrSacTAgp6ifm2Tc7yBpkcR2
> rWo0/zdCQTATHlryKnAtfpx0jngoXmyMxrNVH1efw36zN/C50zq26ri9VMG9vEcE
> TOy8w8lscj8PaCKj5e0skgvwKWjGrH4gplLOW07STK0Mtpb4rfSL5iua73CoaPsD
> PvnzlfgJsYWhlzWF6mExKlTDP+9UmC1195VSfVb3yPdSREf+Lk+PcpAIRnqj4Zma
> ZAQys1LcM5CUPzq4y6T4dokGDIXpwsBaphN7S4MKDp+vgb2W0Z6UbidjkUHiZ25r
> 1dPbt67f3Ro6gYRO/ggorc9y5/0yYs6xjaA9SuM7xvm4uGG4lEn092f6FBnd0+OZ
> 7t/6IylDSP5+CxCmXrPBu9TeJppq42biVz8VJaM+BJjlDKU6BIn+P2qPR/N1C2QK
> wR8aSbcxzKWekSkLv5VCnErCDbx+YekMWVfVfuQobQkMIha977cBHlqc+jhioG2g
> QIHaMAPA6JQMEQdSHrob98QirBI9FfZSDDdWQ/w9BuaAT3+bXXPKvUvgbLz14vN+
> CLya7aynTMumUFHBnnv2
> =MeqU
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message