My primary user is staff_u, but I don't think it has anything to do with my primary user account.

I'm seeing the same AVC denial.
It does not happen with pam-1.0.2-2.fc10.
It is 100% reproducible with pam-1.0.4-2.fc10. Every attempt to login to dovecot IMAP server hits this AVC denial. The login is not prevented though.
My guess is it's a fd leak somewhere.

Yes, previously the pam_unix module closed all descriptors when executing unix_chkpwd. This caused a problem reported in the bug 488147 so it does not close stdin/out/err descriptors anymore. Dovecot should mark the leaked pipe to be closed on exec with fcntl(FD_CLOEXEC).

But does dovecot expect the child process to be able to write to the terminal so 0,1,2 so it can read or log the output?

(In reply to comment #4)
> But does dovecot expect the child process to be able to write to the terminal
> so 0,1,2 so it can read or log the output?  

I don't exactly understand your question...

before dovecot-auth calls pam_authenticate dovecot creates log pipe
(see http://pastebin.com/m600c99f5 line 20)

just before the pam_authenticate, dovecot has this fds open:
fd=  0 ->                 /dev/null
fd=  1 ->                 /dev/null
fd=  2 ->            pipe:[1146620]   pid=12333, cmd='/usr/sbin/dovecot'
fd= 20 ->            socket:[11522]
fd= 21 ->            socket:[11522]
fd= 22 ->            socket:[11522]
fd= 23 ->            socket:[11522]
fd= 24 ->            socket:[11522]
fd= 25 ->            socket:[11522]
fd=  3 ->              /dev/urandom
fd=  4 ->          socket:[1146619]
fd=  5 ->            pipe:[1146623]   unable to find target
fd=  6 ->            pipe:[1146623]   unable to find target
fd=  7 ->    anon_inode:[eventpoll]
fd=  8 ->          socket:[1148624]

so If I understand your question, answer is yes, there is opened stderr for logging

So either dovecot needs to close this descriptor or pam_unix.

pam_unix should not exec unix_chkpwd with any open file descriptors from its parents.

That's debatable. This pipe opened from dovecot is for logging stderr output of pam modules. They should not print anything on stderr though.

Let's see what are the options here:

1. close all the descriptors including the std ones - this means that glibc will abort unix_chkpwd startup if /dev/null /dev/full are broken. With the old pam_unix version that meant allowing access which is clearly a problem. This was fixed so now it would mean disallowing access. Unfortunately that also means that the admin will not be able to log in to the machine anymore.

2. close all the descriptors including the std ones + open the std descriptors the same way glibc does (/dev/null /dev/full). This would have exactly the same consequence as 1. except there will not be any "crash" of unix_chkpwd logged. So this is probably less ugly than 1. but still bad.

3. close only the non-std descriptors - that is what the current packages do - unfortunately with the AVC - if dovecot closed the descriptor (by FD_CLOEXEC probably) it would not help either because that would be the same as case 1.

4. anything else? I thought that I could create a new pipe() and use it for the stderr/stdout descriptors (as the stdin descriptor already is reopened as a pipe when unix_chkpwd is executed). But this seems like a hack as the pipe would not be read by the parent process at all.

So what do you suggest?

Also the option 4. would require the same allow rule in policy as the option 3. as the pipe would have the same label probably.

Tomas,

I believe pam_unix is replacing stdout and stdin before execing unix_chkpwd with its own pipe, for communication, but it is not closing stderr.  Why not close stderr and either hand it stdouts pipe or /dev/null?

Previously it closed stdout and stderr (and everything else) and replaced stdin with a pipe. There is no stdout pipe currently.

So what you propose is the option 4 from the comment 7 (use a new pipe) or option 2 (/dev/null). I suspect that the option 4 will not make the AVC to disappear. The option 2 has the unwanted consequence of disallowing login on broken /dev/null.

The problem I have is this is being based from dovecot_t to dovecot_auth_t to system_chkpwd_t.

There is not direct transition from dovecot_t to system_chkpwd_t.

So there is not simple way for me to write policy that says system_chkpwd_t can write to pipes owned by the execing process.


If you changed to using pipes or /dev/null in the execing process, I can put a general rule allowing 

chkpwd_domtrans($1)
domtrans_pattern($1, chkpwd_exec_t, system_chkpwd_t);
allow system_chkpwd_t $1:fifo_file write;

')

So I chose the option 4 from comment 7 and it seems no selinux policy changes are necessary.

pam-1.0.4-3.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update pam'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-2783

*** Bug 492489 has been marked as a duplicate of this bug. ***

pam-1.0.4-4.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/pam-1.0.4-4.fc10

pam-1.0.4-4.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update pam'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3204

pam-1.0.4-4.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.