Code one C Manuel d'utilisateur télécharger pdf (Page 4)

calls are safe. So we check the following property, which

is a good approximation of the desired behavior (see Fig-

ure 2):

Property 1 A process should drop privilege from all its

user IDs before calling

execl

popen

system

, or any

of their relatives.

We decompose this property into two FSAs. The ﬁrst

one describes which user IDs of the process carry privi-

lege (Figure 2(a)) and the second one describes whether

the process has called the execl, popen, and system

(Figure 2(b)

). Decomposition makes each FSA simpler

and also allows the user to reuse FSAs (if the user wants

to describe another property that involves privilege, he can

reuse the FSA in Figure 2(a)). MOPS automatically com-

putes the the parallel composition of the two FSAs, which

represents the integrated property.

3.1.2. Create Chroot Jails Securely

chroot is a system call that allows a process to conﬁne

itself to a sub-ﬁlesystem, called a chroot jail. To create

a jail securely, the process should observe the following

property (see Figure 3(a)):

Property 2 After calling

chroot

, a process should im-

mediately call

chdir("/")

to change its working direc-

tory to the root of the sub-ﬁlesystem.

The program in Figure 3(b) violates this property

because it fails to call chdir("/") after chroot

("/var/ftp/pub"), so its current directory remains

/var/ftp. As a result, a malicious user may ask the pro-

gram to open the ﬁle ../../etc/passwd successfully even

though this is outside the chroot jail and the programmer

probably intended to make it inaccessible. Here, the ma-

licious user takes advantage of the method by which the

operating system enforces chroot(new

root). When

a process requests access to a ﬁle, the operating system

follows every directory component in the path of the ﬁle

sequentially to locate the ﬁle. If the operating system has

followed into the directory new

root and if the next di-

rectory name in the path is “..”, then “..” is ignored. How-

ever, in the above example, since the current directory is

/var/ftp, the path ../../etc/passwd never comes across the

new root /var/ftp/pub and is therefore followed success-

fully by the operating system. In short, the chroot sys-

tem call has subtle traps for the unwary, and Property 2

encodes a safe style of programming that avoids some of

these traps.

Although the transition from the state “after exec” to the state “be-

fore exec” is optional for this property, it enables MOPS to ﬁnd all the

risky system calls if a trace contains multiple such calls; without this

transition MOPS can only ﬁnd the ﬁrst call on the trace.

chroot

other

chdir("/")

other

(a) An FSA describing Property 2

chroot(“/var/ftp/pub”);

ﬁlename = read

from network();

fd = open(ﬁlename, O

RDONLY);

(b) A program segment violating Property 2. Note that the

program fails to call chdir("/") after chroot(),soif

filename is “../../etc/passwd”, a security violation ensues.

Figure 3. An FSA illustrating Property 2

(“

chroot()

must always be immediately followed

chdir("/")

”) and a program violating it.

3.1.3. Avoid Race Conditions When Accessing the

File System

When a process accesses a ﬁle by its name, the process

should avoid race conditions, which are potential security

vulnerabilities [5]. As an example, consider a privileged

process that runs on behalf of a normal user and that wants

to constrain itself to access only ﬁles owned by the nor-

mal user. A naive implementation might use two steps:

(1) call stat("foo") to identify the owner of the ﬁle

foo; (2) only open the ﬁle if it is owned by the current

user. This strategy, however, is insecure because of a race

condition: an attacker may change the ﬁle associated with

the name foo (e.g., through modifying a symbolic link)

between the stat("foo") and open("foo") calls.

The program in Figure 4(b) illustrates this race condition.

Suppose the ﬁlename foo in the variable logfile ini-

tially is a symbolic link to a ﬁle owned by the attacker.

When stat(logfile, &st) is called, the program

veriﬁes that the attacker is the owner of the ﬁle. But

before the program proceeds to open the ﬁle by calling

open(logfile, O

RDWR), the attacker changes foo

to be a symbolic link to /etc/passwd, a ﬁle that should

not be writable to him. So open(logfile, O

RDWR)

ends up opening /etc/passwd for him in read/write mode.

We see that race conditions in privileged processes may

be exploited by an adversary to gain control over the sys-

tem. Moreover, race conditions in unprivileged processes

may also be exploited by an adversary to penetrate the ac-

count of the user that runs the vulnerable processes. A

conservative approach for detecting race conditions is to

check if the program passes the same ﬁle name to two

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

Commentaires sur ces manuels

Pas de commentaire

Code one C Manuel d'utilisateur Page 4

Commentaires sur ces manuels

Produits connexes et manuels pour Détecteurs de fumée Code one C