UNIX Hints & Hacks
Chapter 3: Security
|
Sections in this Chapter: |
|
|
||
|
|
|
3.5 Permissions Levels |
|
|
|
|
|
|||
|
|
|
|||
|
|
|
|
|
|
UNIX Hints & Hacks |
|
||||||||||||||||||||||||||
|
Chapter 3: Security |
|
||||||||||||||||||||||||||
|
Various levels or types of permissions can be set on files and directories.
Flavors: AT&T, BSD
Syntax:
chown mode file
If a directory is set up with execute permissions only, everyone can go in the directory but only the owner of the directory and superuser can see the files inside the directory.
rocket 1% mkdir private rocket 2% chmod 711 private rocket 3% touch private/foo rocket 4% ls -ald private drwx--x--x 2 paul user 21 Sep 29 00:32 private/
rocket 7% su - steve Password:
rocket 5% cd private rocket 6% ls -al Cannot access directory .: Permission denied total 0
$ exit rocket 1# ls -al total 8 drwx--x--x 2 paul user 21 Sep 29 00:32 ./ drwxrwxrwt 6 sys sys 4096 Sep 29 00:33 ../ -rw-r--r-- 1 paul user 234 Sep 29 00:32 foo
In this example, users are allowed to access only what the owner of the directory wants them to access. They don't get to see what it is they are accessing but they can get it and write it out somewhere else. It is a blind directory; what the user doesn't know, he can't harm.
Paul set the permissions on the directory to private, so only he can see the directory. When Steve comes along, he too can go in the directory, but has to know the name of the file, foo, in order to get it.
Flavors: AT&T, BSD
Syntax:
chmod mode file
If you think your read-only files, which are set with permissions of 444, are safe from being written to, think again. There is a way to still write to the file and even change the permissions.
rocket 1% touch foo rocket 2% chmod 444 foo rocket 3% ls -al foo* -r--r--r-- 1 paul user 0 Sep 29 01:25 foo -rw-rw-rw- 1 paul user 427 Sep 29 01:23 foo.old
rocket 5% cp foo.old foo Cannot create foo - Permission denied
rocket 6% mv foo.old foo foo: 444 mode? (yes/no)[no] : yes
rocket 7% ls -al foo* -rw-rw-rw- 1 paul user 427 Sep 29 01:23 foo
If there is an attempt to edit, remove, or copy the file while it is in a read-only state, UNIX prompts you to make sure you really want to perform one of these functions to the read-only file.
Then how come the move command worked? In UNIX editors, the remove and copy commands look at the permissions of the files themselves to determine whether they have the ability to access the file. The move command is a renaming function within UNIX and uses the permission of the directory, not the file, to determine whether there is enough access to rename or move the file. It then inherits the permissions of the file that was moved onto it.
Flavor: BSD
Syntax:
chmod mode file chgrp mode file
You know from experience that you can generate a list of users into a group and provide that group with access to certain directories and files, which might not have been possible otherwise. Did you know that this works in reverse also? You can use the same list to deny access into certain areas of the system and files with the same group access list.
Edit the /etc/group file and add a new group called refuse with a list of users that you want kept out of the private area.
refuse:*:6666:gary,arthur,damiel,guest
Set the permissions on the file so that there is no read, write, or executable access for the group called refuse.
rocket 1# mkdir private rocket 2# chmod 705 private rocket 3# chgrp refuse private rocket 4# ls -ald private
drwx---r-x 2 root refuse 9 Sep 29 03:34 private/
rocket 10% cd private private - No such file or directory
When someone tries to access the private directory, UNIX always verifies that the account has permissions by the following order: owner-group-other. When it gets to the group access field, everyone in the refuse group is denied access; they cannot see the directory as long as none of the accounts in the refuse group access list has a root's UID of 0. Only those with root access and those that are considered others and not in the refuse group listing have access to the private area.
|
Note - It is not advisable to perform this little hack on any of the UNIX system files. Although it can be done, try to avoid it whenever possible. |
Because UNIX is a multiuser environment, there is a need for protecting files and users from one another. Having control of setting permissions helps to keep people from removing the wrong system files by mistake, snooping into other users' private areas, or compromising important data files.
One of the first things an administrator does is lock down access to her files and system files that are backed up to disk. Users and hackers like to think that something good is somewhere and the system administrator usually has it. Think about what you collect and have stored in your home directory. If you store and use administrative tools and files somewhere, lock that down too. I always keep a separate 2-3GB off on another disk with the permissions locked down to the root level only on some of my machines.
Think about what you're setting the permissions to before you change them. This is another area where changing something could turn into a bigger issue.
Dealing with permissions is also seriously dependent on the environment that you are working in. There are those who require a tight and secure environment, whereas others feel they require the freedom to have no permission, and they can expand their creative juices.
Man pages:
chmod, chgrp, group
|
UNIX Hints & Hacks |
|
||||||||||||||||||||||||||
|
Chapter 3: Security |
|
||||||||||||||||||||||||||
|
© Copyright Macmillan USA. All rights reserved.