Date: Sun, 15 Nov 1998 22:57:20 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: andre.albsmeier@mchp.siemens.de, hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? Message-ID: <199811152257.PAA02868@usr05.primenet.com> In-Reply-To: <199811151758.JAA15108@apollo.backplane.com> from "Matthew Dillon" at Nov 15, 98 09:58:22 am
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 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-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811152257.PAA02868>