Any chance for a tighter /etc/ structure?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux