Any chance for a tighter /etc/ structure?

[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

[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?

[Kevin Kofler]

Pat Riehecky <prieheck <at> iwu.edu> writes:
>  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. 
Sure, the /etc permissions are more open than necessary, but here 
the .ht_passwords file's permissions are the actual problem. There are plenty 
of ways to make files readable to Apache without making them world-readable:
* use groups: make a group for each hosted site containing only the user(s) 
allowed to modify the site and apache, then chown the file theuser:thegroup and 
make it 640.
* use setfacl (requires filesystem support, ext3 supports it):
chmod 600 .ht_passwords
setfacl -m u:apache:r .ht_passwords

        Kevin Kofler

[nodata]

Am Donnerstag, den 31.07.2008, 15:04 +0000 schrieb Kevin Kofler:
>  Pat Riehecky <prieheck <at> iwu.edu> writes:
>  > 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.
>  
>  Sure, the /etc permissions are more open than necessary, but here 
>  the .ht_passwords file's permissions are the actual problem. There are plenty 
>  of ways to make files readable to Apache without making them world-readable:
>  * use groups: make a group for each hosted site containing only the user(s) 
>  allowed to modify the site and apache, then chown the file theuser:thegroup and 
>  make it 640.
>  * use setfacl (requires filesystem support, ext3 supports it):
>  chmod 600 .ht_passwords
>  setfacl -m u:apache:r .ht_passwords
>  
>          Kevin Kofler 
But any user who can run scripts on the server as the apache user can
still read the files.. unless you only use php, and you try to prevent
it with safe mode or similar.

[Pavel Shevchuk]

>  But any user who can run scripts on the server as the apache user
> can
>  still read the files.. unless you only use php, and you try to prevent
>  it with safe mode or similar. 
Both php and apache cgi interface have tools to run scripts as unprivileged user


-- 
http://scwlab.com