Bug 491471 - SELinux is preventing unix_chkpwd (system_chkpwd_t) "write" dovecot_t.
SELinux is preventing unix_chkpwd (system_chkpwd_t) "write" dovecot_t.
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
: SELinux
: 492489 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-21 09:55 EDT by Matěj Cepl
Modified: 2009-04-14 11:53 EDT (History)
6 users (show)

See Also:
Fixed In Version: 1.0.4-4.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-14 11:53:13 EDT
Type: ---
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 Matěj Cepl 2009-03-21 09:55:54 EDT
Souhrn:

SELinux is preventing unix_chkpwd (system_chkpwd_t) "write" dovecot_t.

Podrobný popis:

SELinux denied access requested by unix_chkpwd. It is not expected that this
access is required by unix_chkpwd and this access may signal an intrusion
attempt. It is also possible that the specific version or configuration of the
application is causing it to require additional access.

Povolení přístupu:

You can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable
SELinux protection altogether. Disabling SELinux protection is not recommended.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.

Další informace:

Kontext zdroje                system_u:system_r:system_chkpwd_t:s0
Kontext cíle                 system_u:system_r:dovecot_t:s0
Objekty cíle                 pipe [ fifo_file ]
Zdroj                         unix_chkpwd
Cesta zdroje                  /sbin/unix_chkpwd
Port                          <Neznámé>
Počítač                    viklef.ceplovi.cz
RPM balíčky zdroje          pam-1.0.4-2.fc10
RPM balíčky cíle           
RPM politiky                  selinux-policy-3.5.13-49.fc10
Selinux povolen               True
Typ politiky                  targeted
MLS povoleno                  True
Vynucovací režim            Enforcing
Název zásuvného modulu     catchall
Název počítače            viklef.ceplovi.cz
Platforma                     Linux viklef.ceplovi.cz
                              2.6.27.15-170.2.24.fc10.x86_64 #1 SMP Wed Feb 11
                              23:14:31 EST 2009 x86_64 x86_64
Počet upozornění           3
Poprvé viděno               So 21. březen 2009, 10:36:53 CET
Naposledy viděno             So 21. březen 2009, 10:36:53 CET
Místní ID                   3cbfd25f-8431-43a7-ba57-88cb234fda7f
Čísla řádků              

Původní zprávy auditu      

node=viklef.ceplovi.cz type=AVC msg=audit(1237628213.554:16): avc:  denied  { write } for  pid=3659 comm="unix_chkpwd" path="pipe:[9244]" dev=pipefs ino=9244 scontext=system_u:system_r:system_chkpwd_t:s0 tcontext=system_u:system_r:dovecot_t:s0 tclass=fifo_file

node=viklef.ceplovi.cz type=SYSCALL msg=audit(1237628213.554:16): arch=c000003e syscall=59 success=yes exit=0 a0=a12998 a1=7fff4e0a36e0 a2=c14890 a3=3c5c96da70 items=0 ppid=2552 pid=3659 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="unix_chkpwd" exe="/sbin/unix_chkpwd" subj=system_u:system_r:system_chkpwd_t:s0 key=(null)
Comment 1 Matěj Cepl 2009-03-21 09:56:29 EDT
My primary user is staff_u, but I don't think it has anything to do with my primary user account.
Comment 2 Michal Schmidt 2009-03-22 03:01:17 EDT
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.
Comment 3 Tomas Mraz 2009-03-23 06:41:20 EDT
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).
Comment 4 Daniel Walsh 2009-03-23 09:24:45 EDT
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?
Comment 5 Michal Hlavinka 2009-03-25 12:37:38 EDT
(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
Comment 6 Daniel Walsh 2009-03-25 13:15:00 EDT
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.
Comment 7 Tomas Mraz 2009-03-25 13:48:17 EDT
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?
Comment 8 Tomas Mraz 2009-03-25 13:49:58 EDT
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.
Comment 9 Daniel Walsh 2009-03-25 15:05:57 EDT
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?
Comment 10 Tomas Mraz 2009-03-25 15:24:10 EDT
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.
Comment 11 Daniel Walsh 2009-03-25 16:35:45 EDT
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;

')
Comment 12 Tomas Mraz 2009-03-26 10:51:18 EDT
So I chose the option 4 from comment 7 and it seems no selinux policy changes are necessary.
Comment 13 Fedora Update System 2009-03-26 10:52:14 EDT
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
Comment 14 Daniel Walsh 2009-03-26 20:23:21 EDT
*** Bug 492489 has been marked as a duplicate of this bug. ***
Comment 15 Fedora Update System 2009-03-30 12:45:11 EDT
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
Comment 16 Fedora Update System 2009-04-02 13:13:50 EDT
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
Comment 17 Fedora Update System 2009-04-14 11:52:58 EDT
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.

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