[soen321-f04] material for week 3 (Sep 27)[soen321-f04] material for week 3 (Sep 27) David K. Probst PROBST at vax2.concordia.ca Mon Sep 27 19:26:31 EDT 2004 Previous message: [soen321-f04] Unix considered harmful (Sep 27) Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] SOEN 321 Week 3 Lecture Material _________________________________ Much of security depends on access control. In the Unix security model, access control is determined by how much privilege a process has. There are mechanisms to raise and lower the privilege level while a process is running. These mechanisms are trustworthy provided they allow us to raise and lower privilege in a safe and controlled manner. In Unix, one of the most important of these mechanisms is the 'setuid' instruction. Setuid subtleties _________________ Access control in Unix is mainly based on the set of user IDs associated with a process. This set determines which system resources, such as files and network ports, can be accessed by the process. Certain privileged user IDs allow a process to access restricted system resources; in particular, user ID zero (0), reserved for the superuser 'root', allows a process to access all system resources. In some applications, a user process needs extra privilege, such as permission to write the password file. By the Principle of Least Privilege, the process should drop its privileges as soon as possible to minimize risk to the system just in case it is compromised and executes malicious code while still running with high privilege. Unix has a set of system calls to raise and drop privileges. These things are so complicated, you practically have to apply formal methods to very simple models (abstractions of the calls) to understand them and spot bugs in code that uses them. The are three user IDs: the real user ID, the effective user ID, and the saved user ID. It is the effective user ID that is used in most access-control decisions. The real ID is determined by the owner while the saved ID is a temporary copy of the effective user ID that can be saved at some point and restored later. IDs are divided into 'user' and 'group' IDs. The 'fork' command provides for simple inheritance of the set of user IDs; the forked process has the same set of user IDs and the same set of group IDs. In contrast, 'exec (file)', where 'file' is an executable, either: - does nothing to the permissions, or - if the suid bit of the file is set, then the effective user ID and the saved user ID of the process get the user ID of the _owner_ of the file Since access control is based on the effective uid, a process gains privilege bu assigning a privileged uid to its effective uid and drops privilege by removing the privileged uid from its effective uid. "Exec () has one set of rules, but a process can't call 'setuid ()' unless it has "appropriate privilege". Roughly, this means being root. Precisely what it means depends on the Unix flavor. Example: Sendmail is a commonly used MTA. It runs in two modes: 1) as a daemon that listens on port 25 (SMTP), and 2) via an MUA to submit mail to the mail queue. In the first case, all uids are zero. In the second case, sendmail is run by an ordinary user. Since the mail queue is not world writable, special privilege is temporarily required. The sendmail 8.10.1 binary was configured as an suid-root executable. If executed by an ordinary process, it ran with an effective uid of zero. The sendmail program would drop root privilege before doing potentially dangerous operations requested by the user. But, prior to Linux 2.2.16, the designers of the kernel completely forgot about the saved uid; setuid changed the effective uid but made no change to the saved uid. Thus, using one of the standard compromise techniques, e.g., causing a buffer overflow, a hacker who compromised sendmail could easily restore the saved uid. Example: In version 8.12.0, sendmail was no longer installed as suid-root. Instead, the mail queue was writable by group smmsp and the binary was installed as sgid-smmsp. As before, it is prudent to drop smmsp group privilege as soon as possible. But sendmail, at this point, does not have _appropriate privilege_ to do so (i.e., change the effective uid) so a similar bug applies. The Internet changes everything _______________________________ Because the hosts in a LAN are managed by the sysadmin, because the network is physically and logically under control, because machine and routers are locked in machine rooms, because places to plug into are identified, because the software is installed and configured by the sysadmin, etc., etc., we have some idea about the trustworthiness inside the local network. About things in the Internet, we have neither knowledge or control. At first blush, we trust absolutely nothing. For example, a big problem is proving identities across the Internet. Since total paranoia is not viable, we must build "trust servers" into the net, and design protocols to bootstrap this trust. Protection and OS Security (cont) __________________________ The growth of the Internet has increased the risk of serious attacks on critical systems. The reason is two-fold: 1) there are far more entities that can potentially access your system, and 2) the accesses themselves are increasingly hetereogeneous. A common theme underlying many successful exploitations of system vulnerabilities is inadequate authentication of programs and data exchanged over the Internet. A program may be untrusted (and untrustworthy) for one of two reasons: - we may suspect the code of being malicious - we may suspect the code of being vulnerable (i.e., unable to defend itself against adversarial input) Authentication matters so much because unauthenticated code could easily have been constructed by an adversary. At the same time, much of the software we reasonably run is not very good at handling adversarial input, and our operating systems are not very good at containining successful intrusions behind impervious bulwarks. For this reason, one central security problem is, how do we reduce the harmful effects of a security compromise? One of several suggestions is to confine untrusted software, of either variety, inside a semiporous sandbox that monitors and restricts the system calls the software performs. Why might we fail to trust an application? We might know nothing of its source, or we might know the source quite well but not have a high opinion of the source's programming skill or integrity. An application may be well sourced but still untrusted if it is both exposed to outside attack and yet not trusted to protect itself against adversarial input. Such is the expected case for any application whose complexity exceeds a certain threshold. The application might not be malicious, and yet it could prove to be a weak link in the security chain. Sometimes, though, untrusted software is simply too convenient or too widespread to reasonably avoid, and we must learn to manage the risk. Let us use the word "compromise" for the successful exploitation of a system vulnerability. Any security suite should be an appropriate mix of compromise-avoiding mechanisms (self-explanatory), compromise-tolerating mechanisms (error confinement), and compromise detection and damage recovery mechanisms. These distinctions are more or less hard. Confinement of untrusted applications is one form of compromise avoidance. The security requirement is that an outsider who has control over the untrusted application must not be able to compromise the CIA^2 of the rest of the system, including the user's files or account. Any damage must be limited to short-lived objects manipulated by the application. The application must be granted the minimum set of capabilities required to perform its legitimate duties (Principle of Least Privilege). Without some special mechanism, an unprotected Unix application that is compromised will very likely soon inherit all the privileges of the account in which it is running. In Unix, privilege is process based more than it is account based. What is the range of security mechanisms that we might use for compromise avoidance? We will mention several. One can draw a diagram that shows the different mechanisms as different places to errect a barrier to filter adversarial inputs. It is shown below: <--- use a network firewall ______________ | | | firewall | | | -------------- <--- harden all untrusted applications ______________ | | | Netscape | | | -------------- ______________ | | | sendmail | | | -------------- <--- confine untrusted applications ______________ | | | OS | | | -------------- <--- use powerful security features in the OS kernel ______________ | | | OS kernel | | | -------------- <--- build strong security hooks into the hardware ______________ | | | h/w | | | -------------- Approach 1: Harden each and every untrusted application or engineer security patches one at a time to close each newly discovered vulnerabilitiy. (This is a mentally and physically exhausting arms race between defenders and attackers, at least for systems of any complexity). Security experts used to joke (bitterly) about sendmail's "bug of the month". Even if you escape from sendmail, can you escape from Netscape (and vice versa)? Most of us cannot. We are stuck with many useful programs that offer only minimal assurances of security. Approach 2: Build more powerful features into the security kernel of the operating system. This is involved both technically and politically. An ordinary organization would probably not risk doing this themselves. New security kernels must come from vendors or from the open-source community, and probably require federal funding and jaw-boning. Approach 3: Reference monitors in traditional operating systems fail even to protect a penetration from spreading to new accounts; very often, once one account has been subverted, the whole system typically falls soon after. My security idiocy (if I helped the attacker by doing something stupid) beggars my local-area-network neighbor. We need more research to understand whether this rule applies at larger scale, e.g., hierarchically and recursively. Approach 4: Install powerful firewalls. This is often less of a panacea than it looks. Packet filters cannot distinguish between different types of http traffic, let alone analyze incoming data or embedded mobile code for security threats. Perhaps a proxy firewall could do some of this, but it would be quite elaborate. Approach 5: Use Java security to run untrusted Java applications (perhaps signed applets). Many security researchers have concerns about Java's ability to contain mobile code with high assurance. The Java story has yet to play itself out. Approach 6: Employ proof-carying code. In this approach, the compiler generates object code that establishes to the satisfaction of a runtime verifier that it (the object code) satisfies some security policy. This is a bit advanced at present. So, how satisfactory is confinement of untrusted applications in a carefully sanitized space? Note: rational security professionals like defense in depth for compromise avoidance plus some form of compromise tolerance. But various security religions have developed in the security community. Lemma 4. An application can do little harm if its access to the underlying operating system is appropriately restricted. So the strategy would be: design a user-level mechanism that monitors an untrusted application and disallows harmful system calls. This can be bootstrapped into full CIA^2 protection. We would need the moral equivalent of a hierarchical expert system. One rule is surely: Write access to '.rhosts' is universally denied. We would need operating-system process-tracing hooks, often provided in debuggers. We would depend on the OS to enforce some minimal protection properties, e.g., protect the confinement monitor from the untrusted application it monitors. Lemma 5: The are fewer holes in OS security kernels than there are in applications. A rough outline of a sandbox security policy might be: - sandboxed processes may fork - they may signal "internally" - they must live in a sanitized sandbox directory in which 'cd' is forbidden - X is tricky Note that 'chroot' can help control file-system access reliably, but is powerless to control network access. Techniques for handling networked access by sandboxed applications can be adapted from ideas pioneered in the firewalls community. Web browsers are specially problematic because of the extensive privilege they need to do their authorized job. Finally, even a program running as root can be filtered. Previous message: [soen321-f04] Unix considered harmful (Sep 27) Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] More information about the soen321-f04 mailing list