Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 16 Nov 1998 08:16:40 +0100
From:      Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
To:        Warner Losh <imp@village.org>, 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:  <19981116081640.A2304@internal>
In-Reply-To: <199811160658.XAA01912@harmony.village.org>; from Warner Losh on Sun, Nov 15, 1998 at 11:58:02PM -0700
References:  <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
On Sun, Nov 15, 1998 at 11:58:02PM -0700, Warner Losh wrote:
> In message <19981116072937.E969@internal> Andre Albsmeier writes:
> : > Back to the original thread, I'm not sure how making more programs
> : > setgid would help system security.  Small ones that are easy to audit
> : 
> : Well, if you make it setgid and use 640 on the password file, you
> : a) can't write to the pw file directly any more
> : b) have to crack the root pw from the still readable pw file in order
> :    to become root.
> : 
> : Now you are root immediately.
> 
> Now you have to have root in order to get root.  /etc/passwd is
> readable by everybody, but so what.  There are no passwords in it.

Of course, I ment "pw file" standing as a synonym for the 600 files
in /etc: /etc/spwd.db /etc/master.passwd

> The master password file, on the other hand, is readable only by
> root.

And writeable. 

> It is true that a stack smashing attack would get you only group pw if
> you made this change.  Hmmm, that might be worth it.
> 
> : BTW, by examining the xlockmore configure file I found that I am not
> : the first one thinking of it:
> 
> Not being the first to think of it doesn't make it right. :-)
>
> This would plug some potential holes in a small number of
> applications.  I'm not sure that it is worth it on the effort/return

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.

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.

Especially xlock is a good candidate since it never gives up it
root privileges.

	-Andre

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?19981116081640.A2304>