Description of problem: psad fails to start because the following error. [root@sovereign files]# systemctl status psad ● psad.service - SYSV: The Port Scan Attack Detector (psad) Loaded: loaded (/etc/rc.d/init.d/psad) Active: failed (Result: exit-code) since Mon 2014-12-15 16:03:56 CET; 12min ago Process: 20654 ExecStart=/etc/rc.d/init.d/psad start (code=exited, status=1/FAILURE) Dec 15 16:03:56 sovereign psad[20654]: Starting psad: [*] The config file "/etc/psad/psad.conf" does not contain the Dec 15 16:03:56 sovereign psad[20654]: variable: "EMAIL_ADDRESSES". Exiting! at /usr/sbin/psad line 10593. Dec 15 16:03:56 sovereign psad[20654]: [FAILED] Dec 15 16:03:56 sovereign systemd[1]: psad.service: control process exited, code=exited status=1 Dec 15 16:03:56 sovereign systemd[1]: Failed to start SYSV: The Port Scan Attack Detector (psad). Dec 15 16:03:56 sovereign systemd[1]: Unit psad.service entered failed state. Dec 15 16:03:56 sovereign systemd[1]: psad.service failed. Version-Release number of selected component (if applicable): [root@sovereign files]# rpm -qa psad psad-2.2.1-5.fc21.x86_64 How reproducible: with an SELinux enabled system, run: systemctl start psad Actual results: fails to start because it can't read/write the log file in /var/log/psad/psad.iptout Expected results: a clean start Additional info: # Audit.log [root@sovereign files]# grep AVC /var/log/audit/audit.log | grep psad type=AVC msg=audit(1418655683.029:442): avc: denied { write } for pid=20589 comm="sh" path="/var/log/psad/psad.iptout" dev="dm-0" ino=5246019 scontext=system_u:system_r:psad_t:s0 tcontext=system_u:object_r:psad_var_log_t:s0 tclass=file permissive=0 type=AVC msg=audit(1418655683.029:443): avc: denied { write } for pid=20589 comm="sh" name="psad.iptout" dev="dm-0" ino=5246019 scontext=system_u:system_r:psad_t:s0 tcontext=system_u:object_r:psad_var_log_t:s0 tclass=file permissive=0 type=AVC msg=audit(1418655683.030:444): avc: denied { read } for pid=20587 comm="psad" name="psad.iptout" dev="dm-0" ino=5246019 scontext=system_u:system_r:psad_t:s0 tcontext=system_u:object_r:psad_var_log_t:s0 tclass=file permissive=0 # file contexts of psad [root@sovereign files]# semanage fcontext -l | grep psad /etc/psad(/.*)? all files system_u:object_r:psad_etc_t:s0 /etc/rc\.d/init\.d/psad regular file system_u:object_r:psad_initrc_exec_t:s0 /usr/sbin/psad regular file system_u:object_r:psad_exec_t:s0 /var/lib/psad(/.*)? all files system_u:object_r:psad_var_lib_t:s0 /var/log/psad(/.*)? all files system_u:object_r:psad_var_log_t:s0 /var/run/psad(/.*)? all files system_u:object_r:psad_var_run_t:s0 # applied file contexts on the folder [root@sovereign files]# ls -Z /var/log/* | grep psad /var/log/psad: -rw-------. root root system_u:object_r:psad_var_log_t:s0 fwdata -rw-------. root root system_u:object_r:psad_var_log_t:s0 psad.iptout # sestatus [root@sovereign contexts]# sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 29 # FIX A possible fix would be to add read/write permission to the type: psad_var_log_t
The systemctl error was an old one I copied, below is the recent error. ● psad.service - SYSV: The Port Scan Attack Detector (psad) Loaded: loaded (/etc/rc.d/init.d/psad) Active: failed (Result: exit-code) since Mon 2014-12-15 16:44:57 CET; 5s ago Process: 21226 ExecStart=/etc/rc.d/init.d/psad start (code=exited, status=1/FAILURE) Dec 15 16:44:57 sovereign psad[21226]: Starting psad: sh: /var/log/psad/psad.iptout: Permission denied Dec 15 16:44:57 sovereign psad[21226]: [*] Could not open /var/log/psad/psad.iptout at /usr/sbin/psad line 7025. Dec 15 16:44:57 sovereign psad[21226]: [FAILED] Dec 15 16:44:57 sovereign systemd[1]: psad.service: control process exited, code=exited status=1 Dec 15 16:44:57 sovereign systemd[1]: Failed to start SYSV: The Port Scan Attack Detector (psad). Dec 15 16:44:57 sovereign systemd[1]: Unit psad.service entered failed state. Dec 15 16:44:57 sovereign systemd[1]: psad.service failed.
This problem still persists in Fedora 22... [root@defiant /]# cat /etc/redhat-release Fedora release 22 (Twenty Two) [root@defiant /]# sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 29 Please fix this. PSAD doesn't work by default after the installation is complete and `systemctl start psad` is ran with SELinux in enforcing mode.
I can confirm this bug. It exists at least since Fedora 20. To fix it, please follow these steps: 1. dnf install selinux-policy-devel libselinux-utils 2. mkdir -p ~/psad-log-access-selinux && cd ~/psad-log-access-selinux || echo "Can not create directory \"~/psad-log-access-selinux\"!" 3. touch psad_log_access.fc 4. touch psad_log_access.if 5. test ! -f ./psad_log_access.te && echo -e -n "policy_module(psad_log_access, 1.0)\n\nrequire {\n\ttype psad_var_log_t;\n\ttype psad_t;}\n\nmanage_files_pattern(psad_t,psad_var_log_t,psad_var_log_t)\nmanage_lnk_files_pattern(psad_t,psad_var_log_t,psad_var_log_t)\n" > ./psad_log_access.te 6. make -f /usr/share/selinux/devel/Makefile 7. semodule -i psad_log_access.pp 8. semodule -R 9. systemctl restart psad.service Hope, this helps.
Thanks! But are there also plans to incorporate a fix in an upcoming selinux-policy release? PSAD is a neat security feature, it would be a waste if it doesn't work by default in Fedora with SELinux enabled.
I don't know. I'm not a member selinux development team ;-), but I think this bug should be fixed, too. Fortunately psad is a part of Fedora 2x. Hence it should run out of the box IMHO. Until the bug is fixed in the selinux policy, we have to use a custom selinux module like the one if have posted.
Would be nice to have this finally working for Fedora 23. All the debug information is provided to create a new SELinux rule. Do you need any help?
reassigning to Lukas. Lukas, could you incorporate provided module into the policy? Is there a better way to start providing custom policy module(using CIL and prioritization)?
(In reply to Peter Vrabec from comment #7) > reassigning to Lukas. > > Lukas, could you incorporate provided module into the policy? Is there a > better way to start providing custom policy module(using CIL and > prioritization)? It never got fixed for Fedora 23, any chance it will be fixed for Fedora 24?
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
(In reply to Fedora End Of Life from comment #9) > Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is > no longer maintained, which means that it will not receive any further > security or bug fix updates. As a result we are closing this bug. > > If you can reproduce this bug against a currently maintained version of > Fedora please feel free to reopen this bug against that version. If you > are unable to reopen this bug, please file a new report against the > current release. If you experience problems, please add a comment to this > bug. > > Thank you for reporting this bug and we are sorry it could not be fixed. Really? I just pointed out it's still present in F24. This bug won't get fixed by itself. I already sent you all the information you need to create a new SELinux rule 2 years ago. If you need help then please reach out to me or to other people. Your package has been broken for 2 years already.
SELinux is preventing psad from read access on the file /var/log/psad/psad.iptout. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that psad should be allowed read access on the psad.iptout file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'psad' --raw | audit2allow -M my-psad # semodule -X 300 -i my-psad.pp Additional Information: Source Context system_u:system_r:psad_t:s0-s0:c0.c1023 Target Context system_u:object_r:psad_var_log_t:s0 Target Objects /var/log/psad/psad.iptout [ file ] Source psad Source Path psad Port <Unknown> Host defiant Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-191.8.fc24.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name defiant Platform Linux defiant 4.6.4-301.fc24.x86_64 #1 SMP Tue Jul 12 11:50:00 UTC 2016 x86_64 x86_64 Alert Count 1 First Seen 2016-08-09 09:11:01 CEST Last Seen 2016-08-09 09:11:01 CEST Local ID b151dac5-9b89-4496-a7a6-596998315a47 Raw Audit Messages type=AVC msg=audit(1470726661.591:286): avc: denied { read } for pid=2954 comm="psad" name="psad.iptout" dev="dm-2" ino=3014756 scontext=system_u:system_r:psad_t:s0-s0:c0.c1023 tcontext=system_u:object_r:psad_var_log_t:s0 tclass=file permissive=0 Hash: psad,psad_t,psad_var_log_t,file,read
The complete list of denials is: type=AVC msg=audit(1475881793.305:6188): avc: denied { write } for pid=2483 comm="sh" name="psad_iptout.wmY9JM" dev="dm-1" ino=1311115 scontext=system_u:system_r:psad_t:s0 tcontext=system_u:object_r:psad_var_log_t:s0 tclass=file permissive=0 type=AVC msg=audit(1475881793.306:6189): avc: denied { read } for pid=2480 comm="psad" name="psad_iptout.wmY9JM" dev="dm-1" ino=1311115 scontext=system_u:system_r:psad_t:s0 tcontext=system_u:object_r:psad_var_log_t:s0 tclass=file permissive=0 type=AVC msg=audit(1475882541.307:6452): avc: denied { unlink } for pid=5116 comm="psad" name="psad_iptout.bMdyna" dev="dm-1" ino=1314279 scontext=system_u:system_r:psad_t:s0 tcontext=system_u:object_r:psad_var_log_t:s0 tclass=file permissive=0 type=AVC msg=audit(1475882541.683:6460): avc: denied { rename } for pid=5149 comm="psad" name="top_ports.tmp" dev="dm-1" ino=1314302 scontext=system_u:system_r:psad_t:s0 tcontext=system_u:object_r:psad_var_log_t:s0 tclass=file permissive=0 So, the actions that need to be allowed are: allow psad_t psad_var_log_t:file { read rename unlink write }; Please note that this is preventing psad from starting successfully and I'd like to get this fixed for the unretired package (bug 1382875).
Miroslav, is there any chance of getting this included in the next selinux-policy update?
Dan?
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Bumping up to rawhide.
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
(In reply to Jan Kurik from comment #17) > This bug appears to have been reported against 'rawhide' during the Fedora > 27 development cycle. > Changing version to '27'. This bug has been present since F21 (as far as I know) and hasn't been fixed since. Is more information required? The PSAD version in use is also quite old and the maintainer isn't very responsive either. I'll bump the request to update the package as well, maybe different behavior is triggered with the new version.
Restoring the 'needinfo' flag, I thought it was set for another question.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug as been solved by the maintainer. However, /var/log/audit/audit.log is flooded with many SELinux errors per second ever since. Below is the most common one. I will create a new bug report for that soon (if none exists). type=AVC msg=audit(1543348221.615:31844): avc: denied { sys_ptrace } for pid=30873 comm="ps" capability=19 scontext=system_u:system_r:psad_t:s0 tcontext=system_u:system_r:psad_t:s0 tclass=cap_userns permissive=0
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days