Date: Thu, 10 Mar 2011 15:00:53 +0000 From: Miguel Lopes Santos Ramos <mbox@miguel.ramos.name> To: "J. Hellenthal" <jhell@DataIX.net> Cc: FreeBSD Security <freebsd-security@freebsd.org> Subject: Re: It's not possible to allow non-OPIE logins only from trusted networks Message-ID: <1299769253.20266.23.camel@w500.local> In-Reply-To: <alpine.BSF.2.00.1103100147350.1891@qvfongpu.qngnvk.ybpny> References: <1299682310.17149.24.camel@w500.local> <alpine.BSF.2.00.1103100147350.1891@qvfongpu.qngnvk.ybpny>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <mbox@miguel.ramos.name> PGP A006A14C
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1299769253.20266.23.camel>