Before we can start Squid, we have to create a few directories on the system. It's important that these directories have the correct permissions, otherwise someone with a login on the cache may be able to gain root access. Let's work through the default directory tree, and set the permissions on each directory correctly. Since you may have special requirements, I won't simply give you a sequence of commands to run: if you need to use different permissions, it's important to understand the possible consequences.
In Chapter 2 we created a squid user and group, and created another group, squidadm for the people that will maintain the cache. When Squid starts up, it changes it's user and group ids to squid (thanks to the cache_effective_user and cache_effective_group tags in squid.conf.) Changing userids reduces the chance of a complete exploit because of a bug in Squid. It's important, however, to remember that users in the squidadm group can probably get root on your machine, so you should not put people that do not already have root on the machine in that group: it's just so that you don't have to su to root continuously.
In the below examples, we assume that a root group exists on your system. This may not be the case: some of you may have to replace the root group (not the user id!) in the examples below with either wheel or bin.
There are many versions of chown that don't use the "userid:groupid" notation we use in the following examples. On some systems the ":" may have to be replaced by a ".", on others you may have to run a separate "chgrp groupid" command to achieve the same end. See your system's chown manpage for more information.
Let's start with the /usr/local/squid/ directory. If your system starts Squid at bootup, a startup script running as root starts the program /usr/local/squid/bin/squid. If someone were to replace this binary with a trojan, they could gain root access. The /usr/local/squid/ directory should be owned by root, group root, and should not be writable by anyone else. This stops someone from moving the entire bin directory to (say) bin.off, and creating a new bin directory which contains their own squid binary. Use the following commands to set the permissions on this directory correctly:
Since we have already introduced the /usr/local/squid/bin directory, let's set it's permissions correctly next. If the directory itself was writeable by malicious users, we would have the same problem that we described above. Let's change it to be owned by root, group root, and make sure that only these root can write to the directory. We also need the files in this directory to be readable (and executable) by everyone, so that normal users can run programs like client. There are no setuid binaries in this directory, and if the rest of the files have the correct permissions, there is no reason not to let users into this directory.chown root:root /usr/local/squid/
chmod 755 /usr/local/squid/
cd /usr/local/squid/bin
chown root:root . chown root:root *
chmod 755 . *
Config files all live in the /usr/local/squid/etc/ directory. If a user can write to these files, they can almost certainly do malicious things. Because of this, you should not let normal users edit these files: only users which already have root access should be allowed to edit squid.conf. Earlier in the book, we created a squidadm for these users.
The /usr/local/squid/etc/ directory should be owned by root, group squidadm, so that squid-administrators would be able to create and update config files.
Many of you will not have encountered chown commands which use more than three numbers before. The following command sets the sticky bit on the directory. Let's assume that my primary group-id is staff (not squidadm.) On some systems, any file that I create will be owned by group staff, even if the directory is owned by the squidadm group. On these systems this would be a security problem: if I create the squid.conf file, people in the staff group may be able to make changes to the file.
With the sticky bit set on the directory, any files I create will be owned by the squidadm group. As I have said: this isn't necessary on some operating systems, but these permissions shouldn't have any adverse effect.
When you use RCS (introduced in Chapter 2), the revision history of a file is stored in an RCS logfile. These files will normally be created in the current directory (the ci command appends a comma to the filename to decide the name of the logfile, leading to filenames like squid.conf,v.) If you don't want your directory cluttered with these files, you can create an RCS directory, and move RCS files into it. The Revision Control System only stores logfiles in the current directory if an RCS directory doesn't exist, if one does, all new log files are created in it.cd /usr/local/squid/etc
chmod 2775 .
chown root:squidadm . *
If someone can gain access to the log files, they essentially have write access to original file, since when you check a file out (to make changes to it) the log file is considered to be the authoritive source. Don't forget to change the permissions on the RCS log files Squid doesn't create an RCS directory automatically; we create it in the example below.
Cache log files should be confidential. You (and other Squid administrators) may have to look at them occasionally, but other users should have no access to the files. Squid runs as the squid user, though, and needs to create the logs, so any directory we make needs to be writeable by the squid user too.# first, make the RCS directory
cd /usr/local/squid/etc
mkdir RCS
# move any RCS logfiles into the RCS directory, so that they don't
# clutter the config-file directory
mv *,v RCS
# make sure that the RCS directory is owned by the right people, and
# can be writeable by them
chown root:squidadm RCS
chmod 2770 RCS
# change the permissions of the files in the RCS directory to match
# newly created files
chown root:squidadm RCS/*
chmod 770 RCS/*
chown squid:squidadm /usr/local/squid/logs
chmod 770 /usr/local/squid/logs
As you may recall from Chapter 3, downloaded objects are placed in a hierarchy of swap directories. Squid.conf contains a cache_store line for each directory that files are to be stored in, and specifies the number of subdirectories that are to be created in each cache store (most people leave this at the default, 4096 directories per cache store.)
Squid's -z command-line option will create the appropriate cache-swap directories (since creating them by hand would be painful!) If the top-level cache directory specified in squid.conf does not exist, Squid will attempt to create it too, as squid, group squid (or whatever cache_effective_user/cache_effective_group is set to in squid.conf.) Since we changed the permissions on /usr/local/squid above so that only root can write to this directory, Squid's directory create will fail. Instead, let's create these directories and set their permissions manually.
If someone has read access to the cache logs, they can invade people's privacy. It may seem harmless to let people access the cache store indiscriminately, but I contend that it isn't.
Many web accesses reveal something about the person examining the page, be it their sexuality, their financial status, or their job satisfaction. This is why we stop people accessing log files and finding out who went to what pages, right? Well, it also means that we must stop people accessing the cache store directly. In many systems using cryptography, you can discover much about the nature of the contents of the traffic by traffic analysis, relating traffic flows to other events. If people only have access to the cache using a browser, it difficult for them to associate any hits they see with a given person. If they can examine other information about the object (say, the time that the file was created) they may be able to discover information about the person that requested the object. A simple example: let's say that someone connected to a job-search site at the middle of the night. You can immediately narrow down the list of possible requestors to night-staff. If you can find out who was on duty on that day, you narrow the number of possible requestors even more.
Let's change the permissions on the cache store so that only squid-administrators can access files in it. Note that you are going to have to repeat this process for every cache_dir in the squid.conf file.
Once the permissions on the cache directories are set correctly, you can run squid -z.mkdir /usr/local/squid/cache/
chown squid:squidadm /usr/local/squid/cache/
chmod 770 /usr/local/squid/cache/
Your output should look something like this:
cache1:~ # /usr/local/squid/bin/squid -z
1999/06/12 19:15:34| Creating Swap Directories
cache1:~ #
If you get permission denied errors running squid -z, double check that you are root, then check that squid.conf's cache_effective_user and cache_effective_group tags are both set to squid.
What occasionally happens is that a directory further towards / (the directories /usr/local/ or /usr/local/squid/, for example) are not set as readable/executable by the squid user. Because the appropriate user cannot access these directories, it cannot create files in the cache store directory. If you are still having problems running squid -z, ensure that each of the directories /usr/local and /usr/local/squid have reasonable permissions.
Right:
Wrong:cache1:~ # ls -ld /usr/local/
drwxr-xr-x 10 root root 1024 May 1 10:31 /usr/local/
Use the chmod o+rx /usr/local/ command to make the directory readable and executable by everyone.cache1:~ # ls -ld /usr/local/
drwxr-x--- 10 root root 1024 May 1 10:31 /usr/local/