freebsd security - Mar 2011 - It's not possible to allow non-OPIE logins only from trusted networks

Hi,

This is about pam_opieaccess. Because there's no project page for OPIE
outside FreeBSD and because I found other complaints on pam_opieaccess
on this list
(http://www.derkeiler.com/Mailing-Lists/FreeBSD-Security/2003-06/0118.html),
I'm posting this here, I hope it's OK.


For a few years now, I have used this policy for SSH logins, and home
and at work:
- users can login with passwords if they are on a trusted (read: local)
network
- users can always login with public key authentication from anywhere
- users can only login from outside trusted networks if they use either
public key authentication or OPIE.

This is almost easy. Each user enables OPIE, and an /etc/opieaccess file
allows password logins from trusted networks, with something like:

permit 10.0.0.0 255.0.0.0

However, one thing about pam_opieaccess makes having this policy
troublesome. pam_opieaccess(5) says that it returns PAM_SUCCESS in two
cases:

1. The user does not have OPIE enabled.
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.


Now, things work according to the SPEC, that's good, but point 1 above
is troublesome for my policy.
Users is an open set: every now and then a new one is created. Because
every user must be explicitely mentioned in /etc/opiekeys, it's error
prone for my policy.
If I create a user and forget to add him to /etc/opiekeys I have a
breach in my policy. If additionally he chooses a weak or a strong but
compromised password, I have a security breach.


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.


I understand opieaccess is a transition mechanism (transition to a time
where everyone uses OPIE, yeah right), and it is meant so that users who
can't use OPIE don't stop those that can from using it.
However, I think a greater incentive for using OPIE (with my policy) is
"do you want to connect from the Internet like I do? You must use OPIE
for that."


Now, I'm a programmer, not so much an admin. I'm perfectly capable of
making a new pam_opieaccess module that does what I said or a simpler
module which just returns PAM_SUCCESS for trusted networks (that's all
that matters to my policy).


The point is, wouldn't the other behaviour be better for pam_opieaccess?
Also, why don't people bump on this more often? Is my policy
inadvisable?


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

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

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.

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
...


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/

-- 

  Regards,

  J. Hellenthal
  (0x89D8547E)
  JJH48-ARIN

Miguel Lopes Santos Ramos <mbox@miguel.ramos.name>
writes:
> 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.
Seems like a good idea, at first blush (provided it's optional).  Do you
have a patch?

DES
-- 
Dag-Erling Sm?rgrav - des@des.no