restorecon -v /root/.forward is the fix unlike what the report suggests.

We should be able to take care of issues like these in Fedora 16

OK, I've done that and it fixed the problem.

What's the cause? And why will it take until F16 to fix?

R.

(thanks for the quick reply, btw)

The sendmail system service is not allowed to read "generic user home content files" admin_home_t is the type for generic home content files for root (/root).

type transitions are usually defined based on the source process and the parent directories type. But since /root is the parent of many different kind of files and most of the files created in /root are created by a single user (root), we can not differentiate between the various type of files that are created below /root.

So all files create by root in /root with get the generic user home content type for (/)root (admin_home_t). We can however specify what a particular file should be labelled (that is also why restorecon -v /root/.forward fixed the issue. There is a file context specification that says that /root/.forward should be labelled type mail_home_t.

mail_home_t is a type that the sendmail service is allowed to read.

In Fedora 16 we implemented a new functionality called "named" file type transitions which allowed us to differentiate based of the name of the file to be created.

We can say if root creates a file named .forward in /root then create the file with type mail_home_t instead of admin_home_t.

That will fix the current issue because the file will be created with the proper type as opposed to what we have to deal with currently, namely the file getting created with the wrong type.

OK, thanks for the detailed explanation.

R.

I will investigate why setroubleshoot did not give you a better answer though.  It should have figured this out.

Robin could you send me the original avc message.

ausearch -m avc

Sure, here you go:


time->Wed Jun  1 10:12:23 2011
type=SYSCALL msg=audit(1306919543.946:119): arch=c000003e syscall=2 success=no exit=-13 a0=7fff34544de0 a1=0 a2=1b6 a3=0 items=0 ppid=3481 pid=3482 auid=4294967295 uid=0 gid=51 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none) ses=4294967295 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:sendmail_t:s0 key=(null)
type=AVC msg=audit(1306919543.946:119): avc:  denied  { read } for  pid=3482 comm="sendmail" name=".forward" dev=dm-1 ino=403128 scontext=system_u:system_r:sendmail_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file

Well the problem is 

name=".forward" which is avc.path

If you change name=".forward" to name="/root/.forward"

then 

sealert -a /tmp/sendmail.log

works.

Yes but the tool is supposed to do a locate .forward and try to find an inode that matches, in order to fix the path.


Robin, if you do a locate .forward does it find /root/.forward?

I simulated the test on my machine, and it found the proper solution using locate .forward.

# locate .forward
/root/.forward

Yes. :)

ls -i /root/.forward
1186885 /root/.forward

# ls -i /root/.forward
403128 /root/.forward

?

Strange 

The AVC has 

ino=403128

Which is correct and the alert found the correct path.  But it did not suggest restorecon /root/.forward

Which is did on my machine.


If you paste that avc into a file (/tmp/avc) and run sealert -a /tmp/avc

Does the output suggest restorecon?

I get this:


$ sealert -a avc
100% donefound 1 alerts in avc
--------------------------------------------------------------------------------

SELinux is preventing /usr/sbin/sendmail.sendmail from read access on the file .forward.

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

If you believe that sendmail.sendmail should be allowed read access on the .forward 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 sendmail /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Can you run that as root?

Here you go:

# sealert -a avc
100% donefound 1 alerts in avc
--------------------------------------------------------------------------------

SELinux is preventing /usr/sbin/sendmail.sendmail from read access on the file /root/.forward.

*****  Plugin restorecon (99.5 confidence) suggests  *************************

If you want to fix the label. 
/root/.forward default label should be mail_home_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /root/.forward

*****  Plugin catchall (1.49 confidence) suggests  ***************************

If you believe that sendmail.sendmail should be allowed read access on the .forward 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 sendmail /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

That looks right.  Not sure why this did not happen in the first place.


Also notice the confidence level adds up to more then 100%...

Probably because the setroubleshooter app runs as a normal user with elevated (sudo) privileges rather than as root?

And yes, I did notice that 99.5 + 1.49 != 100% :)

R.

No setroubleshootd which is doing the analysys is running as root, it could have been blocked by selinux, but I do not see why.

I was just observing that running "sealert -a avc" as myself using sudo produced the same results as setroubleshootd did in the GUI app.

Yes I am looking at that also.