Author: Benjamin D. Thomas
horde2, Perl, Webmin, eagle-usb, spamassassin, mailman, xpdf, libc-client, and
imap. The distributors include Debian, Gentoo, Mandriva, and Red Hat.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/
| Debian | ||
| Debian: New gdk-pixbuf packages fix several vulnerabilities |
||
1st, December, 2005
|
||
| Debian: New horde2 packages fix cross-site scripting |
||
1st, December, 2005
|
||
| Debian: New helix-player packages fix arbitrary code execution |
||
2nd, December, 2005
|
||
| Debian: New Inkscape packages fix arbitrary code execution |
||
7th, December, 2005
|
||
| Debian: New courier packages fix unauthorised access |
||
8th, December, 2005
|
||
| Gentoo | ||
| Gentoo: Perl Format string errors can lead to code execution |
||
7th, December, 2005
|
||
| Gentoo: Webmin, Usermin Format string vulnerability |
||
7th, December, 2005
|
||
| Mandriva | ||
| Mandriva: Updated eagle-usb packages fixes firmware loading issues |
||
2nd, December, 2005
|
||
| Mandriva: Updated spamassassin packages fixes vulnerability |
||
2nd, December, 2005
|
||
| Mandriva: Updated mailman packages fix various vulnerabilities |
||
2nd, December, 2005
|
||
| Mandriva: Updated webmin package fixes format string vulnerability |
||
2nd, December, 2005
|
||
| Red Hat |
||
| RedHat: Important: xpdf security update | ||
6th, December, 2005
|
||
| RedHat: Moderate: libc-client security update |
||
6th, December, 2005
|
||
| RedHat: Moderate: imap security update | ||
6th, December, 2005
|
||
