- CHMOD 000 implications?
- Posted by Peter on October 24th, 2004
If anyone can spare the time to reply to my questions I would be very
grateful
I created some pages and put them on my website in their own directory,
in fact I created several directories and each contained webpages. Two
of the directories had the index page altered by someone unknown.
After speaking to the hosting company they suggested that it was likely
that the chmod for directory, pages or images was set to 777 which
allowed someone to remotely save a page. I checked all pages
directories and images and chmod was either 755 or 644 even the index
page which had been changed was 755.
I created several more pages exactly as I had done before and
everything was either 777 or 644 except the indexpage which was 000.
I am not well up on the permissions and how someone could have saved a
new index page to my ftp space replacing the original. Fortunately
nothing else was touched.
Is the chmod permissions 000 the problem?
Can anyone point me to any urls that explain in lay terms about
permissions and any relevant security problems?
My web site has a blank front page and I put relevant webpages into
their own directories and the only way anyone knows they are there is
if I give them the name of the directory...or so I thought...how can
anyone see directories that are not referenced on the main index page?
Regards
--
Peter
- Posted by David Kirkby on October 24th, 2004
Peter wrote:
I'm basing all the following on UNIX. You don't say what server is being
used, and in any case my knowledge of Windoze is a lot poorer.
chmod is a UNIX command, to change the permission modes of a file. So
you should not really talk about 'the chmod was 755'. The permissions
might well have been 755, and these could be set using the chmod
command, but the chmod is not 755. (In fact, coincidently, the
permissions on the actual command chmod are likely to be 755, but that
is not connected with the permissions on the files).
The permissions are listed with the 'ls' command. Here are the
permissions of a file on my web server.
webserver2 # ls -l index.html
-rw-r--r-- 1 root sys 8487 Oct 21 11:44 index.html
There are permissions for 3 groups of users
1) The owner of the file
2) Someone else in the same user group as the owner.
3) Anyone else.
Each of these 3 groups is allocated a set of 3 permissions. These are
read, write, execute.
read=4,
write=2
execute=1
So in the above file, the owner (root) has permissions of read and
write, but not execute, so the permission number for the owner would be
4+2=6. For the group (sys), the permission number (for want of a better
term) would be 4, as sys can only read it, and the same for the rest of
the world it would be 4 too, as they can only read the file.
In order to allow someone to get into a directory, they must have
execute permissions on that directory. That seems a bit odd, as you
can't execute a directory, but that is the way it is.
So a directory that I allow the world to look into, would have
permissions of
webserver2 # ls -ld timetables
drwxr-xr-x 2 root sys 512 Oct 1 18:08 timetables
or 755.
Files created on a UNIX system has a default set of permissions. So if I
create a file 'foobar' using the touch command.
webserver2 # touch foobar
then list the permissions using the ls command.
webserver2 # ls -l foobar
-rw------- 1 root root 0 Oct 24 22:47 foobar
webserver2 #
So on my system, when root creates a file, only he can read it by
default. This is set by a 'umask'. (Do a google to find out more about
that, as it gets a bit complex to explain).
index.html do not need execute permission, so do not have 755 on any
'normal' web pages. I am ignoring server side includes, and cgi scripts,
but I doubt you are at a point to worry about them.
There is nothing stopping one creating a file and it automatically have
permissions that allow anyone to write to it. It would be a bad default,
but it is not impossible.
What sets the default permissions when you create a file on a remote
site is probably due to the UNIX umask on the remote site. (for example
the file /etc/default/ftpd on my Solaris system), but could be your ftp
software or the permissions on the file before you try to ftp it to your
web site.
(I doubt if you have the ability to copy files via scp, which is a
secure copy. But if you do, it is useful to set the permissions what you
want on your own site first:
chmod 644 index.html
Then use something like
% scp -p index.html username@remotehost:/remote/directory
The -p option tells to keep the same permissions.
)
**But after creating a file, you should check the permissions are 755
for directories and 644 for files on the web server** That is the
important bit.
If you create a file with permissions 000, you will not be able to read,
write or execute it. But the owner can change the permissions using the
chmod command.
You should only be able to change the permissions on your own files -
not anyone elses, even if you have write access to them. But of course,
if you have write access to them, you can delete them, or change their
contents.
I think I have covered them above. If you have access to a shell, and
can use the ls command, check the permissions of files with
% ls -l
and make sure they show
-rw-r--r--
and for directories, you have to use ls -ld (otherwise you list the
files in the directory, and not the directory itself).
There you need permission of 755
ls -ld
drwxr-xr-x
Just make sure the write bit is not set for anyone other than yourself.
Easy. There are a number of programs (e.g. wget) which can copy all the
files they have permissions to copy. Then search engines could possibly
find them too. If you don't have an index.html file, someone can list
the contents, such as here.
http://www.medphys.ucl.ac.uk/~drkirkby/data/Eimac/
If its a UNIX system, with other uses, then they can probably look at
your files to see what you have. Just make sure any you don't want
people reading do not have the read bit set. But you should not really
put such files on a web server anyway. Web servers are by their very
nature less secure than isolated systems.
Don't rely on security hoping someone will not find your files.
Dr. David kirkby
- Posted by David Kirkby on October 24th, 2004
A couple of corrections to my own post !!
David Kirkby wrote:
I should have said if you leave write access to the files (such as with
a permission field of 777
-rwxrwxrwx
they *anyone* can read or delete them on the system. Without the help of
some cgi scrips or similar a normal user with a brower should not be
able to delete them (I don't think so anyway), but certainly other uses
of the system will be able to.
I meant don't rely on obscruity hoping someone will not find your files.
If you don't want anyone finding the files, there is really no need for
them to be on a web server - especially one where you are not the
administor. But if you intend making the data available later, but
perhaps not just now, then don't rely on people not finding it - set the
permissions so they can't read if
chmod 600 secret_file
chmod 700 secret_directory
- Posted by Jim Ley on October 25th, 2004
On Sun, 24 Oct 2004 23:41:07 +0100, David Kirkby <nospam@nowhere.com>
wrote:
if webdav was enabled, it may well be possible to overwrite from a
suitable web-browser/client too.
Jim.
- Posted by Dr. David Kirkby on October 25th, 2004
jim@jibbering.com (Jim Ley) wrote in message news:<417c36ac.105751402@news.individual.net>...
You are probably right, althogh I think the term I used: "without the
use of some cgi scripts or similar" would sort of cover that. Perhaps
'a non prividged application on the server' would have been more
appropiate. Clearly permission of 777 are very poor practice indeed.
Summing up a bit more, the implications of a permissions of 000 are:
1) The owner is unable to read, write or execute the file (the first
zero)
2) Users in the same group as the owner are unable read, write or
execute the file (second zero)
3) Anyone else is unable to read, write or execute the file (third
zero).
If the permissions of 000 were on a directory, nobody would be able to
read the contents of the directory. Even if they knew the names of the
files in there, they would be unable to read or write to them.
David Kirkby
- Posted by Harrie on October 25th, 2004
Dr. David Kirkby said the following on 10/25/04 14:33:
Unless that user is root. If this is about a site which is hosted, the
admin('s) can do everything, so like you said before, don't trust a
website with sensitive content.
To the OP: check the man pages of chmod and ls (and maybe chown) on your
UNIX/Linux system for more references.
--
Regards
Harrie
- Posted by Jim Ley on October 25th, 2004
On 25 Oct 2004 05:33:36 -0700,
see_my_signature_for_my_real_address@hotmail.com (Dr. David Kirkby)
wrote:
Isn't webDAV supported natively on many web-servers now?
Jim.
- Posted by David Kirkby on October 26th, 2004
Harrie wrote:
Agreed - I forgot to mention that very valid point !!
- Posted by Richard Watson on October 28th, 2004
jim@jibbering.com (Jim Ley) writes:
That rather depends on your lower threshold for "many" and whether
you're counting by type of server or by individual box out there
running an http service.
--
Richard Watson
http://www.opencolo.com/
High Quality, Value for money colocation
- Posted by Jim Ley on October 28th, 2004
On Thu, 28 Oct 2004 00:02:16 +0100, "Richard Watson"
<tinnedmeat@doilywood.org.uk> wrote:
I think IIS has it and Apache 2.0 has it and Tomcat has it, so I
guess I was meaning many versions of the popular server choices.
Jim.


