From owner-freebsd-hackers Sun Nov 15 14:57:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA12918 for freebsd-hackers-outgoing; Sun, 15 Nov 1998 14:57:56 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA12907; Sun, 15 Nov 1998 14:57:53 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id PAA10913; Sun, 15 Nov 1998 15:57:29 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpd010906; Sun Nov 15 15:57:26 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id PAA02868; Sun, 15 Nov 1998 15:57:20 -0700 (MST) From: Terry Lambert Message-Id: <199811152257.PAA02868@usr05.primenet.com> Subject: Re: Would this make FreeBSD more secure? To: dillon@apollo.backplane.com (Matthew Dillon) Date: Sun, 15 Nov 1998 22:57:20 +0000 (GMT) Cc: andre.albsmeier@mchp.siemens.de, hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG In-Reply-To: <199811151758.JAA15108@apollo.backplane.com> from "Matthew Dillon" at Nov 15, 98 09:58:22 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@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 trusting you to not run "crack" (or whatever) against the password file. Basically, DES is insecure enough tese days that if I trust you with read access, I'm effectively trusting you with the root password (if you had access to the EFF hardware, you could obtain root in less than an hour). I think it's a bad idea to spread this trust around like this. Second, if I trust a program to read the file, but not to write it, I'm saying I have less trust in the program than I would hold out for "root". This is ridiculous, since I'm implicitly trusting the program to not have a hidden option to enumerate the shadow password database contents, and I'm also entrusting it to not be a trojan that, when passwords are successfully validated, the account/password information gets sent someplace. Basically, if I'm in for a penny, I'm in for a pound, and relying on obscurity and spreading the wealth around are both bad security risks. > Another thing that would be nice would be to give certain user id's > the ability to listen on low-numbered sockets without giving the rest > of the users that ability. SCO ODT had this "feature". SVR4 also has this "feature". It's effectively the same thing as VMS (or NT) installed images, where the image itself conveys permission to do things. Actually, there's already something like this for FreeBSD: "sudo". For priviledged ports, we have a different program: "inetd". > Immediate uses that I can see: > > * bind (has a user run mode, but then can't rebind on ifc > changes) This is more of a problem with the fact that we bind to IP addresses instead of binding to interfaces. Ideally, you would want to bind to interfaces, IP addreses, or both, e.g.: ed0:192.168.1.1 *:192.168.1.1 ed0:* > * sendmail (currently run under user with special hacks only) Not true. This is a matter of configuration file settings; so long as you don't specify a mailer to run under a user other than the user whom sendmail runs, you can run as non-root. The big PITA is the local delivery agent, *not* sendmail itself. > * popper (run as root) Don't use the qualcomm code. > * imapd (run as root) Don't know whose you are running; my imapd and pop3d run as user "cyrus". The U of W imapd/pop3d runs as a non-root user as well. > * xterm (suid root for utmp access) Yeah, well, this is just bogus because of the way credentials are handled in FreeBSD. It's the same reason we can't have per-user instead of per-machine SAMBA credeintions: there's no explicit session manager to act as credential holder, and to which programs can proxy requests. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message