Earn an NSA recognized IA Masters Online

The NSA has designated Norwich University a center of Academic Excellence in Information Security. Our program offers unparalleled Infosec management education and the case study affords you unmatched consulting experience. Using interactive e-Learning technology, you can earn this esteemed degree, without disrupting your career or home life.

http://www.msia.norwich.edu/linsec

SELinux Policy Development: Auditing An Application
By: Pax Dickenson

Now that you have a policy development environment and are able to compile SELinux policy, you can make policy changes to correct any audited messages in your system log or enable a permission needed by an application you use.

You must create some source files when adding security policy statements that only apply to the local system, since if you add statements to existing files they will be overwritten during policy updates. Create local files by issuing these commands:

touch /etc/selinux/engarde/src/policy/policy/modules/admin/local.fc
touch /etc/selinux/engarde/src/policy/policy/modules/admin/local.te
touch /etc/selinux/engarde/src/policy/policy/modules/admin/local.if

Next, edit the /etc/selinux/engarde/src/policy/policy/modules.conf file and add a line reading local = base and save the file. Recompile the policy and check the output to ensure your local.* files were included.

Let's say, for example, that you've installed some PHP scripts on your website that function fine in permissive mode, but fail when you enable enforcing mode, since the scripts are attempting an action that SELinux does not allow.

The first step would be to open a terminal to the server, ensure you're logged in to the sysadm_r role, and execute the following commands:

# setenforce 0
# dmesg -c
# watch audit2allow -d

These commands will allow you to view the missing SELinux permissions in real time. The audit2allow command is the single most useful tool when troubleshooting SELinux problems. When run with the -d switch, it monitors the dmesg output for SELinux audit errors, and automatically converts these errors into the correct allow command that could be added to the policy to permit the denied action.

With the above commands running and your system in permissive mode, run through the parts of your application that are causing trouble and you should see your audit2allow terminal start outputting allow statements. Review these statements, since they may be unsafe due to incorrect file labeling and may be far too permissive.

For example, your audit2allow output may recommend giving your application full read/write access to the etc_t type. This would allow writing of many files in the /etc directory that belong to other applications and would be unsafe. The correct way to design your policy would be to change the type of the files your application is actually accessing to something narrower and more restricted so you can allow write access to only that new type.

If you're unsure what file is being accessed, look at your system log and search it for the actual denial message. The denial message will look something like the following:

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 ino entry in the denial message indicates the inode of the file that the denial refers to. You can locate this file by using a find command thusly:

# find / -inum 2146393

If you need to assign a different file context to a file, edit the $policy/policy/modules/admin/local.fc. The .fc files are lists of regular expressions matching a full file path followed by a security context to assign to that file during a relabel. Look at other existing .fc files in the policy for an idea of how these work. Once you assign a new context to a file, recompile and relabel, then perform your application testing again to generate a new list of allow statements that take the new context into account.

Read Entire Aricle:
http://www.linuxsecurity.com/content/view/120837/49/

LinuxSecurity.com Feature Extras:

Linux File & Directory Permissions Mistakes - One common mistake Linux administrators make is having file and directory permissions that are far too liberal and allow access beyond that which is needed for proper system operations. A full explanation of unix file permissions is beyond the scope of this article, so I'll assume you are familiar with the usage of such tools as chmod, chown, and chgrp. If you'd like a refresher, one is available right here on linuxsecurity.com.

Introduction: Buffer Overflow Vulnerabilities - Buffer overflows are a leading type of security vulnerability. This paper explains what a buffer overflow is, how it can be exploited, and what countermeasures can be taken to prevent the use of buffer overflow vulnerabilities.

Getting to Know Linux Security: File Permissions - Welcome to the first tutorial in the 'Getting to Know Linux Security' series. The topic explored is Linux file permissions. It offers an easy to follow explanation of how to read permissions, and how to set them using chmod. This guide is intended for users new to Linux security, therefore very simple. If the feedback is good, I'll consider creating more complex guides for advanced users. Please let us know what you think and how these can be improved.

 

Take advantage of our Linux Security discussion list! This mailing list is for general security-related questions and comments. To subscribe send an e-mail to security-discuss-request@linuxsecurity.com with "subscribe" as the subject.

Thank you for reading the LinuxSecurity.com weekly security newsletter. The purpose of this document is to provide our readers with a quick summary of each week's most relevant Linux security headline.

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

Powered by AkoComment!