Date: Wed, 24 Jan 1996 02:04:03 -0800 (PST) From: Nathan Lawson <nlawson@statler.csc.calpoly.edu> To: lists@argus.flash.net (mailing list account) Cc: security@freebsd.org Subject: Re: Ownership of files/tcp_wrappers port Message-ID: <199601241004.CAA11866@statler.csc.calpoly.edu> In-Reply-To: <199601230641.AAA00965@argus.flash.net> from "mailing list account" at Jan 23, 96 00:41:19 am
next in thread | previous in thread | raw e-mail | index | archive | help
> In reply: > > or not. Are there any more? I really have not heard a convincing argument > > for bin ownership other than "too many files are owned by root". Remember > > which is a lame argument to boot. Yes, it is. > user and group ownership should be based on function, instead of preference. > >I pity the poor fool who changes the ownership of a setuid script to root, or >a setgid script to wheel... same for setuid/gid programs that give any form of > shell access.. I think you're missing the point. Root runs programs like /bin/ls any time someone su's and lists a directory. So why is ls owned by bin? This means a degradation of privileges and allows a trojan horse attack. Is root a higher level of access than bin? Most definitely. So why should we allow bin compromises an easy way to make a root compromise. > bin is nice for non-threat functions in that it has no password assigned, thus >disabling any logins... of course there is that one fool in a million who will > assign a password for bin, thus making it vulnerable. I think you're missing the fact that bin compromises do not come from passwords assigned to it by mistake, but through NFS. Also, things like hosts.equiv allow bin access, while root is not allowed. Many many utilities treat root as a special account, with appropriate restrictions. I have NEVER seen a system that also applies these checks to bin as well. The only protection on bin is that it doesn't have a valid password. Let's have files that are executed as root be owned by root. > the plaintext nature of most tcp connections is even a greater threat. That's beside the point. I am not addressing network vulnerabilities. I am singling out host vulnerabilities. > I do see areas where permissions could be changed up a bit... > > world permissions on binaries should always be 1, and for most of them, a 711 > would be adequate... this would be best done in the distribution, and > makefiles so we don't have to do it ourselves every time a new release is made I think that binaries should not be world readable, but should be readable by group bin or whatever so that you can place trusted users in group bin and allow them to do strings(1) on binaries, etc. > the easiest way for hacker to learn a program's weakneses is from a debugging > dump of a readable binary. Yeah, but FreeBSD offers source, which is even better. I like the idea of things like /bin/sh not being readable so that cookbook scripts that copy and make a setuid shell are a bit slower to implement. > this in itself will only stop the casual hacker. with the avalability of the > sources, a determined hacker could probably find holes with a little effort. Exactly. Which is why things that are run with privileges must be protected as carefully as programs that run setuid root. -- Nate Lawson \Yeah, I was dreaming through the 'howzlife', yawning, car black, Owner: \when she told me 'mad and meaningless as ever...' and a song Cal Poly State \came on the radio like a cemetery rhyme for a million crying University \corpses in their tragedy of respectable existence. - BR
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601241004.CAA11866>