From owner-freebsd-security Sun Nov 15 18:20:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA02640 for freebsd-security-outgoing; Sun, 15 Nov 1998 18:20:54 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA02626; Sun, 15 Nov 1998 18:20:50 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id SAA16490; Sun, 15 Nov 1998 18:20:27 -0800 (PST) (envelope-from dillon) Date: Sun, 15 Nov 1998 18:20:27 -0800 (PST) From: Matthew Dillon Message-Id: <199811160220.SAA16490@apollo.backplane.com> To: Terry Lambert Cc: andre.albsmeier@mchp.siemens.de, hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? References: <199811152257.PAA02868@usr05.primenet.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : :> :while installing xlockmore, I noticed that its mode is 4111 for root. :> :... :> : :> :Wouldn't it be generally a good idea to make the /etc/spwd.db and :> :the /etc/master.passwd file 640 and give them to a newly created :> : :> :root@voyager:~>ll /usr/X11R6/bin/xlock :> :---x--s--x 1 root pw - 126976 Oct 1 08:17 /usr/X11R6/bin/xlock* :> : :> :What do you think? Will it make my systems more insecure with the :> :above stuff or not? If not, wouldn't it make sense to incorporate :> :the changes into FreeBSD? IMHO they break nothing since all programs :> :> I think this is an excellent idea. A similar method is used for :> the 'operator' group, to allow the dumper to dump disks without :> giving him write access to them. : : :There are several holes in the theory. The number one hole is :that if I'm trusting you to read the engrpted passwords, I'm :... I'm not so pessimistic. Anything that layers security is better then having nothing at all. It's easy to throw together examples of the failings of any scheme, but to then say that "gee, I'll just give up and give the program root" after shooting down a reasonable idea makes no sense whatsoever to me. The failings of the password file really have very little to do with the concept. If anything, it points out the necessity of using something like kerberos, beefing up the password file's encryption, or using ssh with *'d out passwords in the password file. This problem is easily surmountable. Just because you are storing encrypted passwords in your password file doesn't mean that I am. If you take an idea and try to make it work in every possible situation, you wind up with nothing left at the end of the day. That's a silly way to argue. inetd only goes so far... it is not a good way to start a subsystem such as sendmail or INN that you want to stick around as a daemon, and doesn't work at all when you use more sophisticated sendmail features such as when you separate the queue runs from the daemon, or if you put user's mailboxes in their home directories. In order to do it right, you need to be able to give sendmail the capability to listen on a low numbered port and you need to hack /bin/mail to run an suid 'create home directory' program when necessary. As I said... it requires hacking sendmail (or more to the point: /bin/mail) to make it work. Default configurations don't typically work on heavily loaded systems. Don't assume that we use the same configurations you use. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message