Bug 730143 - failed to open gdbm file '/var/lib/pam_shield/db' : File open error
Summary: failed to open gdbm file '/var/lib/pam_shield/db' : File open error
Keywords:
Status: MODIFIED
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: pam_shield
Version: el6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Carl Thompson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-11 21:38 UTC by Jonathan Underwood
Modified: 2019-04-30 21:39 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)

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).


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