From owner-freebsd-security@FreeBSD.ORG Wed Sep 17 16:16:17 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 773551065672 for ; Wed, 17 Sep 2008 16:16:17 +0000 (UTC) (envelope-from ivangrvr299@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id 26C018FC1A for ; Wed, 17 Sep 2008 16:16:16 +0000 (UTC) (envelope-from ivangrvr299@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so978801ywe.13 for ; Wed, 17 Sep 2008 09:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=Px2vJvbUvln9nzIXej1zZRP/2n36n28wlJCn/3AEKqE=; b=dh7VwIC621DZUg/sdWjjIsKi/L+kxYxNMIxTBRCY1L7TtGwXP+5q6XTnbYr1hjpmTf mywkkTn0a4V06fvgDxd6+oKUm97VRR8LWf+QDZETuIodZLVxM7DqlXl8UhCZvrGn8Y5G tqgpO6ido/WENx5uw+H8PeMxX7e381oFNjrKA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=vMRMEixtlqHlFwZRxmqrMqXr2i99jB1AgU6NdpzEIZ1uLrGyJeLa0fWhUzGh2uvPyX WDzHyqRoqv9t5stRnWXQkUV0NEv7aCLSiX7PRY4DUKu6IREKuGMZqHqiNmP6YVzjZZZ5 bEngTKEaq42RfgdLcFJkv8lPPA8w5DLBTCK8Q= Received: by 10.100.232.13 with SMTP id e13mr3666947anh.140.1221668175759; Wed, 17 Sep 2008 09:16:15 -0700 (PDT) Received: by 10.100.93.16 with HTTP; Wed, 17 Sep 2008 09:16:15 -0700 (PDT) Message-ID: <670f29e20809170916g2cafdbaybc6745ce92ad0187@mail.gmail.com> Date: Wed, 17 Sep 2008 21:46:15 +0530 From: "Ivan Grover" To: freebsd-security@dfmm.org In-Reply-To: MIME-Version: 1.0 References: <670f29e20809170453o43a2ae37sfd548de1ea7e70be@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-security@freebsd.org Subject: Re: Controlling PAM modules X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2008 16:16:17 -0000 Thanks Jason. Let me try to explain the complete problem: I have three authentication modules -- pam_radius_auth.so (for remote authentication) -- pam_unix ( unix local authentication) -- pam_opie (challenge/response) and other accounting modules such as pam_abl. I would like to place these in my service conf file in a best possible way. Assume my service conf file looks like: auth required pam_env.so auth required pam_abl.so config=/etc/security/pam_abl.conf auth sufficient pam_radius_auth.so // for remote authentication auth required pam_unix.so auth required pam_opie.so // for challenge response User will try with Remote authentication, if it fails then he has to enter correct unix passwd and challenge/response(providing both might be painful sometimes). Please advise if the above doesnt look ok or if i missed something. PAM application can be configured in the following way: - setup doesnt want to use Remote authenticaion, then pam_radius_auth.so is unneccessarly executed. so disable it - setup doesnt want to use user lockouts/ip address lockouts, then pam_abl.so is unnecessary. Similarly challenge/response softwatre may not be there in client side, so doesnt want to run pam_opie.so. so disable both in this case. By allowing such configurations, i might have to keep so many service conf files for each configuration. instead can i have some other better approach , if any. Does it make sense to leave to SecurityAdministrator to configure in the desired way or we try to code the PAM modules in a proper way so that they dont crash if they dont find the setup required. Please let me know your comments. On Wed, Sep 17, 2008 at 6:16 PM, wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Do i have any standard way to skip one of the PAM module >> with out changing the service conf file. >> > > Why do you not want to change the per-service conf files? Those files > _are_ the database. > > There are a bunch of strategies that you could use to, e.g., maintain your > alterations as a diff to the base-system config so to make upgrades easier, > but a) to answer your question, no, there's nothing standard for that, and > b) that is an especially risky approach - you could completely break your > security, letting anyone in, or locking legitimate users out, etc. > > > -Jason > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (FreeBSD) > Comment: See https://private.idealab.com/public/jason/jason.gpg > > iD8DBQFI0PwqswXMWWtptckRAqLsAJ9taCFEPfVGwY6Rrt3qtLuHVvmNDwCfatyl > S++ho4Gf4Zl/3E6Vjkks26o= > =gGZG > -----END PGP SIGNATURE----- >