Subject: Ownership and Permissions

From: [email-masked] (Phillip Krokidis)
Date: Sun, 19 Feb 1995 15:57:34 +1100

What ownership, group and permissions for directories and files under ~ftp 
provide the best security. I hear that ROOT should be made the owner rather 
than FTP. A table with headings: File Owner Group Permissions ; would be great!
 
Also,I would like to know how the different ownerships and permissions can be
a security problem... or is this something that should not be discussed openly?

I'm sure this has been asked before but I would greatly appreciate any response.

Thanks,

----------------------------------------------------------------------------
Phillip Krokidis
Network Manager
Internet Access Australia Pty Ltd.    
769 Centre Rd                          Tel: +61 3 576 4222
East Bentleigh, 3165                   Fax: +61 3 563 7854
Victoria, Australia                    e-mail: [email-masked]
----------------------------------------------------------------------------

---

From: [email-masked] (Patrick Salsbury)
Date: Mon, 20 Feb 1995 15:45:16 -0800 (PST)

-Date: Sun, 19 Feb 1995 15:57:34 +1100
-From: [email-masked] (Phillip Krokidis)
-
-What ownership, group and permissions for directories and files under ~ftp 
-provide the best security. I hear that ROOT should be made the owner rather 
-than FTP. A table with headings: File Owner Group Permissions; would be great!
	Sounds reasonable. I think they go through some of this stuff in the
O'Reilly "Managing Internet Information Services" book, but here's a bit from
my archive, with some notes (and editing):

total 8
-r--------  1 root     wheel           0 Jan 13 01:48 .forward
-r--------  1 root     wheel           0 Jan 13 01:48 .rhosts
d--x--s--x  3 root     wheel         512 Aug  9  1994 bin
d--x--s--x  2 root     wheel         512 Sep 30  1993 dev
d--x--s--x  3 root     wheel         512 Feb 20 11:25 etc
dr-xr-sr-x  8 root     wheel         512 Jan 19 17:18 pub
dr-xr-sr-x  3 root     wheel         512 Sep 30  1993 usr
-r--r--r--  1 root     wheel         339 Feb 15 14:10 welcome.msg

	None of the files are owned by ftp. That's because people coming in as
anonymous (or ftp, they're the same) would own those file, and could change
the permissions, delete, whatever.

bin:
total 135
---x--x--x  1 root     wheel       24576 Aug  9  1994 compress
dr-xr-sr-x  2 root     wheel         512 Jul 28  1994 ftp-exec
---x--x--x  1 root     wheel       98304 Aug  9  1994 gzip
---x--x--x  1 root     wheel       13352 Sep 30  1993 ls

bin/ftp-exec:
total 120
---x--x--x  1 root     wheel       24576 Jul 21  1994 compress
---x--x--x  1 root     wheel       98304 Jul 28  1994 gzip

dev:
total 0
cr--r--r--  1 root     misc       3,  12 Sep 30  1993 zero

etc:
total 3
-r--r--r--  1 root     wheel          64 Feb 15 11:07 group
dr-xr-sr-x  2 root     wheel         512 Nov 10 12:14 msgs
-r--r--r--  1 root     wheel         260 Jul 27  1994 passwd

etc/msgs:
total 1
-r--r--r--  1 root     wheel         111 Nov 10 12:00 msg.toomany

pub:
total 6
dr-xr-sr-x  6 root     wheel         512 Feb  6 13:28 ft-servers
dr-xr-sr-x 13 root     wheel         512 Feb  6 13:56 incoming
dr-xr-sr-x  3 root     wheel        1024 Feb 16 14:23 misc
drwxrws--x  5 root     users         512 Feb 20 09:54 outgoing
dr-xr-sr-x 12 root     wheel         512 Feb  6 15:16 patches
dr-xr-xr-x  4 root     wheel         512 Feb  6 14:17 xremote

	Note that 'outgoing' is executable, but not readable, nor writable.
This means that people can go in and get stuff IF THEY KNOW THE FILENAME, but
not otherwise. (No browsing.)

pub/incoming:
total 12
-r--r--r--  1 root     wheel         330 Feb  6 13:56 .message
drwxrws-wx  2	       wheel         512 Feb 20 10:20	     
drwxrws-wx  2	       wheel         512 Jan 20 11:27	     
drwxrws-wx  2	       wheel         512 Jan 17 07:00	     
drwxrws-wx  2	       wheel         512 Jan 13 08:33	     
drwxrws-wx  2	       wheel         512 Jan  3 15:18	     
drwxrws-wx  2	       wheel         512 Jan 13 16:38	     
drwxrws-wx  2	       users         512 Jan 30 12:27	     
drwxrws-wx  2	       mktg          512 Feb 20 11:04	     
drwxrws-wx  2	       staff         512 Jan 26 16:33	     
drwxrws-wx  2	       wheel         512 Feb 14 11:49	     
drwxrws-wx  2	       wheel         512 Jul  5  1994	     

	These incoming directories are set up for various staffers (names
removed here) to receive incoming things. The directories are writeable and
executable, but not readable. i.e.- You can drop things off, but no one else
can browse through and see what you've left.

pub/outgoing:
total 3
drwxrwsr-x  2	       users        1024 Feb 15 11:47 xxxxx
drwxrwsr-x  5	       users         512 Feb 15 11:20 yy.zzzzz
	This is the unreadable outgoing directory from above. If you've been
dealing with a staff person, they'll tell you the actual name of the above
directories, which you can then CD into, and see whatever's in there. (You'll
notice that the subdirectories are readable, even though this one isn't, as
per above.)

usr:
total 1
dr-xr-sr-x  2 root     wheel         512 Sep 30  1993 lib

usr/lib:
total 576
-r-xr-xr-x  1 root     wheel       40960 Sep 30  1993 ld.so
-r--r--r--  1 root     wheel      516096 Sep 30  1993 libc.so.1.8
-r--r--r--  1 root     wheel       24576 Sep 30  1993 libdl.so.1.0

-Also,I would like to know how the different ownerships and permissions can be
-a security problem...or is this something that should not be discussed openly?
-
-I'm sure this has been asked before but I would greatly appreciate any
-response. 
-
-Thanks,
-Phillip Krokidis

	That's part of the problem with security. You have to impart info
without providing a how-to manual. ;^)
	In the case of file permissions/ownerships, you can see some of it
above. By changing whether a directory is read/write/executable, you change
how people can interact with it. By watching the ownership of the actual
directories, you can protect the data in it. 
	Briefly: Whoever owns the directory controls the files in it, no
matter who the file-owners are. Try this yourself. Create a file owned by
root or some other account. (I just did a 'ls > ~pats/filename' as root to
redirect a listing into my home dir.) Even though the file is owned by root, I
am able to delete it. This is _not_ something you want every anonymous user on
your site to have the capability of doing! :)

	Many things seem to relate to permissions. If you understand who owns
what, and what they can and cannot do with/to them, you're well on your way to
finding the solution to many problems.

	For more on security, you can check "Practical Unix Security" and
"Computer Security Basics" by O'Reilly, and "Firewalls and Internet Security"
(don't remember the author, sorry) for a start. There are also newsgroups and
websites out there, and organizations such as CERT.

	And if others out there spot some overlooked glitch in my file
structures above, I'd appreciate a polite pointer to what I can improve, but
not a wiped out machine *GRIN*. There's always more to learn. If you've got
info, please share it! :)

Pat
-------------------------------------------------------------------------------
	  Patrick Salsbury 	                  Visionware           
	Sys Admin/Webmaster             4500 Bohannon Dr., Suite #280  
	Voice: 415/325-2113	             Menlo Park, CA 94025      
	 FAX: 415/325-8710	      X/UNIX/PC Integration Specialists

---

From: [email-masked] (Russell Street)
Date: Tue, 21 Feb 1995 20:23:24 +1300 (NDT)

Hello..

That was a very good layout of a anon-FTP site IMHO.  Mirrors what I
have done to mine quite closely. 

You seem to have neglected ~ftp...

dr-xr-sr-x  3 root     wheel         512 Sep 30  1993 /.../ftp

would be a good start (again, NOT OWNED BY FTP unlike the suggestions
in some man pages!) (.e.g., IRIX 5.2...

     recommended that the subtree be constructed with care;  the following
     rules are recommended, using the ``ftp'' anonymous	account	as an example.

     ~ftp      Make the	home directory owned by	``ftp''	and unwritable by
	       anyone (mode 555	- see chmod(1)):

		  chown	ftp ~ftp
(end of aside)

> -r--------  1 root     wheel           0 Jan 13 01:48 .rhosts

Making these two completely unreadable.  Does not buy you much, but
for the sake of completeness.  You should also have in your
	/etc/aliases
file an alias directing mail to FTP to a suitable person.

> dr-xr-sr-x  3 root     wheel         512 Sep 30  1993 usr

You could take the read permissions of /usr and /usr/lib.  They are
not needed.  

> the permissions, delete, whatever.

If you like that idea then you should also disable remote
	chmod
	chown
	chgrp
in the configuration file.

> dr-xr-sr-x  2 root     wheel         512 Jul 28  1994 ftp-exec

Again, removing read permissions from this directory could buy more
false sense of security :-) :-)

> cr--r--r--  1 root     misc       3,  12 Sep 30  1993 zero

Some systems like Solaris 2.3 need /dev/tcp and friends.  Some of these
need to be world writable :-( :-(

> -r--r--r--  1 root     wheel         260 Jul 27  1994 passwd

If you are happy with your directory listings coming up with numbers
instead of uid/guids these files can be empty.

> dr-xr-sr-x 13 root     wheel         512 Feb  6 13:56 incoming

Again you can remove the world reabable bit so people have to know
what directory to move into next or can be told by the .message file.
(As per the outgoing directory)

> -r--r--r--  1 root     wheel       24576 Sep 30  1993 libdl.so.1.0

Better still, recompile binaries as static binaries and ditch shared
libraries.  Some OSes (Solaris 2.3, you can guess I am a Solaris site)
need others and/or are difficult to make static binaries on --- THANKS
SUN! ;)

> without providing a how-to manual. ;^)

The bad guys know it all already, so all you are doing is keeping
information from the good guys ... or so the argument goes.

> your site to have the capability of doing! :)

If you are a little paranoid (especially about the world writeable
ones) set the sticky bit on the directories and make wu-ftpd change
the ownerships away from 'ftp' or whatever its default it.

The sticky bit will ensure you have to be the owner of the directory
or have write permissions to the file to delete it.  Some OSes don't
support it (HP-UX 8.0x for example).

> finding the solution to many problems.

The permissions on /dev/tcp in Solaris are a worry... 

> websites out there, and organizations such as CERT.

Subscribe to the 'firewalls' mailing list.  That is often a good place
to pick up information like this.

> 	And if others out there spot some overlooked glitch in my file

It was most excellent... perhaps you should send a copy to the guy who
maintains the Anon FTP FAQ (How have a an security hole, :-) er, be an
anon FTP site in ten easy leasons).

One other thought occurs... get and install 'Tripwire'.  Even if you
don't run it on the entire machine, it might be useful to have it
keeping tabs on your anon FTP area.

Hope this is of some help...
Russell
 -------------------------------------------------------------------
 Russell Street ([email-masked]) +64 (9) 373-7599 extn 6487
   UNIX Systems Programmer, Computer Centre, University of Auckland
	     http://www.auckland.ac.nz/cc/People/RS.html

	   It's something to do with the shortage of money
	       and the holidays in the South of France.