Thank you everyone for your responses.  I have gotten it to work the solution is below.

 

Andy: no there is not an extra dot.

Martin: bacula-fd is running as root.  I will remove sudo configuration all together

Ben:  Thanks, seeing that the bacula-fd service is running as root I have removed the sudo all together.

 

With sudo removed was still receiving the same error. 

 

I tried to verify that the command is running as root with the following configuration.

RunScript {

    Command = "whoami"

    Command = "systemctl --v"

    Command = "systemctl stop gophish"

    RunsWhen = Before

    RunsOnClient = yes

  }

 

#-- RESULTS #1

bacula-dir JobId 109: Start Backup JobId 109, Job=D2D-MyService-Application.2017-04-28_11.36.09_40

bacula-dir JobId 109: Using Device "FileChgr1-Dev1" to write.

myservice-fd JobId 109: shell command: run ClientBeforeJob "whoami"

myservice-fd JobId 109: ClientBeforeJob: root

myservice-fd JobId 109: shell command: run ClientBeforeJob "systemctl --v"

myservice-fd JobId 109: Error: Runscript: ClientBeforeJob returned non-zero status=200. ERR=Permission denied

bacula-dir JobId 109: Fatal error: Bad response to RunBeforeNow command: wanted 2000 OK RunBeforeNow

, got 2905 Bad RunBeforeNow command.

bacula-dir JobId 109: Fatal error: Client " myservice -fd" RunScript failed.

 

As you can see just invoking the systemctl program is causing a Permission denied.  This led me to SELINUX.  I issued a quick “setenforce permissive” and everything worked.

 

#-- RESULTS 2

bacula-dir JobId 110: Start Backup JobId 110, Job=D2D-MyService-Application.2017-04-28_11.39.23_07

bacula-dir JobId 110: Using Device "FileChgr1-Dev1" to write.

MyService-fd JobId 110: shell command: run ClientBeforeJob "whoami"

MyService-fd JobId 110: ClientBeforeJob: root

MyService-fd JobId 110: shell command: run ClientBeforeJob "systemctl --v"

MyService-fd JobId 110: ClientBeforeJob: systemd 219

MyService-fd JobId 110: ClientBeforeJob: +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN

MyService-fd JobId 110: shell command: run ClientBeforeJob "systemctl stop MyService"

bacula-sd JobId 110: Labeled new Volume "MyService-fd-Daily-100-2017.4.28.bak" on file device "FileChgr1-Dev1" (/backup/bacula/filebackup01).

 

A check to my audit log pointed to

 

type=AVC msg=audit(1493397605.244:5305): avc:  denied  { execute_no_trans } for  pid=6266 comm="bacula-fd" path="/usr/bin/systemctl" dev="sda1" ino=33834873 scontext=system_u:system_r:bacula_t:s0 tcontext=system_u:object_r:systemd_systemctl_exec_t:s0 tclass=file

 

Audit2Allow steps resulted in:

(https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow.html)

 

#============= bacula_t ==============

 

#!!!! This avc is allowed in the current policy

allow bacula_t init_t:unix_stream_socket connectto;

 

#!!!! This avc is allowed in the current policy

allow bacula_t self:capability net_admin;

 

#!!!! This avc is allowed in the current policy

allow bacula_t system_dbusd_t:dbus send_msg;

 

#!!!! This avc is allowed in the current policy

allow bacula_t system_dbusd_t:unix_stream_socket connectto;

 

#!!!! This avc is allowed in the current policy

allow bacula_t systemd_systemctl_exec_t:file { execute execute_no_trans };

 

#!!!! This avc is allowed in the current policy

allow bacula_t systemd_unit_file_t:service { start status stop };

 

 

I went back to enforcing and my results are:

 

#-- RESULTS 3

bacula-dir JobId 114: Start Backup JobId 114, Job=D2D-MyService-Application.2017-04-28_12.40.18_05

bacula-dir JobId 114: Using Device "FileChgr1-Dev1" to write.

MyService-fd JobId 114: shell command: run ClientBeforeJob "whoami"

MyService-fd JobId 114: ClientBeforeJob: root

MyService-fd JobId 114: shell command: run ClientBeforeJob "systemctl --v"

MyService-fd JobId 114: ClientBeforeJob: systemd 219

MyService-fd JobId 114: ClientBeforeJob: +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN

MyService-fd JobId 114: shell command: run ClientBeforeJob "systemctl stop MyService"

bacula-sd JobId 114: Labeled new Volume "MyService-fd-Daily-111-2017.4.28.bak" on file device "FileChgr1-Dev1" (/backup/bacula/filebackup01).

bacula-sd JobId 114: Wrote label to prelabeled Volume "MyService-fd-Daily-111-2017.4.28.bak" on file device "FileChgr1-Dev1" (/backup/bacula/filebackup01)

bacula-dir JobId 114: Volume used once. Marking Volume "MyService-fd-Daily-111-2017.4.28.bak" as Used.

MyService-fd JobId 114: shell command: run ClientAfterJob "systemctl start MyService"

bacula-sd JobId 114: Elapsed time=00:00:16, Transfer rate=3.883 M Bytes/second

 

 

 

 

Hi Jim,

 

Note that sudo requires the command be executed from a TTY by default for security, which isn’t compatible with how system services run. Do you have a defaults entry for bacula that disables the “requiretty” option? Not having this would manifest as a permission denied as if the sudo rule hadn’t taken effect.

 

> Defaults:bacula !requiretty

 

Giving bacula full access to systemctl is also not consistent with the principles of least privilege, and potentially dangerous. You would be safer providing multiple sudo rules to start and stop just the services you need bacula to have control over.

 

This email and any files transmitted with it contain confidential and proprietary information and is solely for the use of the intended recipient. If you are not the intended recipient please return the email to the sender and delete it from your computer and you must not use, disclose, distribute, copy, print or rely on this email or its contents. This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. Any comments or statements made herein do not necessarily reflect those of GSA Capital. GSA Capital Partners LLP is authorised and regulated by the Financial Conduct Authority and is registered in England and Wales at Stratton House, 5 Stratton Street, London W1J 8LA, number OC309261. GSA Capital Services Limited is registered in England and Wales at the same address, number 5320529.