8

In my playbook, i have a task to update audit.rules and then notify a handler which should restart the auditd service.

task:
  - name:  6.6.7 - audit rules configuration
    template: src=X/ansible/templates/auditd_rules.j2
              dest=/etc/audit/rules.d/audit.rules
              backup=yes
              owner=root group=root mode=0640
     notify:
   - restart auditd


  handlers:
    - name: restart auditd
      service: name=auditd state=restarted

When the playbook runs, the audit rules are updated and a request is made to restart auditd but this fails as below.

RUNNING HANDLER [restart auditd] ***********************************************
fatal: [ipX-southeast-2.compute.internal]: FAILED! => {"changed": false, "failed": true, "msg": "Unable to restart service auditd: Failed to restart auditd.service: Operation refused, unit auditd.service may be requested by dependency only.\n"}

When i look at the unit definition for auditd, i can see refuseManualStop=yes. Is this why i cant restart the service? how does one over come this to pickup the new audit rules?

 systemctl cat auditd.service
# /usr/lib/systemd/system/auditd.service
[Unit]
Description=Security Auditing Service
DefaultDependencies=no
After=local-fs.target systemd-tmpfiles-setup.service
Conflicts=shutdown.target
Before=sysinit.target shutdown.target
RefuseManualStop=yes
ConditionKernelCommandLine=!audit=0
Documentation=man:auditd(8) https://people.redhat.com/sgrubb/audit/

[Service]
ExecStart=/sbin/auditd -n
## To not use augenrules, copy this file to /etc/systemd/system/auditd.service
## and comment/delete the next line and uncomment the auditctl line.
## NOTE: augenrules expect any rules to be added to /etc/audit/rules.d/
ExecStartPost=-/sbin/augenrules --load
#ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules
ExecReload=/bin/kill -HUP $MAINPID
# By default we don't clear the rules on exit. To enable this, uncomment
# the next line after copying the file to /etc/systemd/system/auditd.service
#ExecStopPost=/sbin/auditctl -R /etc/audit/audit-stop.rules

[Install]
WantedBy=multi-user.target
Matzuba
  • 333
  • 2
  • 4
  • 8
  • Change the manual stop to NO and try `sudo service auditd restart` If this works, then the code will also work. – Ranadip Dutta Dec 09 '16 at 04:54
  • `systemctl start auditd` and `systemctl enable auditd` is for version CentOS version7. Follow the link for further help. [link](https://skcave.wordpress.com/2014/11/07/using-audit-on-centos-7/) – Ranadip Dutta Dec 09 '16 at 04:57
  • There goes one more nice documentation. [AuditD in CentOS7](https://www.digitalocean.com/community/tutorials/how-to-write-custom-system-audit-rules-on-centos-7)..Hope it Helps you. – Ranadip Dutta Dec 09 '16 at 04:59
  • 1
    thanks. I didn't really want to mess with the OS side as they must have implemented for a reason. I would also need to change this on every host. it seems standard service commands can call systemctl which works for sudo service auditd restart Stopping logging: [ OK ] Redirecting start to /bin/systemctl start auditd.service sudo service auditd stop `code` Stopping logging: [ OK ] sudo service auditd start Redirecting to /bin/systemctl start auditd.service – Matzuba Dec 09 '16 at 05:00
  • 1
    thanks for the pointers, looks like the offical way to restart audit with RHEL7 is to use the standard service command. The service command is the only way to correctly interact with the auditd daemon. You need to use the service command so that the auid value is properly recorded. You can use the systemctl command only for two actions: enable and status. changed my handler to call the command module instead and this now works `handlers: - name: restart auditd command: service auditd restart` – Matzuba Dec 09 '16 at 05:14
  • Yes. I second you on this restart part. Accept the answer if it helps you. I will paste it as Answer. :) – Ranadip Dutta Dec 09 '16 at 05:27
  • `state=reloaded` is not enough? – techraf Dec 09 '16 at 08:03
  • Good point but i dont think this works from my testing. auditd man page states that reload reloads the auditd.conf file. When i reload, this does not update the rules config, when i restart the config is updated. thanks for the suggestion thou. – Matzuba Dec 12 '16 at 07:12
  • This question really shouldn't be about Ansible. That just adds a layer of obfuscation without really adding much value. It is strictly an OS issue (or rather, an auditd issue). Once it is resolved at the OS level, the solution within Ansible follows automatically. – Kevin Keane Jun 04 '21 at 16:23
  • This question promoted discussion and collaboration. This was an initial investigation into the issue and through this, it came to light that others have asked similar questions and links/discssions were provided about issues at the OS level. All investigation start someone, see no issue with this. – Matzuba Jun 07 '21 at 13:33
  • Does this answer your question? [Restarting auditd service gives dependency error](https://stackoverflow.com/questions/61183536/restarting-auditd-service-gives-dependency-error) – smac89 Aug 31 '22 at 01:49

5 Answers5

13

This has been explored, discussed, and resolved (mostly) in the Red Hat Bugzilla #1026648 and Anisble Issue # 22171 (github) reports.

Resolution

  • Use the ansible service module parameter use=service to force execution of the /sbin/service utility instead of the gathered-fact value of systemd (which invokes /sbin/systemctl) like this:
    • - service: name=auditd state=restarted use=service
  • Example playbook (pastebin.com)

Workaround:

  • Use the ansible command module to explicitly run the service executable like this:
    • - command: /sbin/service auditd restart

Analysis - root cause:

  • This is an issue created by upstream packaging of auditd.service unit. It will not start/stop/restart when acted upon by systemctl, apparently by design.
  • It is further compounded by the Ansible service control function, which uses the preferred method identified when system facts are gathered and "ansible_service_mgr" returns "systemd". This is regardless of the actual module used to manage the service.unit.
  • RHEL dev team may fix if considered a problem in upcoming updates (ERRATA)
  • Ansible dev team has offered a workaround and (as of 2.2) updated the service module with the use parameter.
0xSheepdog
  • 245
  • 3
  • 10
  • 2
    It seems that the `use` parameter doesn't work. The ansible reports that the restart task ran, but `systemctl status auditd` shows that the service wasn't restarted. This is with ansible 2.7 on CentOS 7.6. – orodbhen Apr 12 '19 at 15:46
  • 1
    @orodbhen Not surprising. The pace of change with Ansible means often that something we know works one month may be out-dated just a few minor versions later. – 0xSheepdog Jul 01 '19 at 14:24
  • 1
    This is in fact pretty much the official RedHat-endorsed solution. https://access.redhat.com/solutions/2664811 (RH account required for the link) : stop the service with /bin/service, then start it with systemctl. – Kevin Keane Jun 04 '21 at 16:19
  • It seems that the issue pointed out by @orodbhen can be resolved by using the command workaround rather than `use`. – DustWolf Mar 06 '23 at 09:42
  • Reported bug: https://github.com/ansible/ansible/issues/80142 – DustWolf Mar 06 '23 at 10:12
3

Maybe is quit late for the answer, but if anyone else is facing the same problem, you can import the new rules for auditd with this command :

auditctl -R /path/to_your_rules_file

So, no need to restart auditd.service to import new rules

g00glen00b
  • 41,995
  • 13
  • 95
  • 133
Abel
  • 151
  • 4
  • I've removed your question from your answer. The answer can certainly stay, but for questions you have to [ask a new question](https://stackoverflow.com/questions/ask). See: [Ask questions, get answers, no distractions](https://stackoverflow.com/tour). – g00glen00b Sep 14 '17 at 07:30
  • 1
    No problem, I've posted my question here https://stackoverflow.com/questions/46214714/overwritten-auditd-rules-in-pci-dss-environement – Abel Sep 14 '17 at 09:06
2

I would validate the auditd service reloading correctly as even using the command module with the command you specified will not work or behave in the manner you would expect it to;

Confirm via

service auditd status

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-starting_the_audit_service.html

Try instead

service auditd condrestart

:)

  • Hi, thanks for your input. This is working fine with the command i posted. The rules are loaded after a normal restart – Matzuba Mar 27 '17 at 23:54
1

You should not change the parameter refuseManualStop, it's there to keep you system secure. What you could do instead, after creating new rules, reboot the host, wait for it, then continue with you playbook.

Playbook example:

- name: Create new rules file
  copy:
    src: 01-personalized.rules
    dest: /etc/audit/rules.d/01-personalized.rules
    owner: root
    group: root
    mode: 0600
  register: result

- name: Reboot server
  shell: "sleep 5 && reboot"
  async: 1
  poll: 0
  when: result is changed

- name: Wait for server to become available
  wait_for_connection:
    delay: 60
    sleep: 5
    timeout: 300
  when: result is changed
  • 1
    RedHat explains the rationale here (behind a login wall): https://access.redhat.com/solutions/2664811 . The auditd maintainers did it because the kernel treats auditd specially. If you send a kill signal to auditd, it first sends the credentials of the process that sent the kill signal to auditd for logging, but with systemd, that is always PID 1. They didn't want that logged (probably because it would be confusing), so they prevented systemd from restarting auditd. – Kevin Keane Jun 04 '21 at 16:05
-4

Change the manual stop to NO and try

sudo service auditd restart

If this works, then the code will also work

systemctl start auditd

and

systemctl enable auditd

is for version CentOS version7. Follow the links for further help.

Link

Auditd in CentOS7

Ranadip Dutta
  • 8,857
  • 3
  • 29
  • 45
  • 1
    Changing the distribution baseline security controls on the audit system is probably not the best option for production systems. This may indeed resolve the problem, but its a bit of a kluge that may create vulnerabilities in the security posture of the system. – 0xSheepdog Nov 22 '17 at 19:07
  • @0xSheepdog: Well, even the OP is aware of it and that's why the answer been accepted. If vulnerability is a concern, then that should be raised by OP, isnt it ? Also, mitigation of enabling auditd vulnerabilities can be further taken care too. – Ranadip Dutta Jul 18 '19 at 08:17