Thus the application knows an upper bound on the senders send label In our file

Thus the application knows an upper bound on the

This preview shows page 6 - 7 out of 14 pages.

tion when the message is received. Thus, the application knows an upper bound on the sender’s send label. In our file server example, a process writing u ’s file must supply V = { u G 0 , 3 } to prove it speaks for u . The file server, in turn, verifies the process speaks for u by checking V ( u G ) 0 before accepting a write to u ’s file. An alternative design might eliminate V and just supply message recipients with a copy of the sender’s send label—in effect, con- veying all of a process’s credentials with every message it sends. However, such designs lead to security problems in which an at- tacker can trick a process into exercising unintended privileges, a pitfall known as the confused deputy problem [12]. In our example, a process that speaks for multiple users must explicitly name the credentials it intends to exercise for each write. Level 0 and mandatory integrity The 0 level permits the con- struction of mandatory integrity policies. For example, a process P with P S ( u G ) = 0 can speak for u , but since 0 is less than the de- fault send level of 1 , it cannot further disseminate the privilege: the minute P receives a message from a process Q that does not speak for u ( Q S ( u G ) 1 ), P S will become tainted and P will lose its abil- ity to speak for u . Thus, P cannot act for Q and relay low-integrity data into u ’s files. As with secrecy, different defaults in send and receive labels al- low targeted exclusion of particular processes. An example is pre- venting system files from being corrupted from the network. The file server can allocate a compartment, s , and require V ( s ) 1 for writes to system files. Setting the network daemon’s send label to { s 2 , 1 } then ensures that no process contaminated with data from the network can overwrite system files. 5.5 Capabilities and preventing contamination The discretionary verification label can be used to implement many application-defined security policies, but it is limited in one impor- tant way: An application can choose to ignore a message after ex- amining V , but since the message was already delivered (to allow V to be examined), the application’s labels have already been con- taminated with the message’s taint. In general this taint cannot be undone. Thus, V can flexibly verify integrity but cannot prevent in- appropriate contamination. Imagine, for example, a mail reader that starts an untrusted program to read an attachment. The mail reader can, and should, accept contamination from other system processes, such as the file system; but though it needs to communicate with the attachment program, it doesn’t want to accept contamination from it. A compromised attachment that develops a high taint should lose the ability to send to the mail reader. What is needed is a way to shift a simple form of message filter- ing into the kernel. Asbestos supports this in a straightforward way by integrating communication ports with the label system. The re- sult not only prevents undesired contamination but also ends up providing the semantics of capability-based send rights.
Image of page 6
Image of page 7

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture