CS 480 Lec 2 FA22
CS 480 M01 Lecture Notes 2 - Aug 24, 2022
Last Time
Chapter 1. Where to Start
- Administrator's tasks
- Suggested Background
- user level exp with Linux or UNIX, editors (vi), programming / scripting
- Linux/Unix relationship
- Distributions
- Notes:
vi/vim - vimtutor
stripped file - file with discarded symbols and other data from it (no debug info)
Chapter 1. Where to Start Continued
Units
kilo-, mega-, and giga - defined as powers of 10 (but still used to refer to powers of 2)
New: kibi-, mebi-, gibi-, and so on, ( Ki, Mi, and Gi) based explicitly on powers of 2
Most of the world today still doesn't care ....
Where To Go For Info
google may not always give you the best or authoritative resource ...
- man pages - READ THE BOOK
- Distribution specific docs / System-specific guides (openSuSE, RHEL, ...)
- Package/Software-specific documentation and related web pages
(Apache HTTP Server,
Subversion,
openLDAP,
git,...)
- Books (O'Reilly series, ...)
- RFCs
- other resources listed below (and much much more ...)
Links:
Ch 3. Access Control and Rootly Powers
Mechanics of how the kernel and its delegates make security-related decisions.
Active research, many changes and new options added in recent years
Traditional basics and fundamentals first ...
Standard / Traditional UNIX Access Control
- There was never a single-point access control system - but general system's design rules:
- Access control decisions based on which user (and his/her groups membership) is attempting an operation.
- Objects (files and processes) have owners.
- Owners have broad (not unrestricted) control over their objects.
- User owns objects he/she created
- Special user root can act as the owner of any object.
- Only root can perform certain sensitive administrative operations.
Different system calls make different access control decisions ( settimeofday - root or not X kill - more involved)
system call - request to the kernel by an active process for a service performed by the kernel (create process, I/O operation, ...)
system call X wrapper functions in glibc
kernel/user mode - just these 2 in Linux,Windows,... (utilizing CPU modes) ; only 1 mode in DOS
mode switch (user/kernel) X
context switch (diff process executed by scheduler) - often confused as in "man vdso"
- Filesystem with its own access control:
- Every file or process is OWNED by a user (& group) : UID, GID (IDs mapped to names in /etc/passwd or /etc/group)
Owner of a file specifies what the group owners can do with the file
- root / superuser - owns system files & processes
- file permissions (ls -l ) - owner can change them
Process ownership:
owner can send signals and change scheduling priority (kill, nice)
- real uid - accounting (not used that much anymore)
- & effective uid - access permissions
normally they are the same
- also saved UID (process can enter / leave privileged mode of operation
- passwd, ...)
and filesystem UID (Linux)
root (superuser) UID == 0
root is permitted (= a process with effectiveUID == 0) all valid operations
chroot, create device files, set time, configure network, hostname, shutting down, open privileged network port,sending signal to all processes, ...
changing UID or GID (one way only : root ==> normal user, not back) - login
Setuid and setguid execution - identity substitution implemented by kernel & FS in collaboration
Allows regular (not root) user to execute privileged operations
suid/sgid permissions set on a command => changes effective uid/gid of the executing process
ex.: passwd executed by regular user changes /etc/shadow
try passwd and in another shell ps axo stat,euid,ruid,tty,ppid,pid,pcpu,pmem,args | egrep '(STAT|passwd)'
suid/sgid programs are prone to security problems => can disable on a file-system when mounting (nosuid)
Becoming a root
- Can log in directly BUT
- no record of what operations were done (semi true) - bad as you may not remember what you messed up , worse if unauthorized access ...
- not clear who made the change if more then one sysadmin
- => allow login on console only
- su (use full path !) - logged
- sudo (+sudoers) - logs commands executed
- READ THE BOOK ! p. 70-77
- again - full path to commands
- advantages/disadvantages
- Accountability thanks to logging
- Operators do not need full root access
- Only few users need to know real root password
- faster then su + command
- revoking privileges without changing root's password
- list of privileged users is maintained
- single file to control access for the whole domain / network
- X
- breach of individual account can be equivalent to breach of root's account
- escaping sudo's command logging
Next:
Password,
Extensions to Standard Access Control Model,
Modern Access Control,
Other Special Pseudo Users,
Perl Warm-Up