Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 16 Nov 1998 11:42:40 -0700
From:      Warner Losh <imp@village.org>
To:        Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
Cc:        Matthew Dillon <dillon@apollo.backplane.com>, freebsd-security@FreeBSD.ORG
Subject:   Re: Would this make FreeBSD more secure? 
Message-ID:  <199811161842.LAA05020@harmony.village.org>
In-Reply-To: Your message of "Mon, 16 Nov 1998 08:16:40 %2B0100." <19981116081640.A2304@internal> 
References:  <19981116081640.A2304@internal>  <19981116072937.E969@internal> <19981115192224.A29686@internal> <19981115161548.A23869@internal> <199811151758.JAA15108@apollo.backplane.com> <19981115192224.A29686@internal> <199811152210.PAA01604@harmony.village.org> <19981116072937.E969@int 

next in thread | previous in thread | raw e-mail | index | archive | help
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...

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

Warner

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811161842.LAA05020>