Chapter 12 Privileged Programs Synopsis Why Privileged Programs

Chapter 12 Privileged Programs

Synopsis Why Privileged Programs Possible attacks on privilege Managing Privilege

Why Privileged Programs? (This chapter is very Unix specific) Principle of Least Privilege: “Every program and every user should operate using the least set of privileges necesary to complete the job. ” Means no user should have administrator privileges by default. They only acquire them when they need them, and only when they are running the program that needs the privileges. These programs are privileged programs, aka setuid programs.

Why do we need privileges? Talking directly to hardware Modifying the OS behavior Sending signals to certain processes Working with shared resources Opening restricted network ports Altering global configurations Overriding filesystem protections Installing files in system directories Updating protected files Accessing files that belong to other users.

Possible attacks on Privilege

Privilege Escalation Attacks and defenses Often second stage of a two stage attack. Could also be carried out by a legitimate user. Will cover: Race conditions Access Control Managing Privilege: set uid calls Some general advice Chroot jails Weak file permissions Safe directories Insecure temporary files Command injection Misuse of standard file descriptors.

Managing Privilege: set uid calls Each process has three uid's associated with it: Real uid – uid of program caller Effective uid – uid used for access decisions Saved uid – recoverable uid Vary from Unix version to unix version. Choose from: setuid(uid) (sets euid, unless euid = 0) seteuid(euid) setreuid(ruid, euid) setresuid(ruid, euid, suid) Last two can use -1 to leave value unchanged. Get with int getresuid(uid_t *ruid, uid_t *euid, uid_t *suid);

Privileges for files on linux Linux provides two additional system calls: setfsuid(uid_t fsuid); setfsgid(uid_t fsgid); They both return the old value of the fsuid/fsgid. Setting the euid changes the fsuid to that value.

Use of access(2) Int access(pathname, mode) Is tempting: check is made against the real uid Advice: don't use: subject to race conditions: if you want to open a file with privileges of the invoking user, drop privileges temporarily.

Some General Advice MISTRUST EVERYTHING!!! Command line arguments Environment File System Race conditions Weak file permissions Unsafe directories Bad temporary files Bad standard file descriptors Disable all signals Trap all signals which would otherwise be ignored Beware of unexpected events: Check for EVERY error condition, every return code. Die on errors

chroot Changes the meaning of / Is drastic: anything outside of the new / is unreachable Use ldd and strace to trace dependencies Use mknod or MAKEDEV to create necesary devices. Chroot doesn't close files, or change dir. It can also fail. NEVER LET THE CHROOTED PROCESS RUN AS ROOT!!!!!

Insecure Directories The only safe way to do file work is work on safe directories. A safe directory is a directory of which it and its ancestors are only writable by root and the process. Pages 445 -446 contain the code to create such a directory

Insecure Temporary Files Generating file names with mktemp, tmpnam, tempnam is insecure. The function tmpfile is also insecure, since, if the file exists already, it is only truncated; nothing else is changed. Mkstemp generates a unique file name, opens it, if it can, with mode 0600 and O_EXCL flag. If it cannot open the file, it returns -1. Umask of 077 is a good idea, though.