Date: Sun, 15 Nov 1998 18:20:27 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Terry Lambert <tlambert@primenet.com> Cc: andre.albsmeier@mchp.siemens.de, hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? Message-ID: <199811160220.SAA16490@apollo.backplane.com> References: <199811152257.PAA02868@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:> :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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811160220.SAA16490>