Code one C Instrukcja Użytkownika Pobierz pdf (Strona 3)

MOPS is unsuitable for checking concurrent pro-

grams.

• The program is memory safe, e.g., no buffer over-

runs.

• The program is portable. For instance, MOPS does

not understand inline assembly code.

• The program does not violate the soundness assump-

tions required by the property. Some properties are

sound only under certain assumptions about the pro-

gram. For example, to enable the user to express the

property “do not call open() after calling stat()

on the same ﬁle name”, MOPS allows the user to de-

clare a generic pattern variable f to create the FSA

shown in Figure 4. In that FSA, the variable f in

stat(f) and open(f) is a generic pattern vari-

able — it refers to any variable that is syntactically

used in both stat() and open(). Since this is

syntactic matching, it does not survive aliasing: if the

program contains “stat(x); y=x; open(y)”,

then MOPS does not know that y is an alias of x,so

the property is not sound for this program.

In addition, the current version of MOPS does not con-

sider control ﬂows that are not in the CFG, such as indi-

rect calls via function pointer, signal handlers, long jumps

(setjmp()/longjmp()), and libraries loaded at run-

time (dlopen()). Although these may cause unsound-

ness, they are implementation limitations rather than in-

trinsic difﬁculties.

2.2. Completeness

Since any nontrivial property about the language rec-

ognized by a Turing machine is undecidable (Rice’s

Theorem[16]), no tool that checks a nontrivial property

can be both sound and complete. Because MOPS strives

to be sound, it is inevitably incomplete in that MOPS may

generate false positive traces, i.e., program traces that are

either infeasible or that do not violate the property. Un-

fortunately, large numbers of false positive traces would

overwhelm the user easily; therefore, it is essential to

avoid generating too many false positives. We will dis-

cuss how MOPS reduces false positive traces while not

sacriﬁcing soundness in Section 5.1.

3. Experiments

We designed the experiments to evaluate three objec-

tives of MOPS. To be useful, MOPS ought to be able to

(1) check a variety of security properties; (2) check large

programs; and (3) be usable — it should run fast, require a

moderate amount of memory, and generate a manageable

number of false positive traces.

3.1. Security Properties

We selected ﬁve important security properties that are

non-trivial and that have been violated repeatedly in the

past. We will show how we expressed them in a formal

language suitable for input to MOPS.

3.1.1. Drop Privileges Properly

Access control in Unix systems is mostly based on user

IDs (uids). On most Unix systems, each process has three

user IDs: the real user ID (ruid), the effective user ID

(euid), and the saved user ID (suid). The real uid identiﬁes

the owner of the process, the effective uid represents the

privilege of the process such as its permission to access

the ﬁle system, and the saved uid is used by the process

to swap between a privileged uid and an unprivileged one.

Different user ID values carry different privileges. The uid

0, reserved for the superuser root, carries full privileges:

it gives the process complete control over the machine.

Some non-zero user IDs carry privileges as well. For ex-

ample, the user ID daemon grants the process the privilege

of accessing the spools used by atd. Most user processes

have no privileges

. However, a class of programs called

setuid programs allow the user to run a process with extra

privileges. For example, passwd is a program that allows

a user to change his password, so the program needs ex-

tra privilege to write to the password ﬁle. This program

is setuid-root, which means that when a user runs the pro-

gram, the real uid of the process is still the user, but both

the effective and saved uid of the process are root, a privi-

leged user ID.

A process modiﬁes its user IDs by a set of system

calls, such as setuid, seteuid, setreuid, and

setresuid. By the principle of least privilege, if the

process starts with a privileged user ID, it should drop the

privilege permanently — by removing the privileged user

ID from its real uid, effective uid, and saved uid — as

soon as it no longer needs the privilege. Otherwise, if a

malicious user takes control over the process, e.g. by a

buffer overrun, he can restore the privileged user ID into

the effective uid and thus regain the privilege. For fur-

ther treatment on this topic, we refer the interested reader

elsewhere [7].

Since where to drop privilege permanently is appli-

cation speciﬁc, it is difﬁcult for an automated tool like

MOPS to check this property automatically without know-

ing the design of each application. Nevertheless, a process

should permanently drop privileges before making certain

system calls, such as execl, popen, and system, un-

less the process has veriﬁed that the arguments to these

Since each process always has the privilege of its owner, this priv-

ilege is uninteresting from the security point of view and will not be

considered as a special privilege further on.

1 2 3 4 5 6 7 8 ... 14 15

Komentarze do niniejszej Instrukcji

Brak uwag

Code one C Instrukcja Użytkownika Strona 3

Komentarze do niniejszej Instrukcji

Powiązane produkty i podręczniki dla Wykrywacze dymu Code one C