Hi, > Not really. The big benefits of it is that only user root can start and stop > processes. Also, all configuration data would be hidden for normal users. I presume when you say processes you mean daemon processes ? Are you refering to the fact that the process can't read a config file from /etc - if so, most deamons can be built to use config files from an alternative location (eg. '/home/user/my_apps/sshd/'). > On a SuSE Linux fresh out of the box this is the case for instance and I > would wonder if a regular RedHat wouldn't do it the same way, or at least in > a similar fashion. I'm not convinced. Simple functions like getpwent() rely on having access to /etc/passwd, and this shows up in everyday life: ls -ld /tmp drwxrwxrwx 8 root root 4.0k Sep 10 01:04 /tmp (chmod og-rx /etc/passwd /etc/group) as root ls -ld /tmp drwxrwxrwx 8 0 0 4.0k Sep 10 01:04 /tmp Spot the difference. As /etc/passwd is not readable to the world, ls can't look up the user and group names. It's a simple example, but I hope you get the gist. On one of my servers, /etc has system wide config files for all sorts of things ... xemacs, vim, ssh, minicom, screen and opera to mention just a few. There's the slocate database in there too. These are all files that I want everyone on the system to be able to see. On the whole, there's not much in /etc that I object to people with accounts on the machine viewing. As /etc/shadow is already set to owner and group read only, the most important file is protected and a few others have more rigorous permissions I can't comment on the SuSE setup, as I removed the last installation a couple of years ago, but I've used various flavours of Linux along with Solaris, HP-UX and Tru64 and as I recall, they all had permissions such that standard users had read permission in /etc Cheers, John _______________________________________________ cobalt-security mailing list [EMAIL PROTECTED] http://list.cobalt.com/mailman/listinfo/cobalt-security
