Hacks From Pax: SELinux And Access Decisions

    Date19 Oct 2005
    CategorySELinux
    37170
    Posted ByBrittany Day
    Hi, and welcome to my second of a series of articles on Security Enhanced Linux. My previous article detailed the background of SELinux and explained what makes SELinux such a revolutionary advance in systems security. This week, we'll be discussing how SELinux security contexts work and how policy decisions are made by SELinux.

    SELinux systems can differ based on their security policy, so for the purposes of this article's examples I'll be using an EnGarde Secure Linux 3.0 system, which by default uses a tightly configured policy that confines every included application.

    Security Contexts

    SELinux makes access decisions by checking the security context of the subject (a process, sometimes associated with a user) against the action attempted (e.g. a file read) and the security context of the targeted object (such as a file or network port).

    These contexts are divided into three parts: a user identity, a role, and a domain or type. In the current SELinux policy, access is not restricted based on user identities, so we'll focus on roles and domains in this article.

    User Roles

    On an SELinux system, unlike a standard Linux system, root has no special privileges inherent to the account. SELinux privileges are denoted by a user's role. A standard user is assigned a role of user_r, which gives no special privileges. System administrator accounts are assigned a role of staff_r, which permits what is known as a "role transition" to the sysadm_r role. The sysadm_r role is the equivalent of the root account on a non-SELinux system, it has unfettered access to the system.

    A staff user transitions to the sysadm_r role by using the newrole command, as shown below.

    newrole -r sysadm_r

    The user is then prompted for his or her password, successful entry of which will result in transition to the new role. You can view your current role by issuing an id -Z command.

    Domains and Types

    Domains and types are synonyms, typically the term "domain" is used when referring to processes and the term "type" is used referring to files. Types are the primary method used by SELinux to make authorization decisions. The strict policy defines relatively few users and roles, but contains hundreds of types.

    Types are assigned by the security policy based on the path of the file in question, and the policy also transitions processes into an appropriate domain based on the context of the executed file and the domain of the process executing the file.

    For example, the Apache webserver executable file has a type of httpd_exec_t. When that file is executed by the init process at bootup, the policy forces the new process to transition into the httpd_t domain. The httpd_t domain has the ability to read web content denoted by the httpd_content_t type, but not to change it or access any other domains not required for proper webserver operation.

    You can view the type of a given file by using the -Z option of ls, and you can view the domain a process is running in by using the -Z option of ps. These -Z options are specific to SELinux and will not function on a non-SELinux system.

    Denials and Logging

    Any access attempts that are denied by SELinux will be written to the system log. When troubleshooting any problems on an SELinux system, the logs should be checked for denial messages. These log entries can be quite confusing looking to those just getting their feet wet with SELinux, as shown below:

    Oct 19 14:38:54 paxtest kernel: audit(1129747134.276:0): avc:
    denied  { read } for  name=messages dev=hda6 ino=2146393 
    scontext=root:staff_r:staff_t tcontext=system_u:object_r:var_log_t 
    tclass=file

    The above log entry was triggered by my attempt to run the command tail /var/log/messages while running in the staff_r role (if I had been in the sysadm_r role, this would have been permitted). The denied: { read } section indicates the action that was denied, in this case a read attempt.

    The name, dev, and ino entries indicate the filename, filesystem, and inode number of the target file. If you're unsure of the file's path you can use the find command to locate the file based on its inode number thusly:

    find / -inum 2146393

    The scontext indicates the domain of the process that attempted the action, and tcontext indicates the security context of the target file. So in summary, this error message is telling us that the staff_t domain does not have an allow rule granting it read access to the var_log_t type. If we wanted this to be permitted, a rule would need to be added to the policy to allow this particular interaction.

    In my next article, we'll delve into the basics of SELinux systems administration and show how it differs and what SELinux requires of an administrator. Until then, stay secure and keep those patches current!
    --
    Pax Dickinson has over ten years of experience in systems administration and software development on a wide variety of hardware and software platforms. He is currently employed by Guardian Digital as a systems programmer where he develops and implements security solutions using EnGarde Secure Linux. His experience includes UNIX and Windows systems engineering and support at Prudential Insurance, Guardian Life Insurance, Philips Electronics and a wide variety of small business consulting roles.

    You are not authorised to post comments.

    Comments powered by CComment

    LinuxSecurity Poll

    What do you think of the articles on LinuxSecurity?

    No answer selected. Please try again.
    Please select either existing option or enter your own, however not both.
    Please select minimum 0 answer(s) and maximum 3 answer(s).
    /main-polls/24-what-do-you-think-of-the-quality-of-the-articles-on-linuxsecurity?task=poll.vote&format=json
    24
    radio
    [{"id":"87","title":"Excellent, don't change a thing!","votes":"25","type":"x","order":"1","pct":55.56,"resources":[]},{"id":"88","title":"Should be more technical","votes":"5","type":"x","order":"2","pct":11.11,"resources":[]},{"id":"89","title":"Should include more HOWTOs","votes":"15","type":"x","order":"3","pct":33.33,"resources":[]}]["#ff5b00","#4ac0f2","#b80028","#eef66c","#60bb22","#b96a9a","#62c2cc"]["rgba(255,91,0,0.7)","rgba(74,192,242,0.7)","rgba(184,0,40,0.7)","rgba(238,246,108,0.7)","rgba(96,187,34,0.7)","rgba(185,106,154,0.7)","rgba(98,194,204,0.7)"]350
    bottom200

    We use cookies to provide and improve our services. By using our site, you consent to our Cookie Policy.