Archive for the tag 'permissions'

Apache Security Tips - Permissions on ServerRoot Directories

In typical operation, Apache is started by the root user, and it switches to the user defined by the User directive to serve hits. As is the case with any command that root executes, you must take care that it is protected from modification by non-root users. Not only must the files themselves be writeable only by root, but so must the directories, and parents of all directories. For example, if you choose to place ServerRoot in /usr/local/apache then it is suggested that you create that directory as root, with commands like these:

mkdir /usr/local/apache
cd /usr/local/apache
mkdir bin conf logs
chown 0 . bin conf logs
chgrp 0 . bin conf logs
chmod 755 . bin conf logs

It is assumed that /, /usr, and /usr/local are only modifiable by root. When you install the httpd executable, you should ensure that it is similarly protected:

cp httpd /usr/local/apache/bin
chown 0 /usr/local/apache/bin/httpd
chgrp 0 /usr/local/apache/bin/httpd
chmod 511 /usr/local/apache/bin/httpd

You can create an htdocs subdirectory which is modifiable by other users — since root never executes any files out of there, and shouldn’t be creating files in there.

File permissions for virtual pop inboxes in DirectAdmin

Any domains that you want to use for email (eg: mydomain.com) must be in both the /etc/virtual/domains file and the /etc/virtual/domainowners file.

The directory /etc/virtual/mydomain.com must exist and the files /etc/virtual/mydomain.com/passwd and /etc/virtual/mydomain.com/aliases exist.

File permissions for virtual pop inboxes should be the following below but not applicable with Dovecot/Maildir:

/var/spool/virtual/domain.com 770 username:mail
/var/spool/virtual/domain.com/* 660 username:mail

Permissions on Apache ServerRoot Directories

If you allow non-root users to modify any files that root either executes or writes on then you open your system to root compromises.

For example, someone could replace the httpd binary so that the next time you start it, it will execute some arbitrary code. If the logs directory is writeable (by a non-root user), someone could replace a log file with a symlink to some other system file, and then root might overwrite that file with arbitrary data. If the log files themselves are writeable (by a non-root user), then someone may be able to overwrite the log itself with bogus data.

If you choose to place ServerRoot in /usr/local/apache then it is suggested that you create that directory as root, with commands like these:

mkdir /usr/local/apache
cd /usr/local/apache
mkdir bin conf logs
chown 0 . bin conf logs
chgrp 0 . bin conf logs
chmod 755 . bin conf logs

It is assumed that /, /usr, and /usr/local are only modifiable by root. When you install the httpd executable, you should ensure that it is similarly protected

cp httpd /usr/local/apache/bin
chown 0 /usr/local/apache/bin/httpd
chgrp 0 /usr/local/apache/bin/httpd
chmod 511 /usr/local/apache/bin/httpd
SBDavid

Directory Permissions

Directory Permissions

If you want to prevent other users from reading the contents of your files, you have two choices:

You can set the permission of each file to 0600, so only you have read/write access.

You can put the files in a directory and set the permission of that directory to 0700, which prevents other users from accessing the files in the directory (or in any of the directory’s subdirectories) unless there is a link to the file from somewhere else.

Note the following:

You must have execute access for a directory to make it your current directory (via cd or chdir) or to change to any directory beneath (contained in) that directory.

If you do not have execute access to a directory, you cannot access the files within that directory, even if you own them.

0755 / Anybody can view the contents of the directory, but only the owner or superuser can make changes.

1777 /tmp Any user can create a file in the directory, but a user cannot delete another user’s files.

0700 $HOME A user can access the contents of his home directory, but nobody else can.

Checking File Permissions and Ownership for Security

A simple way to calculate umask values is to remember that the number 2 in the umask turns off write permission, while 7 turns off read, write, and execute permission.

The umask (UNIX shorthand for “user file-creation mode mask”) is a four-digit octal number that UNIX uses to determine the file permission for newly created files. Every process has its own umask, inherited from its parent process.

The umask specifies the permissions you do not want given by default to newly created files and directories. umask works by doing a bitwise AND with the bitwise complement of the umask. Bits that are set in the umask correspond to permissions that are not automatically assigned to newly created files.

The most common umask values are 022, 027, and 077. A umask value of 022 lets the owner both read and write all newly created files, but everybody else can only read them:

0666 default file-creation mode

(0022) umask

0644 resultant mode

A umask value of 077 lets only the file’s owner read all newly created files:

A recent trend among computing centers has been to set up new accounts with a umask of 077, so a user’s files will, by default, be unreadable by anyone else on the system unless the user makes a conscious choice to make them readable.

« Prev - Next »