Page 1 of 1

Connect options strange behaviour

PostPosted: Mon May 11, 2015 6:12 am
by PingLord
Hello,

I am running without issues Grsec for more than a year but in the last weeks im implementing collectd for monitoring java apps over JMX. I have updated the RBAC policy accordingly but one issue seems to appear no matter what :

GenericJMXConfConnection: Creating MBean server connection failed: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.CommunicationException [Root exception is java.rmi.ConnectIOException: Exception creating connection to: localhost; nested exception is: #012#011java.net.SocketException: Permission denied]

This happens only with Grsec enabled.

In the collectd and jvm policy i have enabled connect to localhost :

connect 127.0.0.1/32:1-65500 dgram udp stream tcp
sock_allow_family netlink

Any idea of solving this?

Thank you and kind regards

Re: Connect options strange behaviour

PostPosted: Mon May 11, 2015 8:00 am
by spender
What's in dmesg? Have you tried stracing the app to see what syscall fails?

-Brad

Re: Connect options strange behaviour

PostPosted: Mon May 11, 2015 8:35 am
by PingLord
Hey Spender and thanks for the fast answer.

The snippet i posted it is from dmesg and also i have no idea how to get that strace because the collectd daemon starts sucesfully but it has some plugins which are used , one of them being the jmx to monitor the jvm app.Everything works excepting when it tries to use the jmx which gives the error i already posted above.
The strace i tried to use is :

strace -fq /etc/init.d/collectd start >/var/tmp/strace.log 2>&1

If i run it under root without gradm authentification i get denied ptrace , but if i run it authentificated using gradm it starts sucesfully but the same error occurs.

As far as i understand from the collectd with java plugin it seems i calls a java process to spawn and get MBean data using jmx. So it seems not a syscall is failing,but a network connection to localhost even if the java binary and collectd binary have connect to localhost allowed.

Also here are the sysctl options for grsec :

sysctl -a | grep grsec
kernel.grsecurity.linking_restrictions = 1
kernel.grsecurity.enforce_symlinksifowner = 1
kernel.grsecurity.symlinkown_gid = 9991
kernel.grsecurity.deter_bruteforce = 1
kernel.grsecurity.fifo_restrictions = 1
kernel.grsecurity.ptrace_readexec = 1
kernel.grsecurity.ip_blackhole = 1
kernel.grsecurity.lastack_retries = 4
kernel.grsecurity.rwxmap_logging = 1
kernel.grsecurity.signal_logging = 1
kernel.grsecurity.forkfail_logging = 1
kernel.grsecurity.timechange_logging = 1
kernel.grsecurity.chroot_deny_shmat = 1
kernel.grsecurity.chroot_deny_unix = 1
kernel.grsecurity.chroot_deny_mount = 1
kernel.grsecurity.chroot_deny_fchdir = 1
kernel.grsecurity.chroot_deny_chroot = 1
kernel.grsecurity.chroot_deny_pivot = 1
kernel.grsecurity.chroot_enforce_chdir = 1
kernel.grsecurity.chroot_deny_chmod = 1
kernel.grsecurity.chroot_deny_mknod = 1
kernel.grsecurity.chroot_restrict_nice = 1
kernel.grsecurity.chroot_caps = 1
kernel.grsecurity.chroot_deny_sysctl = 1
kernel.grsecurity.tpe = 0
kernel.grsecurity.tpe_gid = 9992
kernel.grsecurity.tpe_invert = 1
kernel.grsecurity.audit_mount = 1
kernel.grsecurity.dmesg = 1
kernel.grsecurity.chroot_findtask = 1
kernel.grsecurity.resource_logging = 1
kernel.grsecurity.audit_ptrace = 1
kernel.grsecurity.harden_ptrace = 1
kernel.grsecurity.grsec_lock = 0