Bug 1015795 - selinux policy blocks Juniper SecureLauncher applet (icedtea-web)
selinux policy blocks Juniper SecureLauncher applet (icedtea-web)
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-05 10:49 EDT by Thomas Meyer
Modified: 2013-10-24 13:39 EDT (History)
5 users (show)

See Also:
Fixed In Version: selinux-policy-3.12.1-74.9.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-14 02:59:39 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Thomas Meyer 2013-10-05 10:49:36 EDT
Description of problem:
SELinux seems to hinder the Juniper SecureLauncher applet from working correctly.

In "Enforcing" mode I see these exceptions in the juniper log file:

1.) Deletion of file failed.

java.io.IOException: Deletion of file [/home/thomas/.juniper_networks/tncc.jar] failed
        at SecureLauncherApplet.DeleteFileWithAuthorization(SecureLauncherApplet.java:1093)
        at SecureLauncherApplet.InstallTargetApp(SecureLauncherApplet.java:855)
        at SecureLauncherApplet.startTargetApp(SecureLauncherApplet.java:475)
        at SecureHCLauncher.doInstall(SecureHCLauncher.java:259)
        at SecureLauncherApplet.start(SecureLauncherApplet.java:226)
        at SecureHCLauncher.start(SecureHCLauncher.java:205)
        at sun.applet.AppletPanel.run(AppletPanel.java:476)
        at java.lang.Thread.run(Thread.java:724)

2.) Download and copy of stream/file fails:

java.io.FileNotFoundException: /home/thomas/.juniper_networks/tncc.jar (Keine Berechtigung)
        at java.io.FileOutputStream.open(Native Method)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:221)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:171)
        at FileUtil.copyFile(FileUtil.java:221)
        at FileUtil.copyFile(FileUtil.java:206)
        at SecureLauncherApplet.InstallTargetApp(SecureLauncherApplet.java:861)
        at SecureLauncherApplet.startTargetApp(SecureLauncherApplet.java:475)
        at SecureHCLauncher.doInstall(SecureHCLauncher.java:259)
        at SecureLauncherApplet.start(SecureLauncherApplet.java:226)
        at SecureHCLauncher.start(SecureHCLauncher.java:205)
        at sun.applet.AppletPanel.run(AppletPanel.java:476)
        at java.lang.Thread.run(Thread.java:724)

Afer switching to "Permissive" mode, the applet works correctly.

Version-Release number of selected component (if applicable):
selinux-policy.noarch 3.12.1-74.8.fc19

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 Daniel Walsh 2013-10-07 09:34:35 EDT
d1eaea31c12aa14021cb7719cb427f073a70af21 fixes this in git.
Comment 2 Lukas Vrabec 2013-10-07 10:42:07 EDT
back ported.
Comment 3 Fedora Update System 2013-10-08 16:47:37 EDT
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
Comment 4 Fedora Update System 2013-10-09 21:14:36 EDT
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).
Comment 5 Fedora Update System 2013-10-14 02:59:39 EDT
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.
Comment 6 Fedora Update System 2013-10-14 13:21:44 EDT
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.
Comment 7 Thomas Meyer 2013-10-14 15:26:40 EDT
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.
Comment 8 Miroslav Grepl 2013-10-21 12:09:57 EDT
Are you getting AVC msg?

Re-test and run

# ausearch -m avc -ts recent
Comment 9 Thomas Meyer 2013-10-21 13:40:12 EDT
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
Comment 10 Daniel Walsh 2013-10-22 13:38:11 EDT
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 } ;
Comment 11 Thomas Meyer 2013-10-23 17:15:52 EDT
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?
Comment 13 Daniel Walsh 2013-10-24 13:39:24 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.