From owner-freebsd-security@FreeBSD.ORG Thu Mar 10 21:00:05 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 CE4EF1065670 for ; Thu, 10 Mar 2011 21:00:05 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7FE458FC18 for ; Thu, 10 Mar 2011 21:00:05 +0000 (UTC) Received: by iwn33 with SMTP id 33so2320505iwn.13 for ; Thu, 10 Mar 2011 13:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:in-reply-to :message-id:references:user-agent:x-openpgp-key-id :x-openpgp-key-fingerprint:mime-version:content-type :content-transfer-encoding; bh=1hHhgNtd6SzYOZB6PGH+76Kx7+bzkr8t78BXLX4xX/8=; b=fpf51YZry00d3ebBN1LQu982Z/hS+sVKbuHx48LXsAv2ZpYFZ37eZUjJEnIeQGars4 oljoTbOA5DFzNkJcPb9kshgf4yw2OS1YO4qNbjurxcVswR3c48SOAO4KLB+oYLiIQ/lE KT6Qq6qmchRUYaWgOQixQAPRI3nbC1GNsHi1U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type:content-transfer-encoding; b=dnVSQb7SoZL3z3ZGiv018C30gUaGkMLKBsksOZYSLvxjLZTB9NwUS04qJsvU0Fbmvh GXC5cD6d3nSkVk40+B0sHqTBkRjy4Mjod5avcLHEbKdkOQtTSSLEfm94sOx3lf5lCOQ3 YfCXKUWKA4Enl71iDyEEctatqGGLTGwARtmb0= Received: by 10.42.145.199 with SMTP id g7mr10631150icv.451.1299790804716; Thu, 10 Mar 2011 13:00:04 -0800 (PST) Received: from disbatch.dataix.local (adsl-99-19-43-28.dsl.klmzmi.sbcglobal.net [99.19.43.28]) by mx.google.com with ESMTPS id uf10sm2506403icb.5.2011.03.10.13.00.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Mar 2011 13:00:02 -0800 (PST) Sender: "J. Hellenthal" Date: Thu, 10 Mar 2011 16:00:00 -0500 From: "J. Hellenthal" To: Miguel Lopes Santos Ramos In-Reply-To: <1299769253.20266.23.camel@w500.local> Message-ID: References: <1299682310.17149.24.camel@w500.local> <1299769253.20266.23.camel@w500.local> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT 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 21:00:05 -0000 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