Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

2.8. TE Rules - Access Vectors

Access vectors (AVs) are the rules that allow domains to access various system objects. An AV is a set of permissions. A basic AV rule is a subject and object pair of types, a class definition for the object, and a permission for the subject. There is a general rule syntax that covers all the kinds of AV rules:

<av_kind> <source_type(s)> <target_type(s)>:<class(es)> \
<permission(s)>

All AV rules are considered by the policy enforcement engine as two types, one class, and one access permission. However, rules are written using attributes, sets, and macros to be more efficient. AV rules are simplified during policy compilation.

The parts of the AV rule are defined elsewhere in this chapter. This section describes the kinds of access vectors used in the AV rule at av_kind. av_kind is one of three rule types:

  • allow — permit a subject to act in a specific way with an object. The rule here allows named (in the domain of named_t) to perform a search of a directory with the type sbin_t (for example, /sbin, /usr/sbin, /opt/sbin, etc.):

    allow named_t sbin_t:dir search;

    If the ruling results in a denial, the denial is audited (that is, logged). Granted permission events are not logged.

  • auditallow — when the permission is granted, log the access decision. In the targeted policy, there is only one auditallow rule. This rule logs usage of certain SELinux applications, for example logging avc: granted { setenforce } when allowing setenforce:

    auditallow unconfined_t security_t : security { load_policy \
      setenforce setbool }; 
  • dontaudit — never audit a specific access denial. This is used when a program is attempting an action that is not allowed by policy, and the resulting denials are filling the log, but the denial is not affecting the application doing its tasks. This AV lets you silently deny and ignore the access violation. For example, this dontaudit rule says to ignore when the named_t domain attempts to read or get attributes on a file with the root_t type. Denial of this access attempt does not effect named doing its job, so the denial is ignored to keep the logs clean:

    dontaudit named_t root_t:file { getattr read };

There is one additional AV rule, neverallow. This AV assertion, defined in $SELINUX_SRC/assert.te, is not part of the regular permission checking. The purpose of this rule is to declare access vectors that must never be allowed. These are used to protect against policy writing mistakes, especially where macros can provide unexpected rights. These assertions are checked by the policy compiler, checkpolicy, when the policy is built, but after the entire policy has been evaluated, and are not part of the runtime access vector cache.

Here is the syntax and an example. In practice, a wildcard character * is often used to cover all instances possible in a rule field. The syntax is different in that it is possible to use ifdef() statements as sources or targets:

# Syntax for AV assertion

neverallow <source_name(s)> <target_name(s)> : \
  <class(es)> <permission(s)>

In this example from assert.te, the neverallow rule verifies that every type that a domain can enter into has the attribute domain. This prevents a rule from elsewhere in the policy allowing a domain to transition to a type that is not a process type. The tilde in front, ~domain, means "anything that is not a domain":

# Verify that every type that can be entered by
# a domain is also tagged as a domain.
#
neverallow domain ~domain:process transition;

2.8.1. Understanding an avc: denied Message

When SELinux disallows an operation, a denial message is generated for the audit logs. In Red Hat Enterprise Linux, $AUDIT_LOG is /var/log/messages. This section explains the format of these log messages. For suggestions on using an avc: denied message for troubleshooting, refer to Section 5.2.11 Troubleshoot User Problems With SELinux.

Example 2-1 shows a denial generated when a user's Web content residing in ~/public_html does not have the correct label.

Jan 14 19:10:04 hostname kernel: audit(1105758604.519:420):  \
avc:  denied  { getattr } for  pid=5962 exe=/usr/sbin/httpd \
path=/home/auser/public_html dev=hdb2 ino=921135 \
scontext=root:system_r:httpd_t \
tcontext=user_u:object_r:user_home_t tclass=dir

Example 2-1. AVC Denial Message

This shows the message parts and an explanation of what the part means:

avc: denied Message Explained

Jan 14 19:10:04

Timestamp on the audit message.

hostname

The hostname of the system.

kernel: audit(1105758604.519:420):

This is the kernel audit log message pointer. The timestamp consists of a long number, which is the unformatted current time, and a short number, which is the milliseconds, that is, <current_time>.<milliseconds_past_current_time>. The third number is the serial number, which helps in stitching together the full audit trail from multiple messages. Multiple messages for the same event occur when full audit logging is enabled using an audit daemon, which logs various kernel events.

avc: denied

The operation was denied. A few operations have auditallow set so they generate granted messages instead.

{ getattr }

What was denied or granted. The brackets {} contain the actual permission that was attempted.

for pid=5962

The process ID of the application that is the source of the operation.

exe=/usr/sbin/httpd

The application being denied.

path=/home/auser/public_html

The path to the target file or directory the operation was attempted on.

dev=hdb2

The device node that holds the file system. The object of the denied operation lives in this file system.

ino=921135

The inode number of the target file or directory.

scontext=root:system_r:httpd_t

The security context of the source, that is, the process being denied access.

tcontext=user_u:object_r:user_home_t

The security context of the target, that is, the file or directory that is denied.

tclass=dir

The object class of the target, indicating that it was the directory /home/auser/public_html/ that was being blocked.

 
 
  Published under the terms of the GNU General Public License Design by Interspire