Any chance for a tighter /etc/ structure?

[nodata]

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?