Description of problem: BackupPC generates and SELinux denial when accessing the logs from the cgi interface. SELinux is preventing /usr/bin/perl from read access on the file /var/log/BackupPC/LOG. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that perl should be allowed read access on the LOG 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: # grep BackupPC_Admin. /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:httpd_t:s0 Target Context system_u:object_r:var_log_t:s0 Target Objects /var/log/BackupPC/LOG [ file ] Source BackupPC_Admin. Source Path /usr/bin/perl Port <Unknown> Host hobbes.localdomain Source RPM Packages perl-5.12.4-160.fc15 Target RPM Packages Policy RPM selinux-policy-3.9.16-35.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name hobbes.localdomain Platform Linux hobbes.localdomain 2.6.40-4.fc15.x86_64 #1 SMP Fri Jul 29 18:46:53 UTC 2011 x86_64 x86_64 Alert Count 1 First Seen Sun 14 Aug 2011 07:56:07 PM CDT Last Seen Sun 14 Aug 2011 07:56:07 PM CDT Local ID 2e6c75fa-7d5b-4d1f-ba0e-090631c18bc3 Raw Audit Messages type=AVC msg=audit(1313369767.589:820): avc: denied { read } for pid=4272 comm="BackupPC_Admin." name="LOG" dev=dm-3 ino=11010082 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file type=AVC msg=audit(1313369767.589:820): avc: denied { open } for pid=4272 comm="BackupPC_Admin." name="LOG" dev=dm-3 ino=11010082 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file type=SYSCALL msg=audit(1313369767.589:820): arch=x86_64 syscall=open success=yes exit=ESRCH a0=2118610 a1=0 a2=1b6 a3=7fe11b306e30 items=0 ppid=15379 pid=4272 auid=4294967295 uid=48 gid=489 euid=489 suid=489 fsuid=489 egid=489 sgid=489 fsgid=489 tty=(none) ses=4294967295 comm=BackupPC_Admin. exe=/usr/bin/perl subj=system_u:system_r:httpd_t:s0 key=(null) Hash: BackupPC_Admin.,httpd_t,var_log_t,file,read audit2allow #============= httpd_t ============== allow httpd_t var_log_t:file { read open }; audit2allow -R #============= httpd_t ============== allow httpd_t var_log_t:file { read open }; Instead of following the default directions for audit2allow which greps through the entire log, I only pulled the last (and appropriate) entry. Audit2allow then gives: """ module backuppc 1.0; require { type var_log_t; type httpd_t; class file open; } #============= httpd_t ============== allow httpd_t var_log_t:file open; """ See the email conversation with Daniel Walsh below. Although the above will fix the alert he's concerned it's too generic and allows BackupPC/httpd to much access to /var/log. Version-Release number of selected component (if applicable): BackupPC-3.2.1-2.fc15.x86_64 How reproducible: Steps to Reproduce: 1. Click the logs link from the CGI interface. 2. 3. Actual results: SELinux denial/alert is generated. Expected results: Access to logs is allowed. Additional info: From an email conversation with Daniel Walsh: On 08/14/2011 09:12 PM, Richard Shaw wrote: > Daniel, > > I figured out (at least to some extent) what was going on. The SEAlert > app has your grep through the entire log for the app that caused the > alert, in this case BackupPC_Admin. However, it doesn't filter by date > so it picks up every occurrence and pipes it to audit2allow, which in > retrospect, seems a bit dangerous. > > Limiting the data that's piped to audit2allow now produces this: > """ > module backuppc 1.0; > > require { > type var_log_t; > type httpd_t; > class file open; > } > > #============= httpd_t ============== > allow httpd_t var_log_t:file open; > """ > > Which does not include allowing access to a socket in > /var/log/BackupPC. I'm not sure why it ever looked there. This selinux > access is needed for the cgi interface to access the logs. I've added > this to the currently open bug[1] although I guess I should have > started a new one, oh well. > > HTH, > Richard > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=730053 Ok well we dont want to allow apache to share/read generic log files, /var/log/messages for example. This means you need to either label this log file with something apache can read like httpd_log_t. Or add a local customization.
I think backuppc does it's own log rotation so there are several files in /var/log/BackupPC. Is there an appropriate label that we could apply to the /var/log/BackupPC directory and all of its contents?
Any progress made on this so far? Thanks, Richard
Do you think this would do the trick? diff --git a/BackupPC.spec b/BackupPC.spec index 94ee0cd..39aa2b6 100644 --- a/BackupPC.spec +++ b/BackupPC.spec @@ -103,7 +103,7 @@ cp %{SOURCE4} BackupPC_Admin.c pushd selinux cat >%{name}.te <<EOF -policy_module(%{name},0.0.3) +policy_module(%{name},0.0.4) require { type var_log_t; type httpd_t; @@ -116,6 +116,8 @@ require { class file getattr; type var_run_t; class sock_file getattr; + type httpd_log_t; + class file open; } allow httpd_t var_run_t:sock_file write; @@ -124,11 +126,13 @@ allow httpd_t ping_exec_t:file getattr; allow httpd_t sendmail_exec_t:file getattr; allow httpd_t ssh_exec_t:file getattr; allow httpd_t var_run_t:sock_file getattr; +allow httpd_t httpd_log_t:file open; EOF cat >%{name}.fc <<EOF %{_sysconfdir}/%{name}(/.*)? gen_context(system_u:object_r:httpd_sys_script_rw_t,s0) %{_localstatedir}/run/%{name}(/.*)? gen_context(system_u:object_r:var_run_t,s0) +%{_localstatedir}/log/%{name}(/.*)? gen_context(system_u:object_r:httpd_log_t,s0) EOF popd %endif
I'm no SELinux expert but it looks good to me. If you make an SRPM or F15 scratch build I'll be happy to test it. Thanks, Richard
Try this: http://koji.fedoraproject.org/koji/taskinfo?taskID=3364547
I'm still getting the following on package cleanup: Non-fatal POSTUN scriptlet failure in rpm package BackupPC But this time it didn't reference the scriptlet name... Other than that I think it worked. I tried to cause an sealert but since I'm at work I had to do it over an SSH tunnel so I can't checked the sealert applet until I get home. I looked the /var/log/audit/audit.log and didn't see anything "new" but it doesn't seem to be designed for human readability so I couldn't find anything that yelled "timestamp" but I did check the PIDs and what was in there doesn't match the PIDs of the current processes.
(In reply to comment #6) > I'm still getting the following on package cleanup: > > Non-fatal POSTUN scriptlet failure in rpm package BackupPC > > But this time it didn't reference the scriptlet name... > You're probably seeing bug 736946. The bug is in %postun, so even though it's fixed in this new build, you'll get the error upgrading due to running the old %postun on update. > Other than that I think it worked. I tried to cause an sealert but since I'm at > work I had to do it over an SSH tunnel so I can't checked the sealert applet > until I get home. I looked the /var/log/audit/audit.log and didn't see anything > "new" but it doesn't seem to be designed for human readability so I couldn't > find anything that yelled "timestamp" but I did check the PIDs and what was in > there doesn't match the PIDs of the current processes. Ok, I will push the change to updates-testing in a day or so.
I think we're getting closer... I didn't seem to get an error when view the log file but when I clicked on "Email Summary" I got this: SELinux is preventing /usr/bin/perl from read access on the directory /var/log/BackupPC. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that perl should be allowed read access on the BackupPC directory 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: # grep BackupPC_Admin. /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:httpd_t:s0 Target Context system_u:object_r:httpd_log_t:s0 Target Objects /var/log/BackupPC [ dir ] Source BackupPC_Admin. Source Path /usr/bin/perl Port <Unknown> Host hobbes.localdomain Source RPM Packages perl-5.12.4-160.fc15 Target RPM Packages BackupPC-3.2.1-6.fc15 Policy RPM selinux-policy-3.9.16-38.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name hobbes.localdomain Platform Linux hobbes.localdomain 2.6.40.4-5.fc15.x86_64 #1 SMP Tue Aug 30 14:38:32 UTC 2011 x86_64 x86_64 Alert Count 1 First Seen Tue 20 Sep 2011 06:45:37 PM CDT Last Seen Tue 20 Sep 2011 06:45:37 PM CDT Local ID 6c452b22-711d-4257-a558-f526469e777b Raw Audit Messages type=AVC msg=audit(1316562337.727:1331): avc: denied { read } for pid=23197 comm="BackupPC_Admin." name="BackupPC" dev=dm-3 ino=11010114 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:httpd_log_t:s0 tclass=dir type=SYSCALL msg=audit(1316562337.727:1331): arch=x86_64 syscall=open success=yes exit=ESRCH a0=c51220 a1=90800 a2=0 a3=7fff81551200 items=0 ppid=12149 pid=23197 auid=4294967295 uid=48 gid=489 euid=489 suid=489 fsuid=489 egid=489 sgid=489 fsgid=489 tty=(none) ses=4294967295 comm=BackupPC_Admin. exe=/usr/bin/perl subj=system_u:system_r:httpd_t:s0 key=(null) Hash: BackupPC_Admin.,httpd_t,httpd_log_t,dir,read audit2allow #============= httpd_t ============== allow httpd_t httpd_log_t:dir read; audit2allow -R #============= httpd_t ============== allow httpd_t httpd_log_t:dir read;
Comparing the suggested audit2allow fix and your proposed fix: module mypol 1.0; require { type httpd_log_t; type httpd_t; class dir read; } #============= httpd_t ============== allow httpd_t httpd_log_t:dir read; The only difference I see is you're applying a "file open" class and it's suggesting a "dir read" class. Perhaps perl is just trying to stat the whole directory? We may have to allow that. Richard
See if this one works a little better: http://koji.fedoraproject.org/koji/taskinfo?taskID=3369762
BackupPC-3.2.1-6.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/BackupPC-3.2.1-6.fc16
BackupPC-3.2.1-6.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/BackupPC-3.2.1-6.fc15
BackupPC-3.2.1-6.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/BackupPC-3.2.1-6.fc14
BackupPC-3.2.1-6.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/BackupPC-3.2.1-6.el6
BackupPC-3.2.1-6.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/BackupPC-3.2.1-6.el5
(In reply to comment #10) > See if this one works a little better: > http://koji.fedoraproject.org/koji/taskinfo?taskID=3369762 That did it! Thanks, Richard
Package BackupPC-3.2.1-6.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing BackupPC-3.2.1-6.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/BackupPC-3.2.1-6.fc16 then log in and leave karma (feedback).
BackupPC-3.2.1-6.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
BackupPC-3.2.1-6.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
BackupPC-3.2.1-6.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
BackupPC-3.2.1-6.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
BackupPC-3.2.1-6.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.