680 likes | 822 Views
Lecture 4: Unix Security Basics. Asoc. Prof. Guntis Barzdins Asist. Girts Folkmanis University of Latvia Oct 8, 2004. U1 BIND Domain Name System U2 Remote Procedure Calls (RPC) U3 Apache Web Server U4 General UNIX Authentication Accounts with No Passwords or Weak Passwords
E N D
Lecture 4: Unix Security Basics Asoc.Prof. Guntis Barzdins Asist. Girts Folkmanis University of Latvia Oct 8, 2004
U1 BIND Domain Name System U2 Remote Procedure Calls (RPC) U3 Apache Web Server U4 General UNIX Authentication Accounts with No Passwords or Weak Passwords U5 Clear Text Services U6 Sendmail U7 Simple Network Management Protocol (SNMP) U8 Secure Shell (SSH) U9 Misconfiguration of Enterprise Services NIS/NFS U10 Open Secure Sockets Layer (SSL) Top UNIX Vulnerabilities Source: http://www.sans.org/top20/#threats
20 FTP (data) 21 FTP (control) 23 Telnet 25 SMTP (mail) 70 Gopher 79 Finger 80 HTTP also 8000 or 8001 or 8080 110 Pop3 119 NNTP (news) 143 Imap 7-19 echo, discard, daytime, chargen, netstat 22 SSH 42 wins 53 dns 111 sun rpc 113 identd 123 ntp 135 loc-srv/epmap – used to attack wintel 137-139 netbios 161 snmp 512-517 rexec, rlogin, rsh, talk, syslog, who 635 mountd – Linux 2049 nfs 6670 Deepthroat 31337 BackOrifice Favourite TCP Ports
No system is perfectly secure, but still we need security • A number of toolkits exist that allow total amateurs to become holy terrors. • The good news is that if you can beat the popular intrusion toolkits, 90 percent of the bad guys will go bother somebody else who's less secure.
Protection • Operating system consists of a collection of objects, hardware or software • Each object has a unique name and can be accessed through a well-defined set of operations. • Protection problem - ensure that each object is accessed through correct set of operations and only by those processes that are allowed to do so.
UNIX Security Basics • Permissions • UID • GID • Superuser • SUID, SGID • Sticky bit • Umask • Filesystem restrictions • Advanced: Systrace, Veriexec, iptables, etc.
Domain Implementation in UNIX • Two domain groups • User • Superuser (can do everything, UID=0) • User domain group • Domain = user-id (UID) • Domain switch accomplished via file system. • Each file has associated with it a domain bit (setuid bit = SUID bit). • When file is executed and setuid = on, then effective user-id is set to owner of the file being executed. When execution completes user-id is reset (exit() for child process ).
Subjects and Objects • Each subject (process) and object (file, socket, etc) has a 16-bit UID. • Each object also has a 16-bit GID and each subject has one or more GIDs. • Objects have access control lists that specify read, write, and execute permissions for user, group, and world. • Super-users (uid=0 root) can do anything.
Subjects and Objects Objects = files (regular and devices /dev) Subjects = processes(effective UID, GID counts)
inodes • inodes contain a lot of information about a file • mode and type of file • number of links to the file • owner's UID • owners GID • number of bytes in file • times (last accessed, modified, inode changed) • physical disk addresses (direct and indirect blocks) • number of blocks • access information
Directory • Under UNIX directories are special (OS writable only) files. • The directory file is an unsorted linked list of filenames to file-inode (attributes and location of file on hard disk) • Directory size will always increase to be large enough to hold all the file entries. If the number of files latter shrinks the directory size WILL NOT!
ls -l > ls -l foo -rw-rw---- 1 hollingd grads 13 Jan 10 23:05 foo size permissions name owner group time
File Time Attributes • Time Attributes: • when the file was last changed ls -l • when the file was created* ls -lc • when the file was last read (accessed) ls -ul *actually it’s the time the file status in the directory last changed (e.g. file renamed).
Types of Files • Regular Files • binary • GIF, JPEG, Executable etc. • text • scripts, program source code, documentation • Supports sequential and random access
Types of Files (cont.) • Directory • Can contain ANY kind of files . (Dot)The special name for the current directory. ..(Dot) (Dot)The special name for the directory above the current directory. • Device File • Allows programs to communicate with hardware. • Kernel modules handle device management.
Types of Files (cont.) • Device Files (cont.) • Character Device • Accepts a stream of characters, without regard to any block structure. • It is not addressable, therefore no seek operation • Block Device • Information stored in fixed-sized block • It is addressable, therefore seek operation is possible.
Types of Files (cont.) • UNIX Domain Sockets (BSD) • sockets that are local to a particular host and are referenced through a file system object rather than a network port. • X windows • Named Pipe • Allow processes to communicate with each other.
Types of Files (cont.) • Hard links • Linking files by reference • System maintains a count of the number of links • Does not work across file systems. • Soft links • Linking files by name • No counter is maintained • Work across file system
From “man ln” • There are two concepts of `link' in Unix, usually called hard linkand soft link • A hard link is just a name for a file. (And a filecan have several names. It is deleted from disk only when the lastname is removed. The number of names is given by ls(1). There isno such thing as an `original' name: all names have the same status. • A soft link (or symbolic link, or symlink) is an entirely different animal: it is a small special file that contains a pathname.
Creating a Link • Create a link directory by typing the following command from your home directory: % ln -s /home/faculty/ostic/prof myprof • You only need to create this link once.It will appear as a subdirectory in your home directory structure every time you log on to the system. soft link
bin etc users tmp usr Disk vs. Filesystem • The entire hierarchy can actually include many disk drives. • some directories can be on other computers / hollid2 scully
Disk mount options • Override individual file permissions • A major security tool in Unix
File permissions File type - : plain file d : directory c : character device (tty, printer) b : block device (disk, CD-ROM) l : symbolic link s : socket =, p : FIFO Access granted to others -rwxr--r-- Access granted to group member Access granted to owner r : read / w : write / x : execute
Permissions for Files • If you have read permission for a file, you can view its contents. • If you have write permission for a file, you can alter its contents. • If you have execute permission for a file, you can run the file as a program.
Permissions for Directories • If you have read permission for a directory, you can list the contents of the directory. • If you have write permission for a directory, you can create or remove files or directories inside that directory. • If you have execute permission for a directory, you can change to this directory using the cd command, or use it as part of a pathname.
SUID/SGID/sticky bits • SUID (set uid) • Processes are granted access to system resources based on user who owns the file. • SGID (set gid) • (For file) Same with SUID except group is affected. • (For directory) Files created in that directory will have their group set to the directory's group. • sticky bit • If set on a directory, then a user may only delete files that he owns or for which he has explicit write permission granted, even when he has write access to the directory. (e.g. /tmp )
File Permissions • File Permissions (ex: rw-r--r--) • owner: rw-, group: r--, others: r-- • r: read, w: write, x: execute • When a process executes, it has four values related to file permission • a real user ID, an effective user ID • a real group ID, an effective group ID • When you login, your login shell process’ values are your user ID and group ID
Effective User and Group ID • A process’ effective user ID • depends on who executes the process, not who owns the executable • E.g., if you run passwd (owned by root), the effective user ID is your ID, not root; then how can it update /etc/passwd file owned by root ? • Two special file permissions • set user ID and set group ID • When an executable with set user ID permission is executed, the process’ effective user ID becomes that of executable; the real user ID is unaffected • File permission of /bin/passwd is r-sr-sr-x
Real uids • The uid of the user who started the program is used as its real uid. • The real uid affects what the program can do (e.g. create, delete files). • For example, the uid of /usr/bin/vi is root: • $ls -alt /usr/bin/vilrwxrwxrwx 1 root root 20 Apr 13... • But when I use vi, its real uid is dkl (not root), so I can only edit my files.
Effective uids • Programs can change to use the effective uid • the uid of the program owner • e.g. the passwd program changes to use its effective uid (root) so that it can edit the /etc/passwd file • SUID bit enables this functionality
Real and Effective Group-ids • There are also real and effective group-ids. • Usually a program uses the real group-id(i.e. the group-id of the user). • Sometimes useful to use effective group-id(i.e. group-id of program owner): • e.g. software shared across teams • SGID bit enables this functionality
Sample SETUID Scenario • /dev/lp is owned by root with protection rw------- • This is used to access the printer • /bin/lp is owned by root withrwsr-xr-x (with SETUID=1) • User A issues a print command • Shell (running with A’s UID and GID) interprets the command and forks off a child process, say, P • Process P has the same UID/GID as user A • Child process P executes exec(“/bin/lp”,…) • Now P’s domain changes to root’s UID • Consequently, /dev/lp can be accessed to print • When /bin/lp terminates so does P • Parent shell never got the access to /dev/lp
File system tips • Turning off SUID / SGID in mounted file system • use nosuid (and nodev if possible) when mounting remote file system or allowing users to mount floppies or CD-ROMs • Finding SUID and SGID Files • # find / \( -local -o -prune \) \( -perm -004000 -o -perm -002000 \) -type f -print • ( xdev can be used in place of local/prune)
Unix Accounts • To access a Unix system you need to have an account. • Unix account includes: • username and password • userid and groupid • home directory • shell
Creating user accounts • useradd or adduser scripts • manually • edit /etc/passwd, etc/shadow, etc/group • remember to lock these files while editing - vipw • run “passwd [user]” • create home directory • chown, chgrp, chmod • copy defaults (e.g umod) from • /etc/skel • /etc/profile
username • A username is (typically) a sequence of alphanumeric characters of length no more than 8. • username the primary identifying attribute of your account. • username is (usually) used as a part of email address • the name of your home directory is usually related to your username.
password • a password is a secret string that only the user knows (not even the system knows!) • When you enter your password the system calculates a hash (one-way) function and compares it to a stored string. • passwords are (usually) no less than 8 characters long. • It's a good idea to include numbers and/or special characters (don't use an english word!)
userid • a userid is a number (a 16-bit integer) that identifies a Unix account. Each userid is unique. • It's easier (and more efficient) for the system to use a number than a string like the username. • You don't need to know your userid!
Unix Groups and groupid • Unix includes the notion of a "group" of users. • A Unix group can share files and active processes. • Each account is assigned a "primary" group. • The groupid is a number that corresponds to this primary group. • A single account can belong to many groups (but has only one primary group).
Home Directory • A home directory is a place in the file system where the account files are stored. • A directory is like a Windows folder (more on this later). • Many unix commands and applications make use of the account home directory (as a place to look for customization files).
Shell • A Shell is a unix program that provides an interactive session - a text-based user interface. • When you log in to a Unix system the program you initially interact with is your shell. • There are a number of popular shells that are available.
Popular Shells sh Bourne Shell ksh Korn Shell csh C Shell bash Bourne-Again Shell
Startup files sh,ksh: /etc/profile (system defaults) ~/.profile bash: ~/.bash_profile ~/.bashrc ~/.bash_logout csh: ~/.cshrc ~/.login ~/.logout