Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 889705 - SELinux is preventing /usr/bin/mandb from using the 'dac_override' capabilities.
Summary: SELinux is preventing /usr/bin/mandb from using the 'dac_override' capabilities.
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 18
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:559cb28c9e30caccd2f1579b970...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-12-22 19:20 UTC by Colin J Thomson
Modified: 2015-06-01 09:09 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-01-07 09:34:22 UTC
Type: ---


Attachments (Terms of Use)

Description Colin J Thomson 2012-12-22 19:20:18 UTC
Description of problem:
SELinux is preventing /usr/bin/mandb from using the 'dac_override' capabilities.

*****  Plugin dac_override (91.4 confidence) suggests  ***********************

If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system
Then turn on full auditing to get path information about the offending file and generate the error again.
Do

Turn on full auditing
# auditctl -w /etc/shadow -p w
Try to recreate AVC. Then execute
# ausearch -m avc -ts recent
If you see PATH record check ownership/permissions on file, and fix it, 
otherwise report as a bugzilla.

*****  Plugin catchall (9.59 confidence) suggests  ***************************

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

Additional Information:
Source Context                system_u:system_r:mandb_t:s0-s0:c0.c1023
Target Context                system_u:system_r:mandb_t:s0-s0:c0.c1023
Target Objects                 [ capability ]
Source                        mandb
Source Path                   /usr/bin/mandb
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           man-db-2.6.3-2.fc18.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.11.1-67.fc18.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 3.6.11-3.fc18.x86_64 #1 SMP Mon
                              Dec 17 21:35:39 UTC 2012 x86_64 x86_64
Alert Count                   1
First Seen                    2012-12-22 19:05:08 GMT
Last Seen                     2012-12-22 19:05:08 GMT
Local ID                      ee66a8af-e1d8-49d9-bee4-0ff40a1a2b0d

Raw Audit Messages
type=AVC msg=audit(1356203108.49:313): avc:  denied  { dac_override } for  pid=4768 comm="mandb" capability=1  scontext=system_u:system_r:mandb_t:s0-s0:c0.c1023 tcontext=system_u:system_r:mandb_t:s0-s0:c0.c1023 tclass=capability


type=SYSCALL msg=audit(1356203108.49:313): arch=x86_64 syscall=stat success=no exit=ENOENT a0=188a2b0 a1=7fffd81fb970 a2=7fffd81fb970 a3=10 items=0 ppid=4763 pid=4768 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=8 comm=mandb exe=/usr/bin/mandb subj=system_u:system_r:mandb_t:s0-s0:c0.c1023 key=(null)

Hash: mandb,mandb_t,mandb_t,capability,dac_override

audit2allow

#============= mandb_t ==============
allow mandb_t self:capability dac_override;

audit2allow -R

#============= mandb_t ==============
allow mandb_t self:capability dac_override;


Additional info:
hashmarkername: setroubleshoot
kernel:         3.6.11-3.fc18.x86_64
type:           libreport

Comment 1 Miroslav Grepl 2012-12-27 09:34:58 UTC
Could you reproduce it with

Turn on full auditing
# auditctl -w /etc/shadow -p w

Try to recreate AVC. Then execute
# ausearch -m avc -ts recent

Comment 2 Daniel Walsh 2012-12-27 16:03:54 UTC
This looks like some file has the wrong ownership or permissions on it that mandb_t is trying to access.

Comment 3 Daniel Walsh 2012-12-27 16:05:22 UTC
eric would it be possible in some situations to add a name field to a dac_override/dac_read_search avc, so we would have some clue what target is being denied?

Comment 4 Eric Paris 2012-12-27 16:27:55 UTC
maybe if you enable syscall auditting by adding a rule.  I add

-a exit,always -F arch=b32 -S kill -F pid=1

to /etc/audit/audit.rules as it cannot ever trigger a record, but will collect inode info.

But no other way...

Comment 5 Daniel Walsh 2012-12-27 16:38:26 UTC
Yes I know, but doesn't the kernel know in some situations what the name of the file directory is when the avc is triggered?  Not that path but the file name.

name="shadow" for example would be a big help without turning on full auditing.

Comment 6 Colin J Thomson 2012-12-27 19:15:40 UTC
(In reply to comment #1)
> Could you reproduce it with
> 
> Turn on full auditing
> # auditctl -w /etc/shadow -p w
> 
> Try to recreate AVC. Then execute
> # ausearch -m avc -ts recent

Here is the output:

----
time->Thu Dec 27 19:05:05 2012
type=PATH msg=audit(1356635105.960:318): item=0 name="/home/g6avk/man"
type=CWD msg=audit(1356635105.960:318):  cwd="/"
type=SYSCALL msg=audit(1356635105.960:318): arch=c000003e syscall=4 success=no exit=-2 a0=26422b0 a1=7ffff9f8ebe0 a2=7ffff9f8ebe0 a3=10 items=1 ppid=6106 pid=6111 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=8 comm="mandb" exe="/usr/bin/mandb" subj=system_u:system_r:mandb_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1356635105.960:318): avc:  denied  { dac_override } for  pid=6111 comm="mandb" capability=1  scontext=system_u:system_r:mandb_t:s0-s0:c0.c1023 tcontext=system_u:system_r:mandb_t:s0-s0:c0.c1023 tclass=capability

The time coincides when my system is running some standard cron jobs.

Comment 7 Miroslav Grepl 2012-12-27 19:22:43 UTC
Yes, we look for 

name="/home/g6avk/man"

# ls -dZ /home/g6avk/man

Comment 8 Daniel Walsh 2012-12-27 19:36:33 UTC
So the problem is mandb running is trying to read man files that are not owned by root and root does not have "other" access to.

Comment 9 Colin J Thomson 2012-12-27 19:40:52 UTC
(In reply to comment #7)
> Yes, we look for 
> 
> name="/home/g6avk/man"
> 
> # ls -dZ /home/g6avk/man

I am puzzled as I have no such file or directory.

Comment 10 Colin J Thomson 2012-12-27 23:46:20 UTC
(In reply to comment #9)
> (In reply to comment #7)
> > Yes, we look for 
> > 
> > name="/home/g6avk/man"
> > 
> > # ls -dZ /home/g6avk/man
> 
> I am puzzled as I have no such file or directory.

Sorry its been a long day, I do of course have /home/g6avk/ but cannot find anything related to "man" I've tried running the daily cron jobs manually with run-parts but the warning does not happen... assuming that is the trigger.

Comment 11 Daniel Walsh 2012-12-28 16:38:30 UTC
Which means mandb is not allowed to search through /home/g6avk  

ls -ld /home /home/g6avk

Comment 12 Colin J Thomson 2012-12-28 20:37:05 UTC
OK,

ls -ld /home /home/g6avk
drwxr-xr-x.  5 root  root  4096 Jul 19 15:58 /home
drwx------. 59 g6avk g6avk 4096 Dec 28 09:31 /home/g6avk

I did some more checking today and noticed in my crontab file path I had:
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local:/home/g6avk

This file is from way back and I must of added /home/g6avk to the path when doing some tests or something years ago. I wonder if this is what has triggered this in F18

Comment 13 Daniel Walsh 2013-01-02 19:55:28 UTC
Probably. mandb is fairly new policy.

Comment 14 Colin J Thomson 2013-01-06 19:54:27 UTC
(In reply to comment #13)
> Probably. mandb is fairly new policy.

OK, I removed the obsolete setting "/home/g6avk" from my crontab PATH and do not get this alert anymore.


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