[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: Any chance for a tighter /etc/ structure?
- From: nodata <lsof nodata co uk>
- To: Development discussions related to Fedora <fedora-devel-list redhat com>
- Subject: Re: Any chance for a tighter /etc/ structure?
- Date: Thu, 31 Jul 2008 16:59:57 +0200
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
> 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
> 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
> 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.
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?
[Date Prev][Date Next] [Thread Prev][Thread Next]