Bug 522787

Summary:	quagga: build future versions without PAM
Product:	[Fedora] Fedora	Reporter:	Tomas Hoger <thoger>
Component:	quagga	Assignee:	Jiri Skala <jskala>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	low
Version:	rawhide	CC:	aglotov, jskala
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-09-14 12:05:10 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 Tomas Hoger 2009-09-11 12:58:40 UTC

Description of problem:
quagga packages as shipped in Fedora are built with PAM support enabled (--with-libpam) by default.  However, those PAM checks are only enforced on client-side (vtysh) and not server side, making it trivial to bypass them (via ptrace/gdb, LD_PRELOAD or custom vtysh build without PAM support).

vtysh communicates with daemons using unix sockets.  Permissions on the sockets are set as: quagga:quaggavt 660.  User needs to be either root or member of quaggavt group to communicate with the daemons.

Default PAM configuration only restricts access to root user, but once non-root user is member of quaggavt (s)he can easily bypass that restriction.

As requirement of quaggavt group membership seems fairly sufficient for access control, we should consider dropping PAM support by default, as it can only mislead users to believing there is additional check while there is none.