0

I start a bash script (synchronously from java as a glassfish user) which starts a command as another user (let's say myUser):

#!/bin/bash

echo myPassword | su -c "command" myUser &

When I start this script as glassfish user from a bash shell, the command is executed immediately. But when I start this script from java, the command is executed after 10-15 seconds.

It looks like a login security timeout?

I'm wondering if this is related to SELINUX? Here is the command line to start the java program (Glassfish):

/usr/share/glassfish3/glassfish/bin/asadmin start-domain

Here is the SELINUX status of the asadmin startup script:

$ ls -Z /usr/share/glassfish3/bin/asadmin
-rwxr-xr-x. glassfish glassfish unconfined_u:object_r:bin_t:s0  /usr/share/glassfish3/bin/asadmin

I'm running : - GNU bash, version 4.2.53(1)-release (x86_64-redhat-linux-gnu) on Centos 6.4 - java 1.6.45 X86_64 and Glassfish 3.1.2.2

UPDATE: In response to @larsks comment

SeLinux is in enforcing mode. The script produces the followings audit logs when executed from java:

BEFORE THE COMMAND

type=SERVICE_START msg=audit(1438862733.335:8932): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=' comm="fprintd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=USER_AVC msg=audit(1438862733.336:8933): pid=883 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  denied  { send_msg } for msgtype=method_return dest=:1.2520 spid=16027 tpid=16026 scontext=system_u:system_r:fprintd_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=dbus  exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'

HERE IS THE 10-15s WAIT

type=USER_AUTH msg=audit(1438862758.408:8934): pid=16026 uid=1001 auid=4294967295 ses=4294967295 subj=system_u:system_r:initrc_t:s0 msg='op=PAM:authentication acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=? res=success'
type=USER_ACCT msg=audit(1438862758.410:8935): pid=16026 uid=1001 auid=4294967295 ses=4294967295 subj=system_u:system_r:initrc_t:s0 msg='op=PAM:accounting acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=? res=success'
type=CRED_ACQ msg=audit(1438862758.411:8936): pid=16026 uid=1001 auid=4294967295 ses=4294967295 subj=system_u:system_r:initrc_t:s0 msg='op=PAM:setcred acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=? res=success'
type=USER_START msg=audit(1438862758.422:8937): pid=16026 uid=1001 auid=4294967295 ses=4294967295 subj=system_u:system_r:initrc_t:s0 msg='op=PAM:session_open acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=? res=success'
type=USER_END msg=audit(1438862758.429:8938): pid=16026 uid=1001 auid=4294967295 ses=4294967295 subj=system_u:system_r:initrc_t:s0 msg='op=PAM:session_close acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=? res=success'
type=CRED_DISP msg=audit(1438862758.429:8939): pid=16026 uid=1001 auid=4294967295 ses=4294967295 subj=system_u:system_r:initrc_t:s0 msg='op=PAM:setcred acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=? res=success'

NOW THE COMMAND HAS BEEN EXECUTED

The script produces the followings audit logs when executed from bash:

BEFORE THE COMMAND

type=SERVICE_START msg=audit(1438863622.854:9013): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=' comm="fprintd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=USER_AUTH msg=audit(1438863622.877:9014): pid=16215 uid=1001 auid=0 ses=1116 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=pts/1 res=success'
type=USER_ACCT msg=audit(1438863622.879:9015): pid=16215 uid=1001 auid=0 ses=1116 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=pts/1 res=success'
type=CRED_ACQ msg=audit(1438863622.879:9016): pid=16215 uid=1001 auid=0 ses=1116 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=pts/1 res=success'
type=USER_START msg=audit(1438863622.882:9017): pid=16215 uid=1001 auid=0 ses=1116 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=pts/1 res=success'
type=USER_END msg=audit(1438863622.888:9018): pid=16215 uid=1001 auid=0 ses=1116 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_close acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=pts/1 res=success'
type=CRED_DISP msg=audit(1438863622.888:9019): pid=16215 uid=1001 auid=0 ses=1116 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="administrator" exe="/usr/bin/su" hostname=? addr=? terminal=pts/1 res=success'

NOW THE COMMAND HAS BEEN EXECUTED
4
  • Is selinux in enforcing mode? Do you see any audit logs generated when running that command?
    – larsks
    Commented Aug 6, 2015 at 11:42
  • If I set selinux in permissive mode (via setenforce 0) the wait disappears, but it sounds like a dirty solution... Commented Aug 6, 2015 at 12:39
  • That's odd, because there aren't any selinux denials in the audit output you've shown. If there were, you could simply craft a local selinux policy that would permit those actions, but since we don't see those denials I'm not sure what's going on.
    – larsks
    Commented Aug 6, 2015 at 12:41
  • It looks there is one denial when executed from java type=USER_AVC msg=audit(1438862733.336:8933):.. msg='avc: denied ..., which is not there when executed from bash. So you're probably right. But I'm not sure what kind of action it correspond. Commented Aug 6, 2015 at 14:37

1 Answer 1

0

If you're getting an selinux AVC, you can set up a local policy to permit that particular action using the audit2allow tool:

# audit2allow -M local -a

This will create a policy (local.pp) that will permit anything that resulted in an selinux denial in your audit logs. You can then activate this module by running:

# semodule -i local.pp

You can see the source in the file local.te.

The AVC in your question will result in:

module local 1.0;

require {
    type fprintd_t;
    type initrc_t;
    class dbus send_msg;
}

#============= fprintd_t ==============
allow fprintd_t initrc_t:dbus send_msg;
2
  • Perfect! That works like a charm. Thanks a lot! Just one more precision, is there a "standart place" to store the local.te file? Commented Aug 7, 2015 at 7:45
  • I don't think so, no.
    – larsks
    Commented Aug 7, 2015 at 11:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .