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

On Thu, 10 Mar 2011 10:00, mbox@ wrote:
>>
>> /etc/profile
>> grep "^${LOGNAME} " /etc/opiekeys ||/usr/bin/opiepasswd -c
>
> Yes, or /usr/bin/opiepasswd -d. In general, this is a problem of keeping
-d would not be correct for the above example as opiepasswd would run if 
the user was not found. If the user was not found then -d really wouldn't 
be beneficial.

> two files in sync, /etc/master.passwd and /etc/opiekeys... it will never
> work.
master.passwd and opiekeys don't really have much to do with each other in 
this case. OPIE is another layer on top of the existing security and 
setting a different password using opiepasswd would only help to improve 
upon the security of the system.

> 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).
Seems to me that the users here should have their passwords automatically 
generated for them using a dependable secure length that might take 2.3 
billion years for a processor on every square inch of the earths surface 
to crack. ;) adduser(8) has the possibility to generate random passwords, 
mail the user the generated password, and then you just have to enforce 
the /etc/profile rule ;)

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

The hole here is only the administrator of said system. I'm not pointing at 
you in particular but rather knowledge of a policy that is required for 
correct or intended operation and understanding of what OPIE is and how it 
is meant to operate.

>
> 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?
>
FreeBSD isn't and probably will never be a secure by default installation, 
but certainly does have the possibility of doing so with the right amount 
of knowledge behind it.

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

You are right. Its not meant to enforce non-trusted authentication at all. 
This is a tripwire not a authentication. It allows to bypass the OPIE 
mechanism for those that are ``permit'' and to enforce it explicitly for 
those that are listed as ``deny'' besides that pam_opieaccess is blind and 
PAM along with OPIE does the rest.

>
> It's kind of paradoxical, but that's what it does.
>

I have flicked OPIE on in the past and it never allowed anything in past 
the first addition of a opiekeys. This is the admins job to figure out 
whether the policy for the user is to be (user initiated) or (admin 
enforced). If its admin enforced which seems to be your case then you are 
now in charge of changing the required bits for that operation to be 
successful and will probably include some of the things I have already 
stated either above or in the last message posted.

You have a lot of variables in this equation that on FreeBSD can really 
only be met with a mix of modifications, scripting, programming and other 
such methods a experienced administrator would use.

Good luck on your quest,

-- 

  Regards,

  J. Hellenthal 簧
  (0x89D8547E)
  JJH48-ARIN

_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"