Date: Wed, 24 Jan 1996 19:36:57 -0600 From: William McVey <wam@fedex.com> To: security@freebsd.org Subject: Re: Ownership of files/tcp_wrappers port Message-ID: <199601250134.AA23162@gateway.fedex.com>
next in thread | raw e-mail | index | archive | help
>The real point against you're argument is segregation of priviliges. >Why give any more privilage to a binary than is necessary. The ownership of a file gives no privilege to the file unless it's setuid (and even then if you want to be a stickler to detail, the file doesn't get the increase in privileges, the user executing the file does). However, the owner of a file directly impacts on the protections available to it. Under Unix, there are basically two sets of users... root and everyone else. Root is treated special and has extra protections in a number of places meant to protect it from abuse (mapping to nobody with NFS, not honoring hosts.equiv, secure ttys, su only from group 0, etc.) Why make the owners of the binaries that root runs anything other than this protected account? >If a binary >doesn't need to be root then don't make it owned by root at all >and then if something goes wrong, like you mistakenly suid a bin binary >and not realise it, the possible damage is less than if it was a root >binary. This segregation is more to do with protecting sysadmins from >themselves than it is about preventing break-ins Nothing in the world that we do will keep sysadmins from potentially screwing themselves over. Besides this, using your own example, if some bin owned program becomes setuid, then the system is still compromised since with bin permissions you now have root by the nature that bin owns the executables that root runs. Having an unsecure program owned by bin made accidently setuid is just as bad as if the program had been owned by root (as demonstrated below). Your own argument shows that by having a "ghost" user own system critical files can cause administrators who may be inexperienced in security to not realize the ramifications of what has happened. >and the added >segragation is *NOT* a potential security hole since those uid's do not >have passwords and therefore *cannot* be cracked in and of themselves. I disagree. There are other ways into an account than by entering a password. The designers of the system have tried to restrict these entry points for the root id, but for regular users, this is simply not the case. >You *have* to crack root first. The point about bin is that the system >is not owned by an actual user. You gain nothing by having bin own files. Some have claimed it saves on administration details (saying you know it's binary file if it's owned by bin). To this I direct your attention to a lot of the bin owned files in /usr/bin which are not binary at all, but rather shell scripts (whatis, whoami, clear, cpp). If the intent is to show if they are programs or not, that's what the execute bit is for IMHO. >Another, related point, is that if someone does get access to bin, the >damage they can do is limited to the system binaries, you can't go >trashing other people's files. Sure they can... the path from user 'bin' is straightforward to root and from there to anyone. Once you're bin, replace /bin/sh with a program that attempts to chown some copy of the real borne shell to root and make it setuid (and then of course your trojan should invoke the real borne shell to not be detected). Once /bin/sh has been compromised, and run by root (which happens at least daily from /etc/daily) then the bad guy has a setuid root shell that can be used to garner full root privs which as we all know can be used to trash other people's files. Again, the fact that this wasn't intuitvly obvious just goes to show that having 'bin' ownership is misleading at best and downright insecure in practice. >To be honest, in a break-in situation >the system files are my least concern, if you're security minded you'll >be aware pretty soon if someone is messing with your system files and deal >with it. Detecting damage to users files is more difficult and in many >ways is more important, if someone cracks bin and takes your system down >you have outage while you restore, if someone trashed an users mission >critical data you're in big trouble. Granted user data is important, but how can system files be any less important? If I'm an admin for site that has been cracked, my primary concern will be making sure that the OS I'm running my users on won't be cracked again (or still); otherwise, no amount of work done to secure the user data will mean anything since there is nothing a user can do that will keep user files secure from a compromised root account. Even encryption requires the entering of a key or passphrase which root would have access to (a bad guy could read the passphrase directly out of memory or watch the keys strokes entered onto the tty). >Sysadmins make mistakes, if you make a potentially serious mistake with >a bin owned system binary the possible damage is limited to bin owned >files. Which I've demonstrated amounts to a compromise of the root account. >If you make a mistake with a root owned file it's a different matter. No, it's the same. >This is what segregation of privilages is all about. Making a lot more >of the system owned by root just increases the number of potential pitfalls >facing sysadmins. I strongly disagree. The 'bin' account has no additional protections on it than root does (this is obvious since root can become 'bin'). Yet root has numerous added protections. Why would we chose to have the most critical files on the system (the system executables) owned by an id with fewer than the maximum number of protections? -- William
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601250134.AA23162>