linux-2.4.19-grsec-1.9.6 + Apache 2.0.40 + PHP 4.x + MySQL.

Discuss usability issues, general maintenance, and general support issues for a grsecurity-enabled system.

linux-2.4.19-grsec-1.9.6 + Apache 2.0.40 + PHP 4.x + MySQL.

Postby Martinez » Mon Sep 09, 2002 6:21 pm

Hi there.
I have some troubles with apps (as in topic) running on Linux kernel version 2.4.19 patched with grsecurity 1.9.6...
Before upgrading this kernel, I have it working propertly, and now PHP says, that he couldn't connect to mysqld...
May it be caused by inpropetly use of grsec protections?
My sets are:
#
# Grsecurity
#
CONFIG_GRKERNSEC=y
# CONFIG_GRKERNSEC_LOW is not set
# CONFIG_GRKERNSEC_MID is not set
# CONFIG_GRKERNSEC_HI is not set
CONFIG_GRKERNSEC_CUSTOM=y

#
# Buffer Overflow Protection
#
CONFIG_GRKERNSEC_STACK=y
CONFIG_GRKERNSEC_STACK_GCC=y
CONFIG_GRKERNSEC_PAX_RANDMMAP=y
CONFIG_GRKERNSEC_KMEM=y
CONFIG_GRKERNSEC_KSYMS=y

#
# ACL options
#
# CONFIG_GR_DEBUG is not set
# CONFIG_GRKERNSEC_ACL_CAPLOG is not set
CONFIG_GR_MAXTRIES=3
CONFIG_GR_TIMEOUT=30

#
# Filesystem Protections
#
CONFIG_GRKERNSEC_PROC=y
CONFIG_GRKERNSEC_PROC_USER=y
CONFIG_GRKERNSEC_PROC_ADD=y
CONFIG_GRKERNSEC_PROC_MEMMAP=y
CONFIG_GRKERNSEC_LINK=y
CONFIG_GRKERNSEC_FIFO=y
CONFIG_GRKERNSEC_CHROOT=y
CONFIG_GRKERNSEC_CHROOT_MOUNT=y
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
CONFIG_GRKERNSEC_CHROOT_PIVOT=y
CONFIG_GRKERNSEC_CHROOT_CHDIR=y
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
CONFIG_GRKERNSEC_CHROOT_CHMOD=y
CONFIG_GRKERNSEC_CHROOT_MKNOD=y
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
CONFIG_GRKERNSEC_CHROOT_NICE=y

#
# Executable Protections
#
CONFIG_GRKERNSEC_EXECVE=y
CONFIG_GRKERNSEC_DMESG=y
CONFIG_GRKERNSEC_RANDPID=y
# CONFIG_GRKERNSEC_TPE is not set

I will try to rollback to kernel 2.4.18-grsec, but I will be happy to may use kernel 2.4.19-grsec ;)
Please for some advise...
Martinez
 
Posts: 6
Joined: Mon Sep 09, 2002 6:12 pm

The solution...

Postby Martinez » Mon Sep 09, 2002 7:53 pm

Hi, it's me again ;)
I'm answering to myself, but this is for the future...
If anyone has that problem, as described, please try to connect NOT to <b>localhost</b>, but to <b>127.0.0.1</b>!
Function mysql_connect(); is made so, that name <i>localhost</i> means it shoult connect via UNIX socket <i>/path/to/mysql.sock</i>.
But with all these security options, connecting via UNIX socket is not allowed, so You should tell the mysql_connect(); function to connect via TCP port.
So <i>localhost</i> not allways mean <i>127.0.0.1</i> ;) A small difference...
I send BIG THX to Baseciq, who realize me this :)
Martinez
 
Posts: 6
Joined: Mon Sep 09, 2002 6:12 pm

Postby spender » Tue Sep 10, 2002 7:37 am

the security options don't make any difference. We don't do any kind of restrictions on unix sockets. I use mysql connecting to the unix socket fine on my machine.

-Brad
spender
 
Posts: 2185
Joined: Wed Feb 20, 2002 8:00 pm

Postby Martinez » Tue Sep 10, 2002 7:51 am

I don't know also, why this hapens...<br>
On linux-2.4.18-grsec all connections through unix sockets worked fine...<br>
All I know, that this hapens, when I have upgraded system to Slackware 8.1 (all components are reinstalled from packages included on install-cd, or rebuild from tarballs to make them work in SMP environment), and kernel version 2.4.19-grsec (config was imported from old kernel, I have only changed new grsecurity features in it)...<br>
Maybe all the fs + memory + network protections have much more influence to behaviour of nonprivileged users, such as Nobody, or daemon?<br>
Anyway... the kernel works fine and stable, so I have no worry about for now ;) <br>Big thx for your job!
Martinez
 
Posts: 6
Joined: Mon Sep 09, 2002 6:12 pm


Return to grsecurity support