LinuxSecurity.com
Share your story
The central voice for Linux and Open Source security news
Home News Topics Advisories HOWTOs Features Newsletters About Register

Welcome!
Sign up!
EnGarde Community
Login
Polls
What is the most important Linux security technology?
 
Advisories
Community
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
SELinux
White Papers
Featured Blogs
All About Linux
DanWalsh LiveJournal
Securitydistro
Latest Newsletters
Linux Advisory Watch: October 31st, 2014
Linux Security Week: October 27th, 2014
Subscribe
LinuxSecurity Newsletters
E-mail:
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

  
Hacks From Pax: SELinux And Access Decisions Print E-mail
User Rating:      How can I rate this item?
Posted by Pax Dickinson   
SELinux 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.

Comments
aasdasWritten by stempek on 2007-03-17 20:05:41
UKZ Grot Suwalki +  
technocar.pl - Warsztat samochodowy +  
wyszukiwarka +  
funkcje php, lista funkcji php +  
rss +  
darmowe aliasy +  
katalog dmoz kopia +  
darmowe aliasy +  
cytaty +  
opisy gg, opisy do gg 
 
 
 
UKZ Grot Suwalki +  
technocar.pl - Warsztat samochodowy +  
wyszukiwarki +  
funkcje php, lista funkcji php +  
rss +  
darmowe aliasy +  
katalog dmoz kopia +  
darmowe aliasy +  
cytaty +  
opisy gg, opisy do gg 
 
 
 
 
 
http://stempek.info 
http://z00ne.info 
http://qqe.pl 
http://spis.qqe.pl 
http://rss.qqe.pl 
http://opisy-gg.z00ne.info 
http://technocar.pl 
http://stempek-dmoz.z00ne.info 
http://grot.z00ne.info 
http://cytaty.qqe.pl 
 
 
 
 
[url]http://stempek.info[/url] 
[url]http://z00ne.info[/url] 
[url]http://qqe.pl[/url] 
[url]http://spis.qqe.pl[/url] 
[url]http://rss.qqe.pl[/url] 
[url]http://opisy-gg.z00ne.info[/url] 
[url]http://technocar.pl[/url] 
[url]http://stempek-dmoz.z00ne.info[/url] 
[url]http://grot.z00ne.info[/url] 
[url]http://cytaty.qqe.pl[/url] 
 
 
The best sites!!

Only registered users can write comments.
Please login or register.

Powered by AkoComment!

 
< Prev   Next >
    
Partner

 

Latest Features
Peter Smith Releases Linux Network Security Online
Securing a Linux Web Server
Password guessing with Medusa 2.0
Password guessing as an attack vector
Squid and Digest Authentication
Squid and Basic Authentication
Demystifying the Chinese Hacking Industry: Earning 6 Million a Night
Free Online security course (LearnSIA) - A Call for Help
What You Need to Know About Linux Rootkits
Review: A Practical Guide to Fedora and Red Hat Enterprise Linux - Fifth Edition
Yesterday's Edition
Pirate Bay founder guilty in historic hacker case
Parallels CTO: Linux container security is not the problem
Advisory says to assume all Drupal 7 websites are compromised
Partner Sponsor

Community | HOWTOs | Blogs | Features | Book Reviews | Networking
 Security Projects |  Latest News |  Newsletters |  SELinux |  Privacy |  Home
 Hardening |   About Us |   Advertise |   Legal Notice |   RSS |   Guardian Digital
(c)Copyright 2014 Guardian Digital, Inc. All rights reserved.