Please accept my apology for how long this is, in the end it is effectively a feature request (or perhaps a packing ''issue'')... it just takes a while to get there. After installing a typical RHEL/Fedora server a non privileged user has access to read all sorts of files that, while not terribly dangerous, they have no need to read and could, under some not at all extraordinary circumstances, disclose some more sensitive data. I know in a good part of the server world user's simply are not a valid concern. However, I would be surprised if any Unix based shop didn't have at least one server where users could ssh in and put files down. For example a standard user can read just about everything in /etc/samba, like the smbusers file which maps unix users to smb users. The big picture in this file is that it maps root to Administrator. This is something that we expect, but disclosing it seems in error. A security minded admin may change the mapping, but, since there is never a case where a non uid 0 process would need to read the file (samba runs as root), the permissions may never be tightened down. There is also the /etc/samba/smb.conf file which is world readable. A wealth of information that should never be given to users is in this file, as an admin I would expect this file to be not world readable by default. No one needs to read it but me, so I shouldn't share it with them. How about /etc/httpd/* I have a personal hosting account at a server farm where I can read everything in that directory. A quick check of the /etc/httpd/conf/httpd.conf tells me the name of every site hosted on this box. /home/37462614 doesn't tell me who this is, but a simple poke about in apache tells me all sorts of things. Like in this user's home they have a .ht_passwords file with customer access rights. A file that I can cat if I want and compromise their privacy. A file I must be able to cat because of the apache permissions. A file I would never have found if I hadn't been able to read the httpd.conf file. The httpd.conf file that as a non-root user, I never have a reason to read. The /etc/yum files are also world readable, knowing who is and is not a trusted software provider is just not something non-root users should need to know. The SNMP config file (/etc/snmp/snmpd.conf) is world readable by default. Disclosing this information to a non-administrative user is not a good idea. Supposing I enable SNMP writes. Giving any user access to this file after SNMP writes are enabled is rather bad. Chmoding it root only isn't listed in the documentation. Doesn't it seem a little strange that this is not automatically handled by the RPM on installation. Edits to the file will preserve the umask, and therefore retained. The 99% use case for snmpd is to only allow administrative users access to this file. The defaults apply to the 1% case where something else is at work. I wish to challenge this choice. Not just for SNMP but for every file and directory in /etc/. I would love for a secure configuration by default. seLinux is installed by default, the mandatory access control there is excellent, but there is no reason to have to rely on it when for 90% of the files in /etc/ a simple chmod will secure the files reasonably well. I realize one of the first reactions will be to let seLinux take care of it. SeLinux is great at this task, but it seems like pushing the burden entirely into seLinux is hiding the oddity I am pointing out. Suppose I had /etc/httpd/ recursively set to 2777 by default. This is obviously bad, but due to seLinux enforcement the apache process would not be able to modify /etc/httpd/ files, but wouldn't it make more sense to chmod things differently in the RPM? I realize that write access and random sticky bits are far greater than just a world read bit, but just because you can do something with seLinux doesn't mean it is the best way to do it. The list of random files in /etc/ could go on for a long while, but I would ask that a part of the packaging process going forward would be to evaluate the default permissions on all files packaged in /etc/ and decide if any of the world bits should be set. Allowing anything on the system to read files in /etc/ is not a good idea. I know seLinux, when it is enforcing, prevents a lot of this disclosure, but users are currently unconfined in the default RHEL5/Fedora9 and many admins (not myself, but it is still a sizable group) turn off seLinux. In security classes they stress having many lines of defense, setting good permissions by default seems a great place to start, just a serious outlay of work and a large bit of time. I know confined users is coming, but there are times I must put seLinux into Permissive mode. And confined users is not here yet. With the complexity of confining users I would not be the slightest bit shocked if it took a few more years to happen. Getting /etc/ locked down a bit tighter will help demonstrate that RHEL/Fedora is not only secure with seLinux running, but rather that seLinux is an extension of the security focus you expect to see from an Enterprise Linux provider. That even in non seLinux environments the system takes precautions about what data should and should not be given to non-root users. May I request that a step be added to the packaging process? A step where the world read bits are evaluated for validity. Obviously evaluating past packages is a ridiculous idea, but perhaps for the next release of Fedora any packages that start coming in could have this request attached to them. Pat -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
