From owner-freebsd-security@FreeBSD.ORG Thu Mar 10 15:01:21 2011 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 EF2D2106564A for ; Thu, 10 Mar 2011 15:01:21 +0000 (UTC) (envelope-from mbox@miguel.ramos.name) Received: from smtpauth.rollernet.us (smtpauth.rollernet.us [IPv6:2607:fe70:0:3::d]) by mx1.freebsd.org (Postfix) with ESMTP id C40E08FC12 for ; Thu, 10 Mar 2011 15:01:21 +0000 (UTC) Received: from smtpauth.rollernet.us (localhost [127.0.0.1]) by smtpauth.rollernet.us (Postfix) with ESMTP id 8719459400E; Thu, 10 Mar 2011 07:01:08 -0800 (PST) Received: from w500.local (a83-132-6-167.cpe.netcabo.pt [83.132.6.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: @miguel.ramos.name) by smtpauth.rollernet.us (Postfix) with ESMTPSA; Thu, 10 Mar 2011 07:01:07 -0800 (PST) Received: from w500.local (w500.local [127.0.0.1]) by w500.local (8.14.4/8.14.4) with ESMTP id p2AF0sxm020477; Thu, 10 Mar 2011 15:00:54 GMT Received: (from miguel@localhost) by w500.local (8.14.4/8.14.4/Submit) id p2AF0rQF020476; Thu, 10 Mar 2011 15:00:53 GMT X-Authentication-Warning: w500.local: miguel set sender to mbox@miguel.ramos.name using -f From: Miguel Lopes Santos Ramos To: "J. Hellenthal" In-Reply-To: References: <1299682310.17149.24.camel@w500.local> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Mar 2011 15:00:53 +0000 Message-ID: <1299769253.20266.23.camel@w500.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 X-Rollernet-Abuse: Processed by Roller Network Mail Services. Contact abuse@rollernet.us to report violations. Abuse policy: http://rollernet.us/abuse.php X-Rollernet-Submit: Submit ID 2540.4d78e7b3.c4ac7.0 Cc: FreeBSD Security Subject: Re: It's not possible to allow non-OPIE logins only from trusted networks 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: Thu, 10 Mar 2011 15:01:22 -0000 Qui, 2011-03-10 =C3=A0s 02:23 -0500, J. Hellenthal escreveu: > On Wed, 9 Mar 2011 09:51, mbox@ wrote: > > > > I think the way pam_opieaccess behaves is like "leave a security breach > > by default". I think it would be more usefull if it returned PAM_SUCCES= S > > when: > > > > 1. The user does not have OPIE enabled and the remote host is listed as > > a trusted host in /etc/opieaccess. > > 2. The user has OPIE enabled and the remote host is listed as a trusted > > host in /etc/opieaccess, and the user does not have a file > > named .opiealways in his home directory. > > > > Or at least this should be an option for pam_opieaccess. > > >=20 > Does changing the following in /etc/pam.d/sshd help ? > # auth (edited for length) > -auth sufficient pam_opie.so no_warn no_fake_prompts > +auth binding pam_opie.so no_warn no_fake_prompts > auth requisite pam_opieaccess.so no_warn allow_local >=20 Thanks, but no. That's not exactly what I want. That would force people to use OPIE. I only want to enforce OPIE for non-local network access. It's not realistic to enforce OPIE around here, have everybody have an otp-md5 calculator around, etc. For me, OPIE is just for an emergency scenario, when someone is out and doesn't have an SSH key pair (particularly, me). > There might be some other combinations that would change this behavior fo= r=20 > you but you will have to consult with pam.conf(5) as this is a pretty big= =20 > beast to sum up here. I don't think tweaking PAM would suffice. I would need a module which would be very similar in behaviour to pam_opieaccess, but with those changed semantics. Again, I can pick the code of pam_opieaccess and do the changes I said (it's right here in /usr/src/lib/libpam/modules/pam_opieaccess and is 40-50 lines of code). My point is, wouldn't those semantics be better for most people besides me? > Tweaking PAM in some situations could lead you to undesired results.=20 > Putting something into place of a script that runs out of /etc/profile or= =20 > /etc/shrc or whatever that greps the contents of /etc/opiekeys and prompt= s=20 > the user to run the correct commands or runs them the first time might= =20 > just be a better long-term solution to enforcing they use OPIE. >=20 > /etc/profile > grep "^${LOGNAME} " /etc/opiekeys ||/usr/bin/opiepasswd -c Yes, or /usr/bin/opiepasswd -d. In general, this is a problem of keeping two files in sync, /etc/master.passwd and /etc/opiekeys... it will never work. If I did as you say, I would still have a problem if someone would never get to login (people have accounts also because they own files, and account locking stops people who just use SSH as a cheap VPN). I could have some script run when a user is created, however, the hole would always be there, waiting to be exploited, so I wouldn't exploit that much further. > Anyway I'm sure some other shell-masters@ will chime in at some point and= =20 > possibly share what they have done in the past/present/future and offer u= p=20 > some real good insight on this. >=20 > VPN access to the box(s) could be another solution where everyone is loca= l=20 > and you don't need OPIE at all. \o/ Yes, that's right. That would solve a whole lot of other problems too. It's true that I'm using SSH in many cases just as an easy to administer VPN. I've been postponing that for years. But I would need something that worked with FreeBSD and Gentoo (don't want to learn two tools) and for any client. Still, even if I have a solution elsewhere, theoretically my question still stands. Wouldn't those changed semantics help people having a system which is more secure by default? The point is: /etc/opieaccess / pam_opieaccess is meant to allow people not to use OPIE on a trusted network. However, it does not enforce the use of OPIE from a non-trusted network. It's kind of paradoxical, but that's what it does. --=20 Miguel Ramos PGP A006A14C