Apache/PHP mail function SELinux permissions
by Ted Rule
I've had a "problem" recently with SELinux permissions related to PHP's
mail functions. These appear to give rise to two different classes of error,
one for read permissions on the httpd_t domain itself, and one for
read/write permission on a file in the httpd_tmp_t domain.
aureport gives this:
$ sudo aureport -a |grep system_mail |head
6. 25/10/09 13:12:48 sendmail user_u:system_r:system_mail_t:s0 11 file
read user_u:system_r:httpd_t:s0 denied 116101
7. 25/10/09 13:15:57 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116102
17. 25/10/09 13:39:46 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116124
23. 25/10/09 13:43:04 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116136
24. 25/10/09 13:43:04 sendmail user_u:system_r:system_mail_t:s0 11 file
read user_u:system_r:httpd_t:s0 denied 116136
30. 25/10/09 13:52:57 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116148
31. 25/10/09 13:52:57 sendmail user_u:system_r:system_mail_t:s0 11 file
read user_u:system_r:httpd_t:s0 denied 116148
39. 25/10/09 14:01:18 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116168
40. 25/10/09 14:01:18 sendmail user_u:system_r:system_mail_t:s0 11 file
read user_u:system_r:httpd_t:s0 denied 116168
48. 25/10/09 14:11:50 sendmail user_u:system_r:system_mail_t:s0 11 file
read write user_u:object_r:httpd_tmp_t:s0 denied 116181
Policy on the Apache hosts currently uses selinux-policy-2.4.6-203.el5
Looking in more detail at ausearch we see that the httpd_t related avc
is apparently related to an "eventpoll" file descriptor, whilst the
httpd_tmp_t
avc is probably for a file created by php in /tmp.
Looking at the php source code itself, I see that it is simply opening a
temporary file containing the body of the Email and pouring it via a
pipe into an instance of sendmail via popen().
As such, it seems likely that both classes of avc's are simply file
descriptors "leaking" into the popen'ed child process running in the
system_mail_t domain.
Sadly, for other reasons, the Apache hosts are still in permissive, so
it's currently unclear to me whether the PHP mail function would fail
completely if either
of these permissions are denied in enforcing mode, but it makes me
wonder whether there would be any sense in a wider solution to leaky
descriptors which caused popen() itself to close all file descriptors
other than STDIN/STDOUT/STDERR if the popen'ed executable implies a
domain transition. Alternatively, one might envisage a set of selinux
booleans which allowed a more granular control of leaked descriptors
outside of STDIN/STDOUT/STDERR.
The other potential policy improvement would be for system_mail_t to
simply "dontaudit" denials relating to eventpoll class file descriptors
and temporary files in context *_tmp_t.
time->Sun Oct 25 13:12:48 2009
type=SYSCALL msg=audit(1256476368.217:116101): arch=40000003 syscall=11
success=yes exit=0 a0=97e5ff0 a1=97e5798 a2=97e5600 a3=40 items=0
ppid=20809 pid=22040 auid=500 uid=48 gid=48 euid=
48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966
comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
subj=user_u:system_r:system_mail_t:s0 key=(null)
type=AVC msg=audit(1256476368.217:116101): avc: denied { read } for
pid=22040 comm="sendmail" path="eventpoll:[129640960]" dev=eventpollfs
ino=129640960 scontext=user_u:system_r:system
_mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file
----
time->Sun Oct 25 13:15:57 2009
type=SYSCALL msg=audit(1256476557.234:116102): arch=40000003 syscall=11
success=yes exit=0 a0=9ab7ff0 a1=9ab7798 a2=9ab7600 a3=40 items=0
ppid=21767 pid=22099 auid=500 uid=48 gid=48 euid=
48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966
comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
subj=user_u:system_r:system_mail_t:s0 key=(null)
type=AVC msg=audit(1256476557.234:116102): avc: denied { read write }
for pid=22099 comm="sendmail"
path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746
56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0
tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file
----
time->Sun Oct 25 13:39:46 2009
type=SYSCALL msg=audit(1256477986.012:116124): arch=40000003 syscall=11
success=yes exit=0 a0=97f1ff0 a1=97f1798 a2=97f1600 a3=40 items=0
ppid=23457 pid=23560 auid=500 uid=48 gid=48 euid=
48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966
comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
subj=user_u:system_r:system_mail_t:s0 key=(null)
type=AVC msg=audit(1256477986.012:116124): avc: denied { read write }
for pid=23560 comm="sendmail"
path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746
56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0
tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file
----
time->Sun Oct 25 13:43:04 2009
type=SYSCALL msg=audit(1256478184.954:116136): arch=40000003 syscall=11
success=yes exit=0 a0=8f48ff0 a1=8f48798 a2=8f48600 a3=40 items=0
ppid=23048 pid=23802 auid=500 uid=48 gid=48 euid=
48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966
comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
subj=user_u:system_r:system_mail_t:s0 key=(null)
type=AVC msg=audit(1256478184.954:116136): avc: denied { read } for
pid=23802 comm="sendmail" path="eventpoll:[129701955]" dev=eventpollfs
ino=129701955 scontext=user_u:system_r:system
_mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file
type=AVC msg=audit(1256478184.954:116136): avc: denied { read write }
for pid=23802 comm="sendmail"
path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746
56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0
tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file
----
time->Sun Oct 25 13:52:57 2009
type=SYSCALL msg=audit(1256478777.377:116148): arch=40000003 syscall=11
success=yes exit=0 a0=945bff0 a1=945b798 a2=945b600 a3=40 items=0
ppid=24396 pid=24439 auid=500 uid=48 gid=48 euid=
48 suid=48 fsuid=48 egid=51 sgid=51 fsgid=51 tty=(none) ses=11966
comm="sendmail" exe="/usr/sbin/sendmail.sendmail"
subj=user_u:system_r:system_mail_t:s0 key=(null)
type=AVC msg=audit(1256478777.377:116148): avc: denied { read } for
pid=24439 comm="sendmail" path="eventpoll:[129734033]" dev=eventpollfs
ino=129734033 scontext=user_u:system_r:system
_mail_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=file
type=AVC msg=audit(1256478777.377:116148): avc: denied { read write }
for pid=24439 comm="sendmail"
path=2F746D702F2E7863616368652E302E302E313032353230323336322E6C6F636B202864656C65746
56429 dev=dm-3 ino=97922 scontext=user_u:system_r:system_mail_t:s0
tcontext=user_u:object_r:httpd_tmp_t:s0 tclass=file
----
--
Ted Rule
Director, Layer3 Systems Ltd
Layer3 Systems Limited is registered in England. Company no 3130393
W: http://www.layer3.co.uk/
13 years, 2 months
Apparent memory leak in libselinux
by Ed Swierk
When I run the following on a F12 system booted with selinux=0, the
tcmalloc heap checker complains about a leak somewhere in libselinux:
$ HEAPCHECK=normal LD_PRELOAD=/usr/lib64/libtcmalloc.so.0
/usr/bin/python -c 'import _ssl'
Leak check _main_ detected leaks of 120 bytes in 1 objects
The 1 largest leaks:
Leak of 120 bytes in 1 objects allocated from:
@ 0x3bf9866589 _IO_getdelim
@ 0x3bfb40ca53 set_selinuxmnt
@ 0x3bfb414fe6 string_to_security_class
@ 0x3bfb404cdb _init
@ 0x7fff4bdfa8ed 0x00007fff4bdfa8ed
No leak is detected when I run this with selinux enabled. My system
has libselinux-2.0.87-1.fc12 installed.
--Ed
13 years, 7 months
Home directories within /var
by Robert Nichols
On my system I have home directories in /var/home and bind mounted
to /home:
/var/home on /home type none (rw,bind)
Is there any way to prevent restorecon on /var from descending into
/var/home and destroying the normal home directory file contexts?
Reproducing all of file_contexts.homedirs in local policy is of course
unmaintainable.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
13 years, 9 months
CentOS 5.4 + xinetd + sshd + SELinux issues
by Grzegorz Nosek
Hi all,
I have a problem trying to run sshd via xinetd on a CentOS 5.4 system
(I want to slap a tcpwrappers-style wrapper before sshd, so I need it
that way).
In permissive mode I can log in/out with the following failures reported
by audit2allow:
allow amanda_t consoletype_exec_t:file { execute execute_no_trans };
allow amanda_t devpts_t:chr_file { write ioctl };
allow amanda_t hostname_exec_t:file { execute execute_no_trans };
allow amanda_t shell_exec_t:file entrypoint;
I don't even have amanda installed, so the context is clearly bogus.
After a chat on #fedora-selinux it seems that sshd cannot find its
default context, so falls back to the first available one, which happens
to be something:something:amanda_t (the list is read from /selinux/user).
This operation is performed by sshd itself (as verified by strace).
I don't need Fort Knox type security but I'd like to use SELinux to
tighten down other parts of the system, so I'd really like to use the
enforcing mode.
Any hints? A good TFM to R will hopefully do.
Best regards,
Grzegorz Nosek
13 years, 9 months
newrole: double free or corruption
by Andy Warner
Got the following output from using the newrole command on Fedora 12.
Not sure where to properly report such bugs.
If it helps, the rubix_remote_client_r role transition should fail (as
it does) as there are no role transition rules for it. The role is
associated with the current SELinux user.
I believe my system just updated to the newest newrole package.
[warner@Fedora12-Dev ~]$ yum info policycoreutils
Loaded plugins: presto, refresh-packagekit
Installed Packages
Name : policycoreutils
Arch : i686
Version : 2.0.78
Release : 3.fc12
Size : 3.3 M
Repo : installed
>From repo : updates
Error output from newrole follows:
[warner@Fedora12-Dev ~]$ newrole -r rubix_remote_client_r
Password:
failed to exec shell
: Permission denied
*** glibc detected *** newrole: double free or corruption (out):
0x01726138 ***
======= Backtrace: =========
/lib/libc.so.6(-0xff836d9f)[0x233261]
/lib/libselinux.so.1(freecon+0x1e)[0x9fd42e]
newrole(main+0x6eb)[0x119d6b]
/lib/libc.so.6(__libc_start_main+0xe6)[0x1dbbb6]
newrole(+0x16f1)[0x1186f1]
======= Memory map: ========
00117000-0011d000 r-xp 00000000 fd:00 126525 /usr/bin/newrole
0011d000-0011e000 r--p 00005000 fd:00 126525 /usr/bin/newrole
0011e000-0011f000 rw-p 00006000 fd:00 126525 /usr/bin/newrole
0011f000-00135000 r-xp 00000000 fd:00 56679 /lib/libpthread-2.11.so
00135000-00136000 r--p 00015000 fd:00 56679 /lib/libpthread-2.11.so
00136000-00137000 rw-p 00016000 fd:00 56679 /lib/libpthread-2.11.so
00137000-00139000 rw-p 00000000 00:00 0
001a5000-001c3000 r-xp 00000000 fd:00 56677 /lib/ld-2.11.so
001c3000-001c4000 r--p 0001d000 fd:00 56677 /lib/ld-2.11.so
001c4000-001c5000 rw-p 0001e000 fd:00 56677 /lib/ld-2.11.so
001c5000-00333000 r-xp 00000000 fd:00 56678 /lib/libc-2.11.so
00333000-00334000 ---p 0016e000 fd:00 56678 /lib/libc-2.11.so
00334000-00336000 r--p 0016e000 fd:00 56678 /lib/libc-2.11.so
00336000-00337000 rw-p 00170000 fd:00 56678 /lib/libc-2.11.so
00337000-0033a000 rw-p 00000000 00:00 0
0055f000-00560000 r-xp 00000000 00:00 0 [vdso]
005f6000-005fa000 r-xp 00000000 fd:00 1331 /lib/libattr.so.1.1.0
005fa000-005fb000 rw-p 00003000 fd:00 1331 /lib/libattr.so.1.1.0
0062d000-00638000 r-xp 00000000 fd:00 10441 /lib/libnss_files-2.11.so
00638000-00639000 r--p 0000a000 fd:00 10441 /lib/libnss_files-2.11.so
00639000-0063a000 rw-p 0000b000 fd:00 10441 /lib/libnss_files-2.11.so
008a3000-008a5000 r-xp 00000000 fd:00 15448 /lib/libpam_misc.so.0.82.0
008a5000-008a6000 rw-p 00001000 fd:00 15448 /lib/libpam_misc.so.0.82.0
00928000-0092c000 r-xp 00000000 fd:00 1332 /lib/libcap.so.2.16
0092c000-0092d000 rw-p 00003000 fd:00 1332 /lib/libcap.so.2.16
00992000-00995000 r-xp 00000000 fd:00 56684 /lib/libdl-2.11.so
00995000-00996000 r--p 00002000 fd:00 56684 /lib/libdl-2.11.so
00996000-00997000 rw-p 00003000 fd:00 56684 /lib/libdl-2.11.so
009f3000-00a0f000 r-xp 00000000 fd:00 56687 /lib/libselinux.so.1
00a0f000-00a10000 r--p 0001b000 fd:00 56687 /lib/libselinux.so.1
00a10000-00a11000 rw-p 0001c000 fd:00 56687 /lib/libselinux.so.1
00c8b000-00c97000 r-xp 00000000 fd:00 15447 /lib/libpam.so.0.82.1
00c97000-00c98000 rw-p 0000b000 fd:00 15447 /lib/libpam.so.0.82.1
00e6f000-00e85000 r-xp 00000000 fd:00 15446 /lib/libaudit.so.1.0.0
00e85000-00e86000 r--p 00015000 fd:00 15446 /lib/libaudit.so.1.0.0
00e86000-00e87000 rw-p 00016000 fd:00 15446 /lib/libaudit.so.1.0.0
00ea9000-00ec6000 r-xp 00000000 fd:00 51325
/lib/libgcc_s-4.4.2-20091027.so.1
00ec6000-00ec7000 rw-p 0001c000 fd:00 51325
/lib/libgcc_s-4.4.2-20091027.so.1
00f05000-00f0c000 r-xp 00000000 fd:00 56680 /lib/librt-2.11.so
00f0c000-00f0d000 r--p 00006000 fd:00 56680 /lib/librt-2.11.so
00f0d000-00f0e000 rw-p 00007000 fd:00 56680 /lib/librt-2.11.so
01724000-017a9000 rw-p 00000000 00:00 0 [heap]
b7627000-b7827000 r--p 00000000 fd:00 12545
/usr/lib/locale/locale-archive
b7827000-b782a000 rw-p 00000000 00:00 0
b783b000-b7842000 r--s 00000000 fd:00 10739
/usr/lib/gconv/gconv-modules.cache
b7842000-b7843000 rw-p 00000000 00:00 0
bfcce000-bfce3000 rw-p 00000000 00:00 0 [stack]
[warner@Fedora12-Dev ~]$
13 years, 9 months
allow_exec{mem,stack} default to on?
by Klaus Lichtenwalder
Hi,
just checked to freshly installed Fedora 12 machines, and found
allow_execmem --> on
allow_execstack --> on
Is there a reason for this, as the comment in semanage strongly
discourages it? Or did I install a package that switches those booleans?
Klaus
--
------------------------------------------------------------------------
Klaus Lichtenwalder, Dipl. Inform., http://lklaus.homelinux.org/Klaus/
PGP Key fingerprint: A5C0 F73A 2C83 96EE 766B 9C62 DB6D 1258 0E9B B6D1
13 years, 9 months
How to handle cron jobs?
by Stefan Schulze Frielinghaus
Hi all,
on one of my servers (running CentOS 5.4) is a cron job installed by
default which checks the status of my software array on a weekly base.
The script is the following: /etc/cron.weekly/99-raid-check (is shipped
via mdadm)
Having a look at other cron jobs most run as bin_t and call a binary
e.g. logrotate or whatever and do a simple domtrans. The raid check
script only uses basic commands like if/grep/cat and so on. What would
be the best way to write a policy for such a script with the interest to
get it included into RHEL/Fedora or maybe even refpolicy (Chris: Is this
even interesting for refpolicy or should we exclude such tiny policies
because this one seems to be shipped only by RHEL/Fedora).
Just to make it precise: What would be the best way to write a policy
for such tiny cron job? I suppose it would be cron_system_entry()
because prelink uses it and has its own type. All others I have seen are
using domtrans().
cheers,
Stefan
13 years, 9 months
vbetool denied
by Kirk Lowery
I'm running a newly installed, uptodate Fedora 12 box. Is there any reason
by vbetools is denied? From dmesg:
type=1400 audit(1262025694.652:4): avc: denied { mmap_zero } for pid=598
comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023
tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 t
class=memprotect
Is this a problem with my local system, or a more general bug? And what is
the best way to fix this?
TIA!
Kirk
13 years, 9 months
No AVC when using non-standard SSH port
by Jorge Fábregas
Hello everyone,
I'm using Fedora 12 and was wondering why, If I I run my sshd on a non-
standard port...why don't SELinux registers an access violation?
I see that "ssh_port_t" is there (attached to port 22) ... Is this not
implemented yet for SSHD?
Thanks,
Jorge
13 years, 9 months
policy for mgetty fax receive and new_fax
by Klaus Lichtenwalder
Hi,
just tried receiving a fax with mgetty (and notifying me via email with
the attached fax)
Watching all denials flowing by (permissive mode,
selinux-policy-targeted-3.6.32-59.fc12.noarch) I'm wondering whether
someone already started preparing a policy or whether I should try to
start it on myself? Anyone knows? Google does not find much of value
Klaus
--
------------------------------------------------------------------------
Klaus Lichtenwalder, Dipl. Inform., http://lklaus.homelinux.org/Klaus/
PGP Key fingerprint: A5C0 F73A 2C83 96EE 766B 9C62 DB6D 1258 0E9B B6D1
13 years, 9 months
