SELinux [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

SELinux [Electronic resources] - نسخه متنی

Bill McCarty

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید








2.4 Access Decisions


The SELinux security server makes two basic kinds of decisions:

Access decisions


Access decisions determine whether a given
subject is allowed to perform a given operation on a given object.


Transition decisions


Transition decisions, also called
labeling decisions, determine the types assigned
to newly created objects, particularly processes and files.



This section explains access decisionsthe more frequently made
and important of the two kinds of decisionsand the following
section explains transition decisions.

Conceptually, each object class has an associated bitmap called an
access vector, containing one bit for each
action defined for the class. Figure 2-3 shows a
simplified bitmap for the file class. An actual bitmap for the file
class would include each of the more than one dozen actions defined
for the file class, rather than merely the common actions shown in
the figure.


Figure 2-3. A simplified access vector for the file class

As explained earlier in this chapter, the SELinux security server
makes access decisions by considering the security context of the
subject and object of the action, the security class of the object,
and the action requested. When the security server has made the
access decision, it returns an access vector that indicates the allowed
actions. More precisely, if the security server finds one or more
policy rules matching the request, it returns three related access
vectors, as shown in Figure 2-4. In the figure, the
server has granted the subject permission to append to the object or
create the object.


Figure 2-4. A simplified access vector resulting from an access decision

The three access vectors have the following functions:

Allow


The allow
access vector identifies operations that the
subject is permitted to perform on the object. No log entry is made
of the operation.


Auditallow


The auditallow
access vector causes a log entry
to be made when the indicated operation is performed. Despite its
name, it doesn't allow any operation; only the Allow
vector does so.


Dontaudit


The dontaudit
access vector identifies operations that
the subject is not permitted to perform on the object, but that
don't cause the denial to be logged.



Three rules govern access to objects:

A requested action is denied unless the security server returns
allow
. Therefore, requests that have no matching
policy rule are denied.

If an action is denied, a log entry is made unless the security
server returns dontaudit
.

If the security server returns auditallow
, a log
entry is made.


Table 2-3 summarizes the rules

governing access
to objects.


Table 2-3. Access to objects





Result




Access permitted




Result logged




No matching policy rule


No


Yes


allow


Yes


No, unless auditallow
also specified


auditallow


No, unless allow
also specified


Yes


dontaudit


No


No


To improve the efficiency of its operation, the security server
caches access vectors in a data structure called the access
vector cache (AVC).


/ 100