Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 730143

Summary: failed to open gdbm file '/var/lib/pam_shield/db' : File open error
Product: [Fedora] Fedora EPEL Reporter: Jonathan Underwood <jonathan.underwood>
Component: pam_shieldAssignee: Carl Thompson <fedora>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: el6CC: dwalsh, eddie.kuns, fedora, hansecke, lancelassetter
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-30 15:56:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jonathan Underwood 2011-08-11 21:38:18 UTC
Description of problem:
pam_shield doesn't seem to be able to write to the gdbm database, for reasons I haven't fathomed. What I see in /var/log/secure:

Aug 11 21:42:00 hostx unix_chkpwd[26559]: password check failed for user (root)
Aug 11 21:42:00 hostx sshd[26555]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=188-xxx-xxx-xxx.zone13.bethere.co.uk  user=root
Aug 11 21:42:02 hostx sshd[26555]: Failed password for root from 188.222.237.226 port 53949 ssh2
Aug 11 21:42:04 hostx sshd[26556]: Connection closed by 188.xxx.xxx.xxx
Aug 11 21:42:12 hostx PAM-shield[26560]: failed to open gdbm file '/var/lib/pam_shield/db' : File open error


My /etc/pamd.d/sshd looks like this:

#%PAM-1.0
auth       required     pam_shield.so
auth       required     pam_sepermit.so
auth       include      password-auth
account    required     pam_nologin.so
account    include      password-auth
password   include      password-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    required     pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the user context
session    required     pam_selinux.so open env_params
session    optional     pam_keyinit.so force revoke
session    include      password-auth


Version-Release number of selected component (if applicable):
pam_shield-0.9.5-8.el6.x86_64

Comment 1 Carl Thompson 2011-08-11 21:46:45 UTC
A couple of questions:

1) is selinux enabled, if so disable and test
2) is gdbm installed

Comment 2 Jonathan Underwood 2011-08-11 21:58:00 UTC
I do have gdbm installed.

If I disable selinux, the error message in /var/log/secure no longer appears. 

Grepping audit.log for db:

# grep db /var/log/audit/audit.log 
type=AVC msg=audit(1313095235.591:24464): avc:  denied  { read write } for  pid=26152 comm="sshd" name="db" dev=md1 ino=3408251 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_var_lib_t:s0 tclass=file
type=AVC msg=audit(1313095269.020:24477): avc:  denied  { read write } for  pid=26497 comm="sshd" name="db" dev=md1 ino=3408251 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_var_lib_t:s0 tclass=file
type=AVC msg=audit(1313095320.574:24490): avc:  denied  { read write } for  pid=26555 comm="sshd" name="db" dev=md1 ino=3408251 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_var_lib_t:s0 tclass=file
type=AVC msg=audit(1313095332.703:24494): avc:  denied  { read write } for  pid=26560 comm="sshd" name="db" dev=md1 ino=3408251 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_var_lib_t:s0 tclass=file
type=AVC msg=audit(1313099559.911:24560): avc:  denied  { read write } for  pid=28305 comm="sshd" name="db" dev=md1 ino=3408251 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_var_lib_t:s0 tclass=file
type=AVC msg=audit(1313099632.329:24575): avc:  denied  { read write } for  pid=28365 comm="sshd" name="db" dev=md1 ino=3408251 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_var_lib_t:s0 tclass=file
type=AVC msg=audit(1313099632.329:24575): avc:  denied  { open } for  pid=28365 comm="sshd" name="db" dev=md1 ino=3408251 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_var_lib_t:s0 tclass=file
type=AVC msg=audit(1313099632.330:24576): avc:  denied  { getattr } for  pid=28365 comm="sshd" path="/var/lib/pam_shield/db" dev=md1 ino=3408251 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_var_lib_t:s0 tclass=file
type=AVC msg=audit(1313099632.330:24577): avc:  denied  { lock } for  pid=28365 comm="sshd" path="/var/lib/pam_shield/db" dev=md1 ino=3408251 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_var_lib_t:s0 tclass=file
type=AVC msg=audit(1313099673.435:24581): avc:  denied  { read write } for  pid=28365 comm="sshd" name="db" dev=md1 ino=3408251 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_var_lib_t:s0 tclass=file

Comment 3 Carl Thompson 2011-08-12 02:59:31 UTC
If you set the following context on the file you'll be fine:

system_u:object_r:var_auth_t:s0

I will be updating the package with a default context and such shortly.

Comment 4 Fedora Update System 2011-08-12 08:15:23 UTC
pam_shield-0.9.5-9.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/pam_shield-0.9.5-9.el6

Comment 5 Fedora Update System 2011-08-12 08:15:31 UTC
pam_shield-0.9.5-9.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/pam_shield-0.9.5-9.fc14

Comment 6 Fedora Update System 2011-08-12 08:15:39 UTC
pam_shield-0.9.5-9.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/pam_shield-0.9.5-9.fc15

Comment 7 Fedora Update System 2011-08-12 08:15:46 UTC
pam_shield-0.9.5-9.el5 has been submitted as an update for Fedora EPEL 5.
https://admin.fedoraproject.org/updates/pam_shield-0.9.5-9.el5

Comment 8 Fedora Update System 2011-08-12 08:15:54 UTC
pam_shield-0.9.5-9.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/pam_shield-0.9.5-9.fc16

Comment 9 Jonathan Underwood 2011-08-12 08:35:09 UTC
I think that would also require modification to the SElinux policy so that the label survives a relabel? cc'd Dan Walsh.

Comment 10 Daniel Walsh 2011-08-12 10:38:26 UTC
Added label to selinux-policy-3.10.0-19.fc16

Miroslav we need this label in RHEL6, F14,F15

+/var/lib/pam_shield(/.*)?      gen_context(system_u:object_r:var_auth_t,s0)

Comment 11 Jonathan Underwood 2011-08-12 14:59:15 UTC
OK, it seems we're not out of the woods SElinux wise yet. Having relabelled the db file, I see pam_secure failing to insert iptables rules and the following denials in audit.log

type=AVC msg=audit(1313160971.166:25482): avc:  denied  { getattr } for  pid=17818 comm="shield-trigger-" path="/sbin/iptables-multi" dev=md1 ino=3932300 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1313160971.166:25482): arch=c000003e syscall=4 success=no exit=-13 a0=f51480 a1=7fff991a22e0 a2=7fff991a22e0 a3=f items=0 ppid=17813 pid=17818 auid=10000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=197 comm="shield-trigger-" exe="/bin/bash" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1313160971.169:25483): avc:  denied  { getattr } for  pid=17813 comm="shield-trigger-" path="/sbin/iptables-multi" dev=md1 ino=3932300 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1313160971.169:25483): arch=c000003e syscall=4 success=no exit=-13 a0=f57640 a1=7fff991a2670 a2=7fff991a2670 a3=f items=0 ppid=17790 pid=17813 auid=10000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=197 comm="shield-trigger-" exe="/bin/bash" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1313160971.171:25484): avc:  denied  { getattr } for  pid=17813 comm="shield-trigger-" path="/sbin/iptables-multi" dev=md1 ino=3932300 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1313160971.171:25484): arch=c000003e syscall=4 success=no exit=-13 a0=f57b10 a1=7fff991a2690 a2=7fff991a2690 a3=f items=0 ppid=17790 pid=17813 auid=10000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=197 comm="shield-trigger-" exe="/bin/bash" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1313160971.173:25485): avc:  denied  { getattr } for  pid=17813 comm="shield-trigger-" path="/sbin/iptables-multi" dev=md1 ino=3932300 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1313160971.173:25485): arch=c000003e syscall=4 success=no exit=-13 a0=f57b30 a1=7fff991a2b80 a2=7fff991a2b80 a3=f items=0 ppid=17790 pid=17813 auid=10000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=197 comm="shield-trigger-" exe="/bin/bash" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null

Comment 12 Jonathan Underwood 2011-08-12 15:38:40 UTC
This seems to be what's needed for that second lot of denials:

module pamshield 1.0;

require {
	type iptables_exec_t;
	type sshd_t;
	class file getattr;
}

#============= sshd_t ==============
allow sshd_t iptables_exec_t:file getattr;

Comment 13 Carl Thompson 2011-08-12 17:15:09 UTC
Will we see issues with other programs using pam for authentication that may use this system such as saslauthd ftp dovecot.

I believe the gen_context(system_u:object_r:var_auth_t,s0) will cover these without issue but shield-trigger and shield-purge both call iptables by default and can be configured to call route instead.

Comment 14 Jonathan Underwood 2011-08-12 17:33:18 UTC
Yes, i am not sure what the correct policy is. The one I gave in Comment #12 is clearly not it - that works ok for sshd, but as you say, it's not general enough for other services. My selinux foo isn't good enough to work this one out, I'm afriad. Dan?


Aside: Carl - where actually is the best place to put pam_shield.so in the pam stack - where I have it presently it ends up entering an iptables rule even if the logins were successful, so I am clearly doing something wrong :).

Comment 15 Carl Thompson 2011-08-12 17:54:18 UTC
There are three approaches to usage of the pam_shield.so.

The first is block multiple failing login attempts by placing it as required after pam_unix.so

The second is block suspicious logins by placing it as a requisite at the beginning of the pam file

The last is to monitor all connections, including legit, to reduce login spaming from clients (ie outlook and the 1 minute mail check) by placing it as optional at the beginning.

Maybe a better resolution is a different place for the pam_shield directory and its contents.  /var/lib/pam_shield made sense but with selinux input maybe there is a better place that has a default context that would already work.

Comment 16 Carl Thompson 2011-08-12 19:45:28 UTC
I have pulled the release of 0.9.5-9 due to it not correcting the problem and will work on 0.9.5-10 to work with changes in selinux-policy and remove the post scripts that deal with selinux.

Comment 17 Carl Thompson 2011-08-15 18:58:52 UTC
Since there are security issues with allowing all the various daemons access to iptables I'm going to work toward another resolution to the invocation of iptables.  It still works without selinux but end goal is to get a mechanism that is not a security risk under selinux.

Comment 18 Lance Lassetter 2013-02-05 16:01:23 UTC
# cat /etc/fedora-release ; rpm -q pam_shield gdbm selinux-policy ; ls /var/lib/pam_shield/db:

Fedora release 18 (Spherical Cow)
pam_shield-0.9.5-11.fc18.x86_64
gdbm-1.10-3.fc18.x86_64
gdbm-1.10-3.fc18.i686
selinux-policy-3.11.1-73.fc18.noarch
ls: cannot access /var/lib/pam_shield/db: No such file or directory

I reinstalled all packages and still no /var/lib/pam_shield/db

Is there any way to force create pam_shield/db on a local system?

Lance

Comment 19 Edward Kuns 2013-12-08 07:05:34 UTC
This may be understood already, but I still see this on a fresh install of Fedora 19.

Comment 20 Edward Kuns 2016-01-03 18:00:19 UTC
This is still occurring on Fedora 23 (upgrade from 21, not fresh install).

Comment 21 Ben Cotton 2020-11-05 16:49:39 UTC
This message is a reminder that EPEL 6 is nearing its end of life. Fedora will stop maintaining and issuing updates for EPEL 6 on 2020-11-30. It is our policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of 'el6'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later EPEL version.

Thank you for reporting this issue and we are sorry that we were not able to fix it before EPEL 6 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged  change the 'version' to a later Fedora version prior this bug is closed as described in the policy above.

Comment 22 Ben Cotton 2020-11-30 15:56:57 UTC
EPEL el6 changed to end-of-life (EOL) status on 2020-11-30. EPEL el6 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
EPEL 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.