Skip to main content

Is the security-manager enabled in your server?

Posted by felipegaucho on January 4, 2006 at 2:37 PM PST

Recently I have tried to run Cejug-Classifieds on GlassFish - my first
try was frustrated because the application didn't open even the first
page. And the server console didn't reflect anything about the problem.
Very strange, but very didactic also, as I will explain in this blog entry.

Cejug-Classifieds
assume Tomcat as its target server
and it also was tested
on Geronimo and

Websphere
. Due to these successful tests, I got confused
about such a difficulty to run it on
GlassFish
. After few inspections and with a very helpful support from
the

GlassFish forum
, I figured out the
problem:

security-manager
issues. Glassfish comes with the security-manager
enabled by default
and it avoided my application to include security
restrictions on demand - my original algorithm. The Cejug-Classifieds has a security module based on a JassFilter designed to authenticate user requests. During the JaasFilter instantiation, the system adds a set of file names into the system properties.

fishing.gif

On the code below copied from the login module, the method
init(FilterConfig) of the filter tries to set the name of the
JAAS*
properties files as

System properties
, but it is not allowed when the security-manager is enabled:

	public void init(FilterConfig arg0) throws ServletException {
ServletContext context = arg0.getServletContext();
System.setProperty("java.security.manager", "");
System.setProperty("java.security.policy", context
.getRealPath("WEB-INF/jaas/default.policy"));
System.setProperty("java.security.auth.policy", context
.getRealPath("WEB-INF/jaas/app.policy"));
System.setProperty("java.security.auth.login.config", context
.getRealPath("WEB-INF/jaas/jaas.config"));
}

* JAAS is a subject to a further blog entry - for now, I will focus on the security-manager.

The work around this problem and the discussions about security
revealed a curiosity: the most popular web-servers come with the
security-manager disabled. Why?
The server vendors argue about the facility
of disabling security-manager
during the development phase and also argue about the need of a experienced
technician in order to configure the correct details during the deployment
into a production server. Well, I agree in part with such policy but I perceive the
damage on the culture of the developers. How many times did you, developer,
think about the security-manager and its functionality? If you answer
almost never or if you even don't know what this thing means, don't
worry - you are part of the majority of Java community that never has time
or interest to learn about that.

Another interesting detail is about the
Java
TM
2 Platform Enterprise Edition
Specification, v1.4
which claims that the Security Manager is not
optional; it must be enabled in the Application Server
. Glassfish
just follows the specification - and why the other servers don´t do the same?
The answer seems related to the legacy software - several years of unsafe
servers have given us a comfortable feeling about the servers with security-manager
disabled. Your server is probably running without security-manager right
now, and I invite you to think about such fragility.

What is the security-manager about?

By the specification: The security manager is a class that allows
applications to implement a
security policy. It allows an application to determine, before performing
a possibly unsafe or sensitive operation, what the operation is and whether
it is being attempted in a security context that allows the operation to be
performed. The application can allow or disallow the operation.
In
simple words: imagine a client deploying a new application in the server of
your company. How can you verify if this application is not hacking your
system, injecting data in your server or facilitating a
hacker attack? The most common answer is: my server administrator will
take care about that
. The second question is about how the administrator
will guarantee the server safety if he doesn´t have access to the application
code. Everything depends on the confidence between you and the application owner
- a fragile policy, isn´t it?. The evaluation of how the software is produced
and also the deployment procedures reveal the main issue: the most part of developers
doesn´t even know about security needs in a web-application software. They
ignores the problems a malicious code can produce in a server because the
majority of the servers never forced them to think about that. I have been observing a lazy behaviour in terms of security - the application running on the
server seems to be the only objective of the developers and the security
consists on a low priority concern.

The most part of developers ignores the security needs in a web-application software.

The absence of a security-manager causes a lack of knowledge about the
security concepts underneath the JAAS framework - and that was the main
problem with my simple web-application. Talking with friends I detected that this
problem is much more common than I was expecting and then I decided to write
about it. Asking about security-manager, experienced developers revealed
weird concepts about that, including something you need to disable
in order to get all the things working on
. That indifference about security
seems to be a flaw in the development process - and also a dangerous culture.

I think if you expose your developers to a safe environment
since the beginning of your next project, there is a better chance it will
be conformant with the servers with security-manager enabled. Better yet, if
you spread the security concerns in your institution, there is a great chance
of offering more elegant products for your clients - more safety, more
software quality.

The game of the roles - a way to learn JAAS.

Security-manager provides security to the server, but your developers are not system
administrators - how to teach them about security? How to provide a real JAAS
experience for your team? The applications I have done in the
last few years had no security - it was traditional Java web-applications
based on simple login/password authentication, most of them
without JAAS -
just simple verification through databases or files. When I started to use
JAAS, a more sophisticated development become necessary. Through JAAS you
can't simply use if(...) statements in order to verify if a user
can execute a procedure into a system, you need to delegate the validation to
the web-container and that is more complicated, however more elegant. In order to
improve the security of my applications, I adopted
the following policy: nobody can access my application without a
role
. If I have a funcionality open for all users, then I adopt a
guest role in order to allow anyone to use that. The pratice with
roles and the learning required in order to deal with the JAAS
configuration files have enhanced my view about how the things work on the
J2EE world - and I strongly recommend you to include JAAS in your development
cycle.

Acknowledgments: I would like to register the
friendly support from the glassfish team - Jean François Arcand and Ronald
Monzillo demonstrated patience and gave me an excellent way to learn about
glassfish. The glassfish team seems very motivated and I guess their
Java EE 5 Application Server will rock on 2006. The cejug-classifieds team
is hard working in the first release of our project - and we will try to
distribute a pre-configured package to run on glassfish.

References:

Related Topics >>

Comments

Very good

Some basic concepts are ignored by some developers