Code one C Manual de usuario descargar pdf (Pagina 7)

Program LOC Description

Apache 2.0.40-21 229K An HTTP server

At 3.1.8-33 6K A program to queue jobs for later execution

BIND 9.2.1-16 279K An implementation of the Domain Name System (DNS)

OpenSSH 3.5p1-6 59K A client and a server for logging into a remote machine via the SSH protocol

Postﬁx 1.1.11-11 94K A security-oriented Mail Transport Agent

Samba 254K A Windows SMB/CIFS ﬁle server and client for Unix

Sendmail 8.12.8-4 222K A popular Mail Transport Agent

VixieCron 3.0.1-74 4K A program to maintain crontab ﬁles for individual user

Figure 6. Software packages that we checked using MOPS

erties only apply to a subset of these programs. Prop-

erty 1 and 2 only apply to either programs that are

run by the root user or setuid/setgid programs, be-

cause the OS only allows these programs to change

their user IDs or group IDs (Property 1) and to cre-

ate root jails (Property 2). Property 4 applies only to

setuid/setgid programs because an unprivileged ad-

versary can only exploit the violation of this property

by running vulnerable setuid/setgid programs, which

grant him extra privilege. Property 3 and 5 apply to

all the programs in each package.

• The running time. We calculated the running time

by summing the user time and the system time as

reported by the time command.

• The number of real error traces and total error traces.

For each package, after collecting the error traces

that MOPS reported on each program, we merged all

the equivalent traces. We consider two traces from

two different programs equivalent if both make tran-

sitions to an identical error state from an identical

non-error state at an identical program point. This is

similar to how we decide two equivalent traces within

a program (see Section 5.1.). Then, we examine each

trace manually to determine if it indicates a real bug.

A real bug means that under certain conditions an ad-

versary may exploit the bug to take control over the

system or the user’s account, to gain privileges, or to

cause the program to fail. A trace reported by MOPS

may not indicate a real bug due to the following rea-

sons:

– The trace is infeasible due to MOPS’s impre-

cise program analysis.

– Because the property is conservative, the trace

does not indicate a bug even though it violates

the property. For example, Property 1 requires

that a privileged process should not call execv

with untrusted argument. Since we cannot de-

termine if an argument is trusted statically, we

code the property to forbid a privileged process

from calling execv entirely. Therefore, even if

a privileged process calls execv with an trusted

argument, MOPS still considers it a violation

of the security property and provides an error

trace; it is up to the human to notice that this

error trace is not a real bug.

Therefore, the 5th column in each table counts only

real bugs. The 6th column counts the total number of

all error traces (whether they represent real bugs or

not).

3.4. Usability

To evaluate the usability of MOPS, we examine the

three stages in the MOPS process: (1) the user describes

a security property in an FSA; (2) the user runs MOPS

on a software package; and (3) the user analyzes the er-

ror traces from MOPS. For the ﬁrst task, once the user

formalizes a security property into a control-ﬂow cen-

tric temporal safety property, it is fairly easy to describe

it using an FSA. Although one needs to become famil-

iar with the syntax of ASTs before one can write new

FSAs, this proved to be an easy task in our experiments

– users without compiler background learned how to de-

velop new FSAs quickly by looking at examples and by

letting MOPS’s parser generate sample ASTs. For the

second task, we have written tools for integrating MOPS

into the build process of software packages that are built

by GCC. Currently, the tools are able to analyze pack-

ages distributed as .tar ﬁles or as source RPM packages.

To run MOPS on these packages, the user runs a simple

MOPS front-end and provides it with the names of the

packages and the names of FSAs, and then the tools take

care of the rest of model checking. Note that the user need

not modify any Makeﬁle in the packages (see Section 5.2.

for details). For the third task, MOPS reports all the er-

rors in the program by listing all error traces that violate

the property. Section 5.1. will describe how we improved

MOPS so that only one error trace is reported for each

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Comentarios a estos manuales

Sin comentarios

Code one C Manual de usuario Pagina 7

Comentarios a estos manuales

Relacionado con productos y manuales para Detectores de humo Code one C