3

I have a script executed by a Java app with testmod_t context. This script does

chage -M -1 user 

to set a user to no expiry. However, when SELinux is enforcing, the command does not seem to do anything and the following appears in the audit log.

type=USER_MGMT msg=audit(1719390859.006:1359): pid=4342 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:testmod_t:s0 msg='op=change-age acct="" exe="/usr/bin/chage" hostname=? addr=? terminal=? res=failed'UID="root" AUID="unset" 

When SELinux is permissive, the chage command does work correctly and the following appears in the audit log:

type=USER_MGMT msg=audit(1719219933.759:2056): pid=8851 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:testmod_t:s0 msg='op=change-max-age id=1018 exe="/usr/bin/chage" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset" ID="user" 

There is no "denied" message in the audit log.

When I tried

cat /var/log/audit/audit.log | audit2allow -M testmod 

it also prints "nothing to do".

Is there anything else I could do to find out why is SELinux affecting my script?

1 Answer 1

1

If you think SELinux is blocking something, but you see no denial in the audit log, it may be because of silent denials. These denials take place, but aren't audited because a rules exists that explicitly disables auditing. This rule is called dontaudit.

From the RHEL SELinux docs:

Applications and system library functions often probe for more access than required to perform their tasks. To maintain least privilege without filling audit logs with AVC denials for harmless application probing, the policy can silence AVC denials without allowing a permission by using dontaudit rules. These rules are common in standard policy. The downside of dontaudit is that, although SELinux denies access, denial messages are not logged, making troubleshooting more difficult.

To rebuild the SELinux policy ignoring all dontaudit-rules, run semodule -DB. The -D option disables dontaudit rules; the -B option rebuilds policy.

Then try if you can trigger an audit log event. If so, fix it, and then re-enable dontaudit rules by running: semodule -B.

For a full list of dontaudit rules, run the sesearch --dontaudit command. Narrow down searches using the -s domain option and the grep command. For example:

» sesearch --dontaudit -s smbd_t | grep squid dontaudit smbd_t squid_port_t : tcp_socket name_bind ; dontaudit smbd_t squid_port_t : udp_socket name_bind ; 
1
  • 1
    I have tried "semodule -DB" first and run the same script, sadly there isn't any new log that helps but this still give me more insight. Thanks for providing such detailed answer. Commented Oct 24, 2024 at 10:30

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.