[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jetty-dev] security start up mode for jetty7
|
Jesse McConnell wrote:
> All,
>
> I am thinking of adding in a -security mode to the jetty startup
> somewhat akin to what I have seen in other places where adding the
> option to the cli would trigger jetty to start up with a
> SecurityManager and populate it from a default policy file that we
> include with the distribution. I have been working with it a bit and
> I think it has merit for environments where we want to control a bit
> more the environment jetty is running in.
So this would be in start.jar ?
That is where the classloader is built, so a good place I think.
> I toyed with the idea of writing a more custom SecurityManager but I
> want to see how far we can go with the basic one and twiddling
> permissions.
Sure - perhaps you could have options to pass in an
optional SecurityManager class
> One thing that has raised an eyebrow is the may different properties
> that jetty works with on simply startup and how their format is all
> over the board..
culpa mia!
In the dark ages, Jetty used to use a lot of system properties
for configuration. But for a few years I have informally been
trying to replace them all with proper IOC configuration.
Perhap the move to jetty-7 is the time that we get rid of most
of them?
See individual comments below
> // jetty specific properties
> permission java.util.PropertyPermission "DEBUG", "read";
> permission java.util.PropertyPermission "START", "read";
> permission java.util.PropertyPermission "CLASSPATH", "read";
> permission java.util.PropertyPermission "OPTIONS", "read";
> permission java.util.PropertyPermission "STOP.PORT", "read";
> permission java.util.PropertyPermission "STOP.KEY", "read";
These are all start.jar properties and as such I'm a bit less
concerned about them. I think they should be nice simple names and
easy to understand as they are often used on the command line.
> permission java.util.PropertyPermission "jetty.home", "read, write";
> permission java.util.PropertyPermission "user.home", "read";
> permission java.util.PropertyPermission "jetty.class.path",
> "read, write";
> permission java.util.PropertyPermission "java.class.path",
> "read, write";
> permission java.util.PropertyPermission "repository", "read, write";
> permission java.util.PropertyPermission "jetty.lib", "read";
> permission java.util.PropertyPermission "jetty.server", "read";
> permission java.util.PropertyPermission "jetty.host", "read";
> permission java.util.PropertyPermission "jetty.port", "read";
> permission java.util.PropertyPermission "start.class", "read";
> permission java.util.PropertyPermission "main.class", "read";
these ones come from the start.config or jetty.xml files and are not baked
into the code. Again they are intended for the command line, so have simple
meaningful name.
> permission java.util.PropertyPermission "DEBUG", "read";
> permission java.util.PropertyPermission "VERBOSE", "read";
> permission java.util.PropertyPermission "IGNORED", "read";
These are the simple log configuration ones, which I'm also pretty much
OK with - if you don't like them, configure a real logger.
Note the doubling up of the DEBUG.
> permission java.util.PropertyPermission
> "JETTY_NO_SHUTDOWN_HOOK", "read";
I think this can be removed. We already have setStopAtShutdown
and we can create the shutdown thread the first time a server is started
with that set true.
> permission java.util.PropertyPermission "ISO_8859_1", "read";
This is from the days that JVMs did not agree on charset names.
I think it can be safely removed.
> permission java.util.PropertyPermission
> "org.eclipse.jetty.util.log.class", "read";
This is one that is hard to configure any other way - but it is
well named. Perhaps we just need to protect it from security
exceptions and treat that as null?
> permission java.util.PropertyPermission
> "org.eclipse.jetty.util.URI.charset", "read";
This is surely UTF-8 now (and hopefully will stay that
way this time). But as this is a well named property,
perhaps it can stay just in case.
> permission java.util.PropertyPermission
> "org.eclipse.jetty.util.FileResource.checkAliases", "read";
This can be removed - already IOC on context and default servlet
> permission java.util.PropertyPermission
> "org.eclipse.jetty.xml.XmlParser.Validating", "read";
Well named, so happy to leave it.
> permission java.util.PropertyPermission
> "org.eclipse.jetty.io.nio.JVMBUG_THRESHHOLD", "read, write";
HA!!!!!
I'll probably just make this a static rather than a property
> permission java.util.PropertyPermission
> "org.eclipse.jetty.util.TypeUtil.IntegerCacheSize", "read, write";
Not even sure if this cache is needed anymore?
but probably harmless to leave it
> permission java.util.PropertyPermission
> "org.eclipse.jetty.util.TypeUtil.LongCacheSize", "read";
Ditto.
> Any thoughts on standardizing the format of the properties that we use
> in jetty? Or making sure that we have reasonable defaults and don't
> through exceptions if we are executing in an environment that is
> locking off access from reading these properties?
Well it looks like most of the ones that are hard coded are
already well named.
It is only the start.jar and configuration controlled ones that
are not.
> So, anyone have an issues is my adding in some startup functionality
> for enabling a secure startup mode that sets up the security manager,
> and take a stab at standardizing the jetty specific properties to at
> least 2 conventions for naming and formatting conventions? :)
I've created a bugzilla ticket for this: 277403
I'll do the main code as it's mostly my fault :)
All properties that are in code should be org.eclipse.jetty.* named
this makes the log ones a little difficult.... what do we think
change or leave them?
For system properties that come from configuration, I think
a simpler naming convention should be used. Just jetty.something
like most of them already are.
for system properties for start.jar, I think we could probably
make them command line arguments, so that anything with an
equals sign is used to set properties (not system ones).
So
java -DDEBUG -DOPTIONS=Server,jsp,jmx -jar start.jar etc/jetty-jmx.xml etc/jetty.xml
would become
java -jar start.jar DEBUG=true OPTIONS=Server,jsp,jmx etc/jetty-jmx.xml etc/jetty.xml
> I pulled a branch the other day to experiment with some things can I
> could do the changes there is we are concerned about doing them on
> trunk right now. I am half tempted to say I should just do that as I
> am also pushing towards getting us out of incubation and able to
> release an actual 7.0.0 official release in the shortish term...
Now is the time to make such changes on trunk before it is official.
We break APIs going to 7, so lets do all the breaking at once.
cheers
