From owner-freebsd-security Mon Nov 16 22:48:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA27358 for freebsd-security-outgoing; Mon, 16 Nov 1998 22:48:25 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA27353 for ; Mon, 16 Nov 1998 22:48:21 -0800 (PST) (envelope-from andre.albsmeier@mchp.siemens.de) X-Envelope-Sender-Is: andre.albsmeier@mchp.siemens.de (at relayer david.siemens.de) Received: from mail.siemens.de (salomon.siemens.de [139.23.33.13]) by david.siemens.de (8.9.1a/8.9.1) with ESMTP id HAA12515 for ; Tue, 17 Nov 1998 07:47:54 +0100 (MET) Received: from curry.mchp.siemens.de (daemon@curry.mchp.siemens.de [146.180.31.23]) by mail.siemens.de (8.9.1a/8.9.1) with ESMTP id HAA14038 for ; Tue, 17 Nov 1998 07:47:54 +0100 (MET) Received: (from daemon@localhost) by curry.mchp.siemens.de (8.8.8/8.8.8) id HAA27433 for ; Tue, 17 Nov 1998 07:47:55 +0100 (CET) Message-ID: <19981117074752.C11602@internal> Date: Tue, 17 Nov 1998 07:47:52 +0100 From: Andre Albsmeier To: Warner Losh , Andre Albsmeier Cc: Matthew Dillon , freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <19981116081640.A2304@internal> <19981116072937.E969@internal> <19981115192224.A29686@internal> <19981115161548.A23869@internal> <199811151758.JAA15108@apollo.backplane.com> <19981115192224.A29686@internal> <199811152210.PAA01604@harmony.vill Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199811161842.LAA05020@harmony.village.org>; from Warner Losh on Mon, Nov 16, 1998 at 11:42:40AM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Nov 16, 1998 at 11:42:40AM -0700, Warner Losh wrote: > In message <19981116081640.A2304@internal> Andre Albsmeier writes: > : Which security holes do you mean? I thought basically of doing the > : following: > : > : a) invent a new group (e.g. shadow, to stick with xlockmore :-)) > : b) chgrp shadow /etc/spwd.db /etc/master.passwd > : c) chmod 640 /etc/spwd.db and /etc/master.passwd mode > : d) modify programs that write to these files (pwd_mkdb) > : to conform with b) and c) > : > : As far as we are now, I can't see a security hole here. /etc/spwd.db > : and /etc/master.passwd are now readable by the shadow group as well > : but up to now, no one runs under this group. > > Assuming that no users are in the shadow group... Of course. > : Now we modify xlock (or others which are setuid root only in order > : to access /etc/spwd.db or /etc/master.passwd) in the following way: > : > : a) chgrp shadow xlock > : b) chmod 2111 xlock > : > : xlock can now do the same as before: read the encrypted passwords > : but doens't run as root anymore. > > The only programs this would help are those that need to check > passwords and do nothing else. For example, ftpd wouldn't be helped > by this because it needs to set the userid to that of the user logging > in. ditto with login and most of the other programs that access the > password file to allow the user to have access to passwords, but don't > change the uid, etc. This would be xlock and related hangers on, and > little else. One program per system would likely benefit from this > change, since usually there is only one kind of screen lock per > system. > > This would be an incremental increase in security for a couple of > programs. You have changed the prize of breaking those programs from > full access to the system, to access to the password files (which one > could then run crack on). That would definitely be worth the effort > if it didn't just impact one or two programs. > > However, if someone sends me patches for this, I'll happily review > them (and commit them if good enough and the submitter isn't already a > committer). I will look at this maybe the next weekend. I think the most difficult thing is to find all places where /etc/master.passwd and /etc/spwd.db are touched. > > Warner -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message