It's not possible to allow non-OPIE logins only from trusted networks

[Miguel Lopes Santos Ramos]

Qui, 2011-03-10 às 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_SUCCESS
> > 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.
> >
> 
> 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
> 

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 for 
> you but you will have to consult with pam.conf(5) as this is a pretty big 
> 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. 
> Putting something into place of a script that runs out of /etc/profile or 
> /etc/shrc or whatever that greps the contents of /etc/opiekeys and prompts 
> the user to run the correct commands or runs them the first time might 
> just be a better long-term solution to enforcing they use OPIE.
> 
> /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 
> possibly share what they have done in the past/present/future and offer up 
> some real good insight on this.
> 
> VPN access to the box(s) could be another solution where everyone is local 
> 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.


-- 
Miguel Ramos <mbox at miguel.ramos.name>
PGP A006A14C