Am Donnerstag, den 31.07.2008, 09:03 -0500 schrieb Pat Riehecky: > 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 > Apart from the snmpd.conf permissions, which surely must be a bug, the rest of your long message seems like an argument for security by obscurity. Is it? -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
