Written by Kurt Seifried
A solid house needs a solid foundation, otherwise it will collapse. In Linux's case this is the ext2 (EXTended, version 2) filesystem. Pretty much your everyday standard UNIX-like filesystem. It supports file permissions (read, write, execute, sticky bit, suid, sgid and so on), file ownership (user, group, other), and other standard things. Some of its drawbacks are: no journaling, and especially no Access Control Lists, which are rumored to be in the upcoming ext3. On the plus side, Linux has excellent software RAID, supporting Level 0, 1 and 5 very well (RAID isn't security related, but it certainly is safety/stability related). There is an excellent HOWTO on filesystems in regards to Linux at: http://www.penguin.cz/~mhi/fs/Filesystems-HOWTO/Filesystems-HOWTO.html.
The basic utilities to interact with files are: “ls”, “chown”, “chmod” and “find”. Others include ln (for creating links), stat (tells you about a file) and many more. As for creating and maintaining the filesystems themselves, we have “fdisk” (good old fdisk), “mkfs” (MaKe FileSystem, which formats partitions), and “fsck” (FileSystem ChecK, which will usually fix problems). So, what is it we are trying to prevent hostile people (usually users, and or network daemons fed bad info) from doing? A Linux system can be easily compromised if access to certain files is gained, for example the ability to read a non-shadowed password file results in the ability to run the encrypted passwords against crack, easily finding weak password. This is a common goal of attackers coming in over the network (poorly written CGI scripts seem to be a favorite). Alternatively, if an attacker can write to the password file, he or she can seriously disrupt the system, or (arguably worse) get whatever level of access they want. These conditions are commonly caused by "tmp races", where a setuid program (one running with root privileges) writes temporary files, typically in /tmp, however far to many do not check for the existence of a file, thus allowing an attacker to make a hard link in /tmp pointing to the password file, and when the setuid program is run, kaboom, /etc/passwd is wiped out or possibly appended to. There are many more attacks similar to this, so how can we prevent them?
Simple: set the file system up correctly when you install. The two common directories that users have write access to are /tmp and /home, splitting these off onto separate partitions also prevents users from filling up any critical filesystem (a full / is very bad indeed). A full /home could result in users not being able to log in at all (this is why root’s home directory is in /root). Putting /tmp and /home on separate partitions is pretty much mandatory if users have shell access to the server, putting /etc, /var, and /usr on separate partitions is also a very good idea.
The primary tools for getting information about files and filesystems are all relatively simple and easy to use. “df” (shows disk usage) will also show inode usage, “df –i” (inodes contain information about files such as their location on the disk drive, and you can run out of these before you run out of disk space if you have many small files. This results in error messages of "disk full" when in fact “df” will show there is free space (“df –i” however would show the inodes are all used). This is similar to file allocation entries in Windows, with vfat it actually stores names in 8.3 format, using multiple entries for long filenames, with a max of 512 entries per directory, to many long filenames, and the directory is 'full'. The “du” utility will tell you the size of directories, which is very useful for finding out where all that disk space has disappeared to, usage is “du” (lists everything in the current directory and below it that you have access to) or “du /dir/name”, optionally using “-s” for a summary which is useful for directories like /usr/src/linux. To gain information about specific files the primary tool is ls (similar to DOS's “dir” command), “ls” shows just file/dir names, “ls –l” shows information such as file perms, size and so on, and 'ls -la' shows directories and files beginning in “.”'s, typical for config files and directories (.bash_history, .bash_logout, etc.). The “ls” utility has a few dozen options for sorting based on size, date, in reverse order and so forth; “man ls” for all the details. For details on a particular file (creation date, last access, inode, etc) there is “stat”, which simply tells all the vital statistics on a given file(s), and is very useful to see if a file is in use/etc.
To manipulate files and folders we have the typical utilities like cp, mv, rm (CoPy, MoVe and ReMove), as well as tools for manipulating security information. chown is responsible for CHanging OWNership of files the user and group a given file belongs to (the group other is always other, similar to Novell or NT's 'everyone' group). chmod (CHange MODe) changes a files attributes, the basic ones being read, write and execute, as well there is setuid, setguid (set user and group id the program is run as to the ones that own it, often times root), sticky bit and so forth. With proper use of assigning users to groups, chmod and chown you can emulate ACL's to a degree, but it is far less flexible then Sun/AIX/NT's file permissions (although this is rumored for ext3). Please be especially careful with setuid/setguid as any problems in that program/script can be magnified greatly.
I thought I should also mention “find”. It find's files (essentially it will list files), and can also filter based on permissions/ownership (also on size, date, and several other criterion). A couple of quick examples for hunting down setuid/guid programs:
to find all setuid programs:
find / -perm +4000
to find all setgid programs:
find / -perm +2000
The biggest part of file security however is user permissions. In Linux a file is 'owned' by 3 separate entities, a User, a Group, and Other (which is everyone else). You can set which user owns a file and which group it belongs to by:
chown user:group object
where object is a file, directory, etc. If you want to deny execute access to all of the 3 owners simply:
chmod x="" object
where x is a|g|u|o (All/User/Group/Other), force the permissions to be equal to "" (null, nothing, no access at all) and object is a file, directory, etc. This is by far the quickest and most effective way to rip out permissions and totally deny access to users/etc (="" forces it to clear it). Remember that root can ALWAYS change file perms and view/edit/run the file, Linux does not yet provide safety to users from root (which many would argue is a good thing). Also whoever owns the directory the object is in (be they a user/group/other with appropriate perms on the parent directory) can also potentially edit permissions (and since root owns / it can make changes that can traverse down the filesystem to any location).
One thing many of us forget is that when you delete a file, it
isn’t actually gone. Even if you overwrite it, reformat the
drive, or otherwise attempt to destroy it, chances are it can be
recovered, and typically data recovery services only cost a few
thousand dollars, so it might well be worth an attackers time and
money to have it done. The trick is to scramble the data by
repeatedly flipping the magnetic bits (a.k.a. the 1’s and
0’s) so that when finished no traces of the original data
remain (i.e. magnetic bits still charged the same way they
originally were).
Two programs (both called wipe) have been written to do just
this.
wipe securely deletes data by overwriting the file multiple times with various bit patterns, i.e. all 0’s, then all 1’s. then alternating 1’s and 0’s and so forth. You can use wipe on files or on devices, if used on files remember that filename’s, creation dates, permissions and so forth will not be deleted, so make sure you wipe the device if you absolutely must remove all traces of something. You can get wipe from: http://gsu.linux.org.tr/wipe/.
This one also securely deletes data by overwriting the files multiple times, this one does not however support for wiping devices. You can get it at: http://users.erols.com/thomassr/zero/download/wipe/.
One major missing component in Linux is a filesystem with Access Control Lists (ACL’s) instead of the standard User, Group, Other with it’s dozen or so permissions. ACL’s enable you to control access to the filesystem in a much more fine grained fashion, for example on a file you may want to grant the user “bob” full access, “mary” read, the groups sales “change”, the accounting group “read”, and nothing for everyone else . Under existing Linux permissions you could not do this. Hence the need for ACL’s. The ACL stuff is currently under kernel patches.
Information is available here.
Information is available here.
The password file is arguably the most critical system file in Linux (and most other UNIX's). It contains the mappings of username, user ID and the primary group ID that person belongs to. It may also contain the actual password however it is more likely (and much more secure) to use shadow passwords to keep the passwords in /etc/shadow. This file MUST be world readable, otherwise commands even as simple as ls will fail to work properly. The GECOS field can contain such data as the real name, phone number and the like for the user, the home directory is the default directory the user gets placed in if they log in interactively, and the login shell must be an interactive shell (such as bash, or a menu program) and listed in /etc/shells for the user to log in. The format is:
username:encrypted_password:UID:GID:GECOS_field:home_directory:login_shell
Passwords are stored utilizing a one way hash (the default hash used is crypt, newer distributions support MD5 which is significantly stronger). Passwords cannot be recovered from the encrypted result, however you can attempt to find a password by using brute force to hash strings of text and compare them, once you find a match you know you have the password. This in itself is generally not a problem, the problem occurs when users choose easily guessed passwords. The most recent survey results showed that %25 of passwords could be broken in under an hour, and what is even worse is that %4 of users choose their own name as the password. Blank fields in the password field are left empty, so you would see “::”, this is something that is critical for the first four fields (name, password, uid and gid).
The shadow file holes the username and password pairs, as well as account information such as expiry date, and any other special fields. This file should be protected at all costs and only the root user should have read permission to it.
The groups file contains all the group membership information, and optional items such as group password (typically stored in gshadow on current systems), this file to must be world readable for the system to behave correctly. The format is:
groupname:encrypted_password:GID:member1,member2,member3
A group may contain no members (i.e. it is unused), a single member or multiple members, and the password is optional (and typically not used).
Similar to the password shadow file, this file contains the groups, password and members. Again, this file should be protected at all costs and only the root user should have read permission to it.
This file (/etc/login.defs) allows you to define some useful default values for various programs such as useradd and password expiry. It tends to vary slightly across distributions and even versions, but typically is well commented and tends to contain sane default values.
The shells file contains a list of valid shells, if a user’s default shell is not listed here they may not log in interactively. See the section on telnetd for more information.
This file contains a list of tty’s that root can log in from. Console tty’s are usually /dev/tty1 through /dev/tty6. Serial ports (if you want to log in as root over a modem say) are /dev/ttyS0 and up typically. If you want to allow root to login via the network (a very bad idea, use sudo) then add /dev/ttyp1 and up (if 30 users login and root tries to login root will be coming from /dev/ttyp31). Generally you should only allow root to login from /dev/tty1, and it is advisable to disable the root account altogether, before doing this however please install sudo or program that allows root access to commands.
| Written by Kurt Seifried |