Red Hat Bugzilla – Bug 827854
SELinux prevents BackupPC from reading /etc/shadow
Last modified: 2014-03-12 13:26:58 EDT
Description of problem: SELinux is preventing /usr/bin/perl from open access on the file /etc/shadow. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that perl should be allowed open access on the shadow 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 WARNING: Policy would be downgraded from version 27 to 26. WARNING: Policy would be downgraded from version 27 to 26. Additional Information: Source Context system_u:system_r:httpd_t:s0 Target Context system_u:object_r:shadow_t:s0 Target Objects /etc/shadow [ file ] Source BackupPC_Admin. Source Path /usr/bin/perl Port <Unknown> Host clio.ellipsis.cx Source RPM Packages perl-5.14.2-211.fc17.x86_64 Target RPM Packages setup-2.8.48-1.fc17.noarch Policy RPM selinux-policy-3.10.0-125.fc17.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name clio.ellipsis.cx Platform Linux clio.ellipsis.cx 3.3.7-1.fc17.x86_64 #1 SMP Mon May 21 22:32:19 UTC 2012 x86_64 x86_64 Alert Count 21 First Seen Sat Jun 2 12:08:38 2012 Last Seen Sun Jun 3 12:04:56 2012 Local ID 856f1e50-4f23-47a5-a260-d1b6913e9442 Raw Audit Messages type=AVC msg=audit(1338717896.437:583): avc: denied { open } for pid=13521 comm="BackupPC_Admin." name="shadow" dev="dm-0" ino=41157886 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:shadow_t:s0 tclass=file type=SYSCALL msg=audit(1338717896.437:583): arch=x86_64 syscall=open success=no exit=EACCES a0=7f96d6c3d6eb a1=80000 a2=1b6 a3=238 items=0 ppid=13029 pid=13521 auid=4294967295 uid=48 gid=48 euid=498 suid=498 fsuid=498 egid=48 sgid=48 fsgid=48 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,shadow_t,file,open audit2allow #============= httpd_t ============== allow httpd_t shadow_t:file open; audit2allow -R #============= httpd_t ============== allow httpd_t shadow_t:file open; Version-Release number of selected component (if applicable): BackupPC-3.2.1-7.fc17.x86_64 selinux-policy-targeted-3.10.0-125.fc17.noarch
*** Bug 827853 has been marked as a duplicate of this bug. ***
*** Bug 827688 has been marked as a duplicate of this bug. ***
I think the BackupPC_Admin web interface should be started using a cgi script. Then there could be a transition to backuppc_confined_t domain.
As far as I know, BackupPC does not need access to /etc/shadow (access is controlled through httpd). If there is something that is specifically not working, please report it.
(In reply to comment #4) > As far as I know, BackupPC does not need access to /etc/shadow (access is > controlled through httpd). If there is something that is specifically not > working, please report it. Nonetheless, BackupPC *is* trying to get access to /etc/shadow, and SELinux is stopping it. Either BackupPC is doing something wrong, or the SELinux policy is doing something wrong. Which one is outside my wheelhouse.
These SELinux denials are still generated with BackupPC-3.2.1-11.fc18.x86_64 and selinux-policy-3.11.1-81.fc18.noarch. They completely prevent access to the BackupPC web interface.
This is something you will need to add via a local policy. This is not something I want to allow for apache. I don't even know how apache is able to read it via DAC rules.
Maybe the thing to do is modify BackupPC so it doesn't try reading /etc/shadow.
Created attachment 706781 [details] Patch for BackuPC to call getpwnam in scalar instead of list context
I've tracked down the offending function call in BackupPC: It's the call to getpwnam() on line 147 of /usr/share/BackupPC/lib/BackupPC/CGI/Lib.pm: # # Verify we are running as the correct user # if ( $Conf{BackupPCUserVerify} && $> != (my $uid = (getpwnam($Conf{BackupPCUser}))[2]) ) { ... } According to the perldoc, getpwnam returns this list: ($name,$passwd,$uid,$gid,$quota,$comment,$gcos,$dir,$shell,$expire) I guess it's element 1 of that list which causes getpwnam to try to read /etc/shadow. However, the perldoc also states that if you call getwpnam in a scalar context, then what's returned is just $uid. In this case, BackupPC is throwing away everything but $uid anyhow, so there's no point in calling getpwnam in a list context. Furthermore, calling getpwnam in a scalar context does not trigger the SELinux denial---presumably this is because in that case, getpwnam only reads /etc/passwd. So, the solution is very simple: Call getpwnam in a scalar context instead. I've attached a patch which fixes the two places BackupPC does this.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. 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 WONTFIX if it remains open with a Fedora 'version' of '18'. 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 prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 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 to Fedora 18's end of life. 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 is still not fixed in BackupPC-3.2.1-15.fc20.x86_64.
I will get a build out with this fix soon.
BackupPC-3.3.0-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/BackupPC-3.3.0-2.fc19
BackupPC-3.3.0-2.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/BackupPC-3.3.0-2.el6
BackupPC-3.3.0-2.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/BackupPC-3.3.0-2.el5
BackupPC-3.3.0-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/BackupPC-3.3.0-2.fc20
Package BackupPC-3.3.0-2.el6: * should fix your issue, * was pushed to the Fedora EPEL 6 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing BackupPC-3.3.0-2.el6' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0663/BackupPC-3.3.0-2.el6 then log in and leave karma (feedback).
BackupPC-3.3.0-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
BackupPC-3.3.0-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
BackupPC-3.3.0-2.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
BackupPC-3.3.0-2.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.