Bug 1015795

d1eaea31c12aa14021cb7719cb427f073a70af21 fixes this in git.

back ported.

selinux-policy-3.12.1-74.9.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-74.9.fc19

Package selinux-policy-3.12.1-74.9.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-74.9.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-18701/selinux-policy-3.12.1-74.9.fc19
then log in and leave karma (feedback).

selinux-policy-3.12.1-74.9.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

selinux-policy-3.12.1-74.9.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Hi,

The SecureLauchner applet works now, but the application "CitrixICA-Application on Demand-NonWindows" (JSAM?) which get's started later on now throws these exceptions:

TunnelServer.jav:057 (10/14 21:20:03.431)[      Thread-324] *** ServerSocket [1494, 5, 127.0.2.1] threw java.net.BindException: Keine Berechtigung ***
TunnelServer.jav:069 (10/14 21:20:03.432)[      Thread-324] Cannot bind to local port1494 - java.net.BindException: Keine Berechtigung
TunnelServer.jav:057 (10/14 21:20:03.433)[      Thread-325] *** ServerSocket [2598, 5, 127.0.2.1] threw java.net.BindException: Keine Berechtigung ***
TunnelServer.jav:069 (10/14 21:20:03.433)[      Thread-325] Cannot bind to local port2598 - java.net.BindException: Keine Berechtigung

So the running applet tries to bind against 127.0.2.1 port 1494 and 2598.

Is this also caused by SELinux?

Besides that I had to relabel the .junper_networks directory with restorecon.

Are you getting AVC msg?

Re-test and run

# ausearch -m avc -ts recent

Hi,

I see some of these kind, probably the try to bind to a 127.0.2.1 ip address:

time->Mon Oct 21 19:35:23 2013
type=SYSCALL msg=audit(1382376923.452:574): arch=c000003e syscall=49 success=no exit=-13 a0=3f a1=7f4851cc7730 a2=1c a3=402 items=0 ppid=2822 pid=3131 auid=1000 uid=1000 gid=500 euid=1000 suid=1000 fsuid=1000 egid=500 sgid=500 fsgid=500 ses=1 tty=(none) comm="java" exe="/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.3.0.fc19.x86_64/jre/bin/java" subj=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1382376923.452:574): avc:  denied  { name_bind } for  pid=3131 comm="java" src=2598 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket

I also found this audit entry, which is also interessting.
Java tries to use hugepages when there are huge pages configured via sysctl knob "vm.nr_hugepages=112":

----
time->Mon Oct 21 19:33:54 2013
type=SYSCALL msg=audit(1382376834.497:543): arch=c000003e syscall=9 success=no exit=-13 a0=7f0d98c00000 a1=400000 a2=7 a3=40032 items=0 ppid=1 pid=2831 auid=1000 uid=1000 gid=500 euid=1000 suid=1000 fsuid=1000 egid=500 sgid=500 fsgid=500 ses=1 tty=(none) comm="java" exe="/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.3.0.fc19.x86_64/jre/bin/java" subj=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1382376834.497:543): avc:  denied  { execute } for  pid=2831 comm="java" path=2F616E6F6E5F6875676570616765202864656C6574656429 dev="hugetlbfs" ino=92958 scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:hugetlbfs_t:s0 tclass=file

You might be best to turn off unconfined_mozilla_plugin_transition boolean.

setsebool -P unconfined_mozilla_plugin_transition 0

Then restart firefox.

Right now we can not easily differentiate between binding to localhost versus the host network device.

We have no confined domains on the system that can execute hugetlbfs_t, which means we have never seen this before.

sesearch -A -t  hugetlbfs_t -c file -p execute
Found 2 semantic av rules:
   allow filesystem_unconfined_type filesystem_type : file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton execute_no_trans entrypoint execmod open audit_access } ; 
   allow files_unconfined_type file_type : file { ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton execute_no_trans entrypoint open audit_access } ;

1.) The current blocking of binds to loopback addresses hinders the Juniper Network Java Secure Application Manager from working out of the box. See also http://www.juniper.net/techpubs/software/ive/guides/howtos/How_To_JSAM.pdf for some introduction.
2.) regarding hugetlbfs_t: what does this mean? Is something on my machine mislabelled or something like that? Or should I start to worry?

Thomas, I would not worry, just something weird.

Basically java is causing a "/anon_hugepage (deleted)" to be created and then mmapping it into memory as an executable blob.

We are working on a fix for the kernel to differentiate between binding to localhost 127.* networks from system networks.