Bug 1280526 - amanda using tar: fowner capability?
amanda using tar: fowner capability?
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
25
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Miroslav Grepl
Ben Levenson
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-11 19:52 EST by Uwe Menges
Modified: 2017-12-12 06:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-12-12 06:10:29 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Uwe Menges 2015-11-11 19:52:20 EST
Description of problem:
I can't do backup in enforcing mode, permissive works.
It gives these logs:

# sealert -l 728ce69c-1854-40d6-944f-fb3b83ace0d2
SELinux is preventing /usr/bin/tar from using the fowner capability.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that tar should have the fowner capability 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 tar /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


Additional Information:
Source Context                system_u:system_r:amanda_t:s0
Target Context                system_u:system_r:amanda_t:s0
Target Objects                Unknown [ capability ]
Source                        tar
Source Path                   /usr/bin/tar
Port                          <Unknown>
Host                          lima
Source RPM Packages           tar-1.28-6.fc22.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.13.1-128.18.fc22.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     lima
Platform                      Linux lima 4.2.3-200.fc22.x86_64 #1 SMP Thu Oct 8
                              03:23:55 UTC 2015 x86_64 x86_64
Alert Count                   3768
First Seen                    2015-10-05 23:46:13 CEST
Last Seen                     2015-11-10 05:45:32 CET
Local ID                      728ce69c-1854-40d6-944f-fb3b83ace0d2

Raw Audit Messages
type=AVC msg=audit(1447130732.38:97805): avc:  denied  { fowner } for  pid=5136 comm="tar" capability=3  scontext=system_u:system_r:amanda_t:s0 tcontext=system_u:system_r:amanda_t:s0 tclass=capability permissive=1


type=SYSCALL msg=audit(1447130732.38:97805): arch=x86_64 syscall=openat success=yes exit=ENXIO a0=5 a1=1e62de1 a2=e0900 a3=0 items=0 ppid=5135 pid=5136 auid=4294967295 uid=0 gid=6 euid=0 suid=0 fsuid=0 egid=6 sgid=6 fsgid=6 tty=(none) ses=4294967295 comm=tar exe=/usr/bin/tar subj=system_u:system_r:amanda_t:s0 key=(null)

Hash: tar,amanda_t,amanda_t,capability,fowner

Version-Release number of selected component (if applicable):
amanda-server-3.3.7p1-1.fc22.x86_64
amanda-libs-3.3.7p1-1.fc22.x86_64
amanda-3.3.7p1-1.fc22.x86_64
amanda-client-3.3.7p1-1.fc22.x86_64
tar-1.28-6.fc22.x86_64
selinux-policy-3.13.1-128.18.fc22.noarch
selinux-policy-targeted-3.13.1-128.18.fc22.noarch

How reproducible:
Always

Steps to Reproduce:
1. setenforce enforcing
2. run amdump 
3. see backup fail, logs have these:
Oct 10 21:49:10 lima audit[26677]: <audit-1400> avc:  denied  { fowner } for  pid=26677 comm="tar" capability=3  scontext=system_u:system_r:amanda_t:s0 tcontext=system_u:system_r:amanda_t:s0 tclass=capability permissive=0

Actual results:
I need to setenforce permissive before running amdump.

Expected results:
I can run amdump in enforcing mode.

Additional info:

I don't know if the entries are related to my dumptype configuration using amgtar plugin, but these are my config snippets:

define application-tool app_amgtar {
    plugin "amgtar"
    comment "amgtar with blocksize"
    property "TAR-BLOCKSIZE" "16384"
    property "GNUTAR-PATH" "/usr/local/bin/tar_nocache"
#   property append "ignore" "file changed as we read it$"
}
define dumptype uncompressed {
        comment "dump with app_amgtar"
        program "APPLICATION"
        application "app_amgtar"
        index on
        auth "bsdtcp"
        compress none
        estimate client
        exclude "/etc/amanda/uwe/exclude.gtar"
        priority medium
}

# cat /usr/local/bin/tar_nocache
#!/bin/sh
# https://github.com/Feh/nocache
exec nocache tar "$@"
Comment 1 Fedora End Of Life 2016-07-19 16:45:07 EDT
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.
Comment 2 Jason Tibbitts 2017-01-10 13:22:20 EST
I am pretty sure this is still an issue, so I'll reopen and set the version to F25..  I can't think of a good way to allow amanda to read every file on the filesystem besides modifying every single type to allow read by amanda_t (hopefully controlled by a boolean).  Doing that kind of thing is way beyond my comprehension.

Personally I use backup tools which don't require filesystem-level access (dump or xfsdump) but using xfsdump causes other selinux-related problems.  (I'm sure I filed a ticket about that at some point.)

My recommendation for something that doesn't turn off selinux entirely would be to set amanda_t as permissive:

# semanage permissive -a amanda_t
Comment 3 Fedora End Of Life 2017-12-12 06:10:29 EST
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 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.

Note You need to log in before you can comment on or make changes to this bug.