Issues with capabilities and OpenJDK linking

[Andrew Haley]

On 05/05/2010 09:15 PM, Andrew John Hughes wrote:
> There is an issue with the linking of the libraries in the JVM due to
> its use of $ORIGIN in the runtime path:
> 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6919633
> 
> $ readelf -d /usr/lib/jvm/icedtea6/bin/java -V
> 
> Dynamic section at offset 0x9ed0 contains 31 entries:
>   Tag        Type                         Name/Value
>  0x00000001 (NEEDED)                     Shared library: [libz.so.1]
>  0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
>  0x00000001 (NEEDED)                     Shared library: [libjli.so]
>  0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
>  0x00000001 (NEEDED)                     Shared library: [libc.so.6]
>  0x0000000e (SONAME)                     Library soname: [lib.so]
>  0x0000000f (RPATH)                      Library rpath:
> [$ORIGIN/../lib/ppc/jli:$ORIGIN/../jre/lib/ppc/jli]
>  0x0000001d (RUNPATH)                    Library runpath:
> [$ORIGIN/../lib/ppc/jli:$ORIGIN/../jre/lib/ppc/jli]
> 
> When capabilities are added to the java binary:
> 
> setcap cap_net_bind_service=+epi java
> 
> glibc no longer allows relative paths and the expansion of $ORIGIN
> when the binary is run as a normal user
> (http://sources.redhat.com/bugzilla/show_bug.cgi?id=11570).  So we
> get:
> 
> /usr/lib/jvm/icedtea6/bin/java: error while loading shared libraries:
> libjli.so: cannot open shared object file: No such file or directory
> 
> due to:
> 
> 13919 open("$ORIGIN/../lib/ppc/jli/libjli.so", O_RDONLY) = -1 ENOENT
> (No such file or directory)
> 
> Such a capability needs to be added to allow Java to bind ports below
> 1024 as an unprivileged user.

Does it?  By giving Java this capability you'd be allowing every Java
program, no matter what it was, the ability to bind to a privileged
port.  So, anyone on the computer wanting to bind to this port need
only write a small Java program.  And if they can do this they can
hijack incoming connections.

It makes far more sense for a separate (and very small) privileged
program to have the capability to bind to the specific port.  This
program can then pass the file descriptor bound to the port to the
Java program.

There are other ways to do this, too.  A small program can launch as
root, bind to the port, then downgrade to a regular user and launch
Java.  Or a program can forward the port to Java.  There are libraries
to handle Java access to privileged ports: the Apache commons daemon
handles this, IIRC.

AFAIK iptables can forward the port in the kernel, and then there's no
separate program required, but this has some security problems: any
process could then bind to the forwarded port.  This is still better
than giving the Java binary the capability to bind to privileged
ports, though.

I'm not sure there are any situations in which giving the Java binary
enhanced privileges makes an sense from a security point of view.

Andrew.