On 18 Mar 2005 at 4:31, centos-request@xxxxxxxxxxx wrote:
> Man. You open your system to everyone who cracks apache server.
> Open for reading but that's enough. OK, there are DAC rules too but
> that's too open.
The relevant question is: Is this worse than no SELinux at all?
Should I turn off SELinux until the packages that are essential to
my client's business are properly configured to work with SELinux
on CentOS?
I have clients presently running mailman on RH 7.3. Surely moving
them to CentOS4 with SELinux enabled and the configurations as set
above is not worse than leaving things where they are?
Until last week I knew absolutely nothing about SELinux and while
the subject is no doubt fascinating for those that have the time to
delve deeply into it I have not that luxury at present. I need a
standardized basic mailserver setup with mailman, squirrelmail,
cyrus-imapd and mailscanner all running in an environment no less
secure than that available on RH 7.3. That is a functional
requirement that must be met.
As far as I can see, the security issues being raised at this
juncture are more theoretical than real as SELinux is not yet, to
my understanding, widely in use. However, from the tone of these
comments I am beginning to sense that there may be a deeper problem
that I, in my ignorance, fail to appreciate. IS SELinux LESS
secure than a non-SELinux enabled OS if the policies are not
exactly right?
I have dug around in the contexts files and this is what I have
found:
see /etc/selinux/targeted/contexts/files
files/file_contexts:/var/mailman/bin(/.*)? system_u:object_r:bin_t
files/file_contexts:/var/mailman/pythonlib(/.*)?/.*\.so(\..*)? --
system_u:object_r:shlib_t
files/file_contexts:# mailman list server
files/file_contexts:/var/lib/mailman(/.*)?
system_u:object_r:mailman_data_t
files/file_contexts:/var/log/mailman(/.*)?
system_u:object_r:mailman_log_t
files/file_contexts:/usr/lib/mailman/cron/.* --
system_u:object_r:mailman_queue_exec_t
files/file_contexts:/usr/lib/mailman/bin/mailmanctl --
system_u:object_r:mailman_mail_exec_t
files/file_contexts:/var/run/mailman(/.*)?
system_u:object_r:mailman_lock_t
files/file_contexts:/var/lib/mailman/archives(/.*)?
system_u:object_r:mailman_archive_t
files/file_contexts:/usr/lib/mailman/cgi-bin/.* --
system_u:object_r:mailman_cgi_exec_t
files/file_contexts:/var/lock/mailman(/.*)?
system_u:object_r:mailman_lock_t
files/file_contexts:/usr/lib/mailman/scripts/mailman --
system_u:object_r:mailman_mail_exec_t
files/file_contexts:/usr/lib/mailman/bin/qrunner --
system_u:object_r:mailman_queue_exec_t
files/file_contexts:/etc/mailman(/.*)?
system_u:object_r:mailman_data_t
files/file_contexts:/var/spool/mailman(/.*)?
system_u:object_r:mailman_data_t
I infer from the comments that the following local.te entries are
the controversial ones:
> allow mailman_cgi_t file_t:dir write;
> allow mailman_cgi_t file_t:dir add_name;
> allow mailman_cgi_t file_t:dir create;
> allow mailman_cgi_t file_t:file create;
> allow mailman_cgi_t file_t:file { getattr write };
> allow mailman_cgi_t file_t:lnk_file create;
I would think that these should work, but they do not.
> allow mailman_cgi_t mailman_archive_t:dir write;
> allow mailman_cgi_t mailman_archive_t:dir add_name;
> allow mailman_cgi_t mailman_archive_t:dir create;
> allow mailman_cgi_t mailman_archive_t:file create;
> allow mailman_cgi_t mailman_archive_t:file { getattr write };
> allow mailman_cgi_t mailman_archive_t:lnk_file create;
The first error I receive is:
File "/usr/lib/mailman/Mailman/Archiver/Archiver.py", line 95, in
InitVars
os.mkdir(self.archive_dir()+'.mbox', 02775)
OSError: [Errno 13] Permission denied:
'/var/lib/mailman/archives/private/test1.mbox'
audit2allow provides this:
allow mailman_cgi_t file_t:dir write;
Now, do I need to add something regarding mailman_cgi_t and
mailman_archive_t somewhere else in some other file?
Regards,
Jim
---
*** e-mail is not a secure channel ***
mailto:byrnejb.<token>@harte-lyne.ca
James B. Byrne Harte & Lyne Limited
vox: +1 905 561 1241 9 Brockley Drive
fax: +1 905 561 0757 Hamilton, Ontario
<token> = hal Canada L8E 3C3
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
Postmaster
Harte & Lyne Limited
