Russell Coker said: > On Thu, 23 Oct 2003 04:02, Joe Moore wrote: >> >> * A more important consideration is the location of "bin"'s $HOME. >> > >> > What's wrong with the current location? >> >> At the moment, nothing. Since write access to /bin pretty much 0wns >> the box. But a .rhosts file (+) in /bin might not be noticed for a >> while. A file in /var/empty (the home dir for sshd's privsep user) >> might be noticed. > > To create a file in /bin you need root access. Therefore to create > /bin/.rhosts you need more access than such a file will grant. There > is no point in such an attack. Why would someone create /bin/.rhosts > when they can create /root/.rhosts?
There are many programs that use files in the target user's home directory for authentication. rsh and ssh are two common examples. Many of these programs would not be hindered by an invalid shell. That's why I originally said that the home directory is more important than what is in the seventh field of /etc/passwd. I should not have made my comment specific to UID2. As to why someone would create /bin/.rhosts rather than /root/.rhosts, perhaps a sysadmin has mistakenly allowed "sudo cp * /bin" for a user who normally installs software? Ok, that's a rather artificial example, but how about a buggy game that that can drop a .rhosts file in /usr/games? Or a buggy manpage that drops a .rhosts file in /var/cache/man? Any of these bugs would grant "system user" access, regardless of the shell entry in /etc/passwd. > Does bin even own ANY files or have write access to ANY directories on > a default install? From a quick look it seems that account "bin" gets > no write access to anything on a Linux system. If "bin" has no valid password, owns no files, runs no processes, and can write to no directories, then why does "bin" exist at all? --Joe
