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

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

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

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

Bill McCarty

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

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

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








8.2 Other Context-Related Declarations


The SELinux policy language includes several
declaration types that establish contexts for various objects:

Objects having initial SIDs

Filesystems supporting persistent labels

Filesystems not supporting persistent labels

Network-related objects


Some filesystems, such as ext2 and ext3, provide space in which
SELinux can store persistent file labels. However, some filesystems
do not have this capability. So that even uncooperative filesystems
can be used with SELinux, SELinux lets you specify static labels that
are applied to files within such filesystems.

The following subsections describe these declarations.


8.2.1 Syntax of Initial SID Context Declarations


Figure 8-6 shows the syntax of
initial SID context declarations,
which are used to specify the security context
of objects having initial SIDs.


Figure 8-6. Initial SID context declaration

The example SELinux policy typically includes a bit more than two
dozen initial SID declarations. A typical declaration is:

sid kernel      system_u:system_r:kernel_t

This declaration assigns the security context
system_u:system_r:kernel_t
to the
kernel
object. In general, it's
not possible to change or add an initial SID declaration without
making corresponding changes to SELinux itself, so changes and
additions are generally made only by SELinux developers rather than
system administrators.


8.2.2 Syntax of Filesystem Labeling Declarations


When an SELinux system mounts a
filesystem, SELinux must determine
whether the filesystem supports persistent labels. If so, SELinux
processes the persistent labels according to the
options specified in three types of declaration:

fs_use_xattr


Specifies options for conventional
filesystems.


fs_use_task


Specifies options for
pseudofilesystems associated with pipe and socket objects.


fs_use_trans


Specifies options for
pseudofilesystems associated with RAM disk devices, pseudoterminals,
and shared memory objects.



Figure 8-7 shows the syntax for all three types of
declarations.


Figure 8-7. Filesystem labeling declaration

The identifier
appearing in the syntax diagram
denotes the filesystem type. Typical values include the following:

devpts


Pseudoterminal filesystem


ext2


Linux Ext2 filesystem


ext3


Linux Ext3 filesystem


pipefs


Pseudofilesystem associated with a pipe


shm


Pseudofilesystem associated with a
shared memory object


sockfs


Pseudofilesystem associated with a
socket


tmpfs


Pseudofilesystem associated with a
memory-resident filesystem


xfs


Linux Xfs filesystem



Some typical filesystem labeling declarations appearing in sample
policies include:

fs_use_xattr ext2   system_u:object_r:fs_t;
fs_use_xattr ext3 system_u:object_r:fs_t;
fs_use_xattr xfs system_u:object_r:fs_t;
fs_use_task pipefs system_u:object_r:fs_t;
fs_use_task sockfs system_u:object_r:fs_t;
fs_use_trans devpts system_u:object_r:devpts_t;
fs_use_trans tmpfs system_u:object_r:tmpfs_t;
fs_use_trans shm system_u:object_r:tmpfs_t;

Thus, ext2
, ext3
, and
xfs
filesystems store file labels in their
extended attribute space (fs_use_xattr
);
pipefs
and sockfs
filesystems
use the special facility for pipe and socket pseudofilesystems
(fs_use_task
); and devpts
,
tmpfs
, and shm
filesystems use
the special facility for pseudoterminal, memory-resident, and
shared-memory filesystems (fs_use_trans
).


8.2.3 Syntax of Genfs Declarations


For filesystems
not
supporting persistent labels, SELinux behavior
can be specified using Genfs
declarations. Figure 8-8 shows the syntax of such declarations, which
resembles the syntax used in FC (file context) files, with two
differences:

The declaration begins with the keyword genfscon
.

The genfscon
keyword is
followed by an identifier
giving the filesystem
type.



Figure 8-8. Genfs declaration

The replaceable text path
gives the mount
point of the filesystem. More precisely, it gives a prefix for the
mount point, since any directory below the specified directory is
considered to match the declaration. Specifying
/nfs matches any filesystem mounted at
/nfs or any subdirectory of
/nfs, and specifying / matches any mounted
filesystem. When multiple declarations match an actual mount point,
the longest matching declaration is used, and the others are ignored.

The optional identifier, which is preceded by a hyphen (-), also can
be used to restrict the type of files to which the declaration
applies. File types are specified using the codes displayed by the
ls command; for instance, use
-c to specify that the declaration applies only
to character device files, or use -b to specify
that the declaration applies only to block device files .

Genfs
declarations reside in the
genfs_contexts
file,
which contains about three dozen declarations in the example SELinux
policy. These declarations assign security contexts to filesystems
having types such as the following:

autofs
bdev
cifs
cramfs
eventpollfs
fat
futexfs
iso9660
msdos
nfs
nfsd
ntfs
proc
ramfs
romfs
rootfs
rpc_pipefs
selinuxfs
smbfs
sysfs
usbdevfs
usbfs
vfat

For example, a typical declaration assigning a security context to
files residing on an nfs
filesystem mounted
somewhere below the root (/) directory is:

genfscon nfs / system_u:object_r:nfs_t

The related type nfs_t
is defined in the file
types/nfs.te. The proc

filesystem receives special attention in the
genfs_contexts
file. Over one dozen of the entries
in the file pertain to that filesystem.


8.2.4 Syntax of Network Declarations


Recent releases of SELinux support labeling of
network objects, including ports, network interfaces, hosts (nodes),
and received packets. This is useful in implementing the
principle of least privilege, by
restricting users and processes from unnecessarily accessing network
objects. The labeling is specified by network declarations residing
in the file net_contexts. Figure 8-9 shows the related syntax, which includes three
declaration types:

portcon


Specifies the security context of a port.


netifcon


Specifies the security context of a network interface and the
security context of packets it received.


nodecon


Specifies the security context of a host (node).




Figure 8-9. Network declaration


8.2.4.1 Portcon declarations

Portcon
declarations specify security contexts of
local ports. Here is a typical portcon

declaration:

portcon tcp 80  system_u:object_r:http_port_t

The declaration assigns the security context
system_u:object_r:http_port_t
to port TCP/80. The
related type http_port_t
is defined in the file
domains/program/apache.te by the declaration

type http_port_t, port_type;

An access-vector rule such as the following can restrict access to
the port:

allow httpd_t { http_port_t http_cache_port_t }:tcp_socket name_bind;

This rule allows only the httpd_t
domain to
perform the name_bind
operation on port TCP/80;
thus, other domains are prohibited from binding to the port.


8.2.4.2 Netifcon declarations

Netifcon declarations specify
security contexts of network
interfaces. Here is a typical netifcon

declaration:

netifcon eth0 system_u:object_r:netif_eth0_t system_u:object_r:netmsg_eth0_t

Notice that the declaration specifies two security contexts. The
first security context pertains to the network interface itself,
eth0
. The second security context pertains to
packets received on the network interface.

An access vector rule such as the following can restrict access to
the network interface or packets received on it:

allow vmware_t netif_eth0_t:netif rawip_send;

This rule allows the vmware_t
domain to send raw
IP traffic with the eth0
interface.


8.2.4.3 Nodecon declarations

Nodecon
declarations specify security contexts of hosts. Here is
a typical nodecon
declaration:

nodecon 127.0.0.1 255.0.0.0 system_u:object_r:node_lo_t

This declaration binds the security context
system_u:object_r:node_lo_t
to hosts having IP
addresses 127.0.0.1 and netmask 255.0.0.0that is, the local or
loopback host.


The sample policy related to nodecon
declarations
is relatively immature. For instance, the policy distributed with
Fedora Core 2 includes no access vector rules related to types bound
to
hosts
by
nodecon
declarations.


/ 100