Get (some old version?, a fork?) of GNU Debugger to work with PaX?

[timbgo]

PAX terminating task on /usr/bin/gdb
======================
(I may change the title later if I get to understand more in depth the issue.)

I have an occurence like this each 1hour 10min. It's been so for more than a day now (but I couldn't report earlier):

Code: Select all

Jan 31 11:22:04 g0n postfix/qmgr[2736]: A415438092E: from=<[email protected]>, size=1953, nrcpt=1 (queue active)
Jan 31 11:22:04 g0n kernel: [104182.533886] grsec: exec of /usr/libexec/postfix/trivial-rewrite (trivial-rewrite -n rewrite -t unix -u -D ) by /usr/libexec/postfix/trivial-rewrite[master:20603] uid/euid:0/0 gid/egid:0/0, parent /usr/libexec/postfix/master[master:2734] uid/euid:0/0 gid/egid:0/0
Jan 31 11:22:04 g0n postfix/trivial-rewrite[20603]: running: PATH=/bin:/usr/bin:/usr/local/bin; export PATH; (echo cont;?echo where) | gdb /usr/libexec/postfix/trivial-rewrite 20603 2>&1?>/etc/postfix/trivial-rewrite.20603.log & sleep 5
Jan 31 11:22:04 g0n kernel: [104182.541484] grsec: exec of /bin/bash (sh -c PATH=/bin:/usr/bin:/usr/local/bin; export PATH; (echo cont; echo where) | gdb /usr/libexec/postfix/trivial-rewrite 20603 2) by /bin/bash[trivial-rewrite:20605] uid/euid:0/0 gid/egid:0/0, parent /usr/libexec/postfix/trivial-rewrite[trivial-rewrite:20603] uid/euid:0/0 gid/egid:0/0
Jan 31 11:22:04 g0n kernel: [104182.543763] grsec: exec of /bin/sleep (sleep 5 ) by /bin/sleep[sh:20608] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:20605] uid/euid:0/0 gid/egid:0/0
Jan 31 11:22:04 g0n kernel: [104182.544128] grsec: exec of /usr/bin/gdb (gdb /usr/libexec/postfix/trivial-rewrite 20603 ) by /usr/bin/gdb[sh:20607] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:20605] uid/euid:0/0 gid/egid:0/0
Jan 31 11:22:04 g0n kernel: [104182.554031] grsec: exec of /usr/bin/iconv (iconv -l ) by /usr/bin/iconv[gdb:20609] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/gdb[gdb:20607] uid/euid:0/0 gid/egid:0/0
Jan 31 11:22:04 g0n kernel: [104182.582967] grsec: process /usr/libexec/postfix/trivial-rewrite(trivial-rewrite:20603) attached to via ptrace by /usr/bin/gdb[gdb:20607] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:20605] uid/euid:0/0 gid/egid:0/0
Jan 31 11:22:04 g0n kernel: [104182.587538] PAX: execution attempt in: <anonymous mapping>, 2e72ae02000-2e72ae05000 2e72ae02000
Jan 31 11:22:04 g0n kernel: [104182.587553] PAX: terminating task: /usr/bin/gdb(gdb):20612, uid/euid: 0/0, PC: 000002e72ae02000, SP: 000003c67b8da300
Jan 31 11:22:04 g0n kernel: [104182.587562] PAX: bytes at PC: cc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jan 31 11:22:04 g0n kernel: [104182.587596] PAX: bytes at SP-8: 000002e72ae02000 000000166fa61ec0 be59ba04f5c2c100 000000166f42e0e0 000000166fa62000 000000166fa61ec0 00000016712c0d70 000000166f42e0e0 0000000000000000 000003c67b8da3d0 000000166f3d99a1
Jan 31 11:22:04 g0n kernel: [104182.587648] grsec: bruteforce prevention initiated for the next 30 minutes or until service restarted, stalling each fork 30 seconds.  Please investigate the crash report for /usr/bin/gdb[gdb:20612] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/gdb[gdb:20607] uid/euid:0/0 gid/egid:0/0
Jan 31 11:22:04 g0n kernel: [104182.587683] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/gdb[gdb:20612] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/gdb[gdb:20607] uid/euid:0/0 gid/egid:0/0
Jan 31 11:22:09 g0n kernel: [104187.548775] grsec: chdir to /var/spool/postfix by /usr/libexec/postfix/trivial-rewrite[trivial-rewrite:20603] uid/euid:0/0 gid/egid:0/0, parent /usr/libexec/postfix/master[master:2734] uid/euid:0/0 gid/egid:0/0
Jan 31 11:22:09 g0n kernel: [104187.551995] grsec: exec of /usr/libexec/postfix/smtp (smtp -t unix -u -D ) by /usr/libexec/postfix/smtp[master:20613] uid/euid:0/0 gid/egid:0/0, parent /usr/libexec/postfix/master[master:2734] uid/euid:0/0 gid/egid:0/0
Jan 31 11:22:09 g0n postfix/smtp[20613]: running: PATH=/bin:/usr/bin:/usr/local/bin; export PATH; (echo cont;?echo where) | gdb /usr/libexec/postfix/smtp 20613 2>&1?>/etc/postfix/smtp.20613.log & sleep 5
Jan 31 11:22:09 g0n kernel: [104187.563932] grsec: exec of /bin/bash (sh -c PATH=/bin:/usr/bin:/usr/local/bin; export PATH; (echo cont; echo where) | gdb /usr/libexec/postfix/smtp 20613 2>&1 >/etc/p) by /bin/bash[smtp:20614] uid/euid:0/0 gid/egid:0/0, parent /usr/libexec/postfix/smtp[smtp:20613] uid/euid:0/0 gid/egid:0/0
Jan 31 11:22:09 g0n kernel: [104187.571133] grsec: exec of /bin/sleep (sleep 5 ) by /bin/sleep[sh:20617] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:20614] uid/euid:0/0 gid/egid:0/0
Jan 31 11:22:09 g0n kernel: [104188.127503] grsec: exec of /usr/bin/gdb (gdb /usr/libexec/postfix/smtp 20613 ) by /usr/bin/gdb[sh:20616] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:20614] uid/euid:0/0 gid/egid:0/0
Jan 31 11:22:09 g0n kernel: [104188.139433] grsec: exec of /usr/bin/iconv (iconv -l ) by /usr/bin/iconv[gdb:20618] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/gdb[gdb:20616] uid/euid:0/0 gid/egid:0/0
Jan 31 11:22:09 g0n kernel: [104188.170455] grsec: process /usr/libexec/postfix/smtp(smtp:20613) attached to via ptrace by /usr/bin/gdb[gdb:20616] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:20614] uid/euid:0/0 gid/egid:0/0
Jan 31 11:22:09 g0n kernel: [104188.175664] PAX: execution attempt in: <anonymous mapping>, 29549134000-29549137000 29549134000
Jan 31 11:22:09 g0n kernel: [104188.175678] PAX: terminating task: /usr/bin/gdb(gdb):20621, uid/euid: 0/0, PC: 0000029549134000, SP: 000003ce2e83d2f0
Jan 31 11:22:09 g0n kernel: [104188.175687] PAX: bytes at PC: cc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jan 31 11:22:09 g0n kernel: [104188.175721] PAX: bytes at SP-8: 0000029549134000 0000004e8f2b9ec0 bb8fa1bfa09e5600 0000004e8ec860e0 0000004e8f2ba000 0000004e8f2b9ec0 0000004e8ffa5e20 0000004e8ec860e0 0000000000000000 000003ce2e83d3c0 0000004e8ec319a1
Jan 31 11:22:09 g0n kernel: [104188.175770] grsec: bruteforce prevention initiated for the next 30 minutes or until service restarted, stalling each fork 30 seconds.  Please investigate the crash report for /usr/bin/gdb[gdb:20621] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/gdb[gdb:20616] uid/euid:0/0 gid/egid:0/0
Jan 31 11:22:09 g0n kernel: [104188.175805] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/gdb[gdb:20621] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/gdb[gdb:20616] uid/euid:0/0 gid/egid:0/0


At first these occurences made me worry, but after a lot of analysis of logs, packet capture, comparison with my master air-gapped Gentoo system of this cloned system for occasional thoroughly analyzed online time, and seeking of probable causes, I believe it is down to the gdb, some lack of support in gdb for hardening. I believe it is the cause of the "brute prevention initiated" as the log says.

My Grsec-hardened Gentoo has most of the hardening options set. Here is the Grsecurity configuration from my config-3.17.6-hardened:

Code: Select all

# Grsecurity
#
CONFIG_PAX_KERNEXEC_PLUGIN=y
CONFIG_PAX_PER_CPU_PGD=y
CONFIG_TASK_SIZE_MAX_SHIFT=42
CONFIG_PAX_USERCOPY_SLABS=y
CONFIG_GRKERNSEC=y
# CONFIG_GRKERNSEC_CONFIG_AUTO is not set
CONFIG_GRKERNSEC_CONFIG_CUSTOM=y
CONFIG_GRKERNSEC_TPE_UNTRUSTED_GID=100
CONFIG_GRKERNSEC_SYMLINKOWN_GID=1006

#
# Customize Configuration
#

#
# PaX
#
CONFIG_PAX=y

#
# PaX Control
#
# CONFIG_PAX_SOFTMODE is not set
# CONFIG_PAX_PT_PAX_FLAGS is not set
CONFIG_PAX_XATTR_PAX_FLAGS=y
CONFIG_PAX_NO_ACL_FLAGS=y
# CONFIG_PAX_HAVE_ACL_FLAGS is not set
# CONFIG_PAX_HOOK_ACL_FLAGS is not set

#
# Non-executable pages
#
CONFIG_PAX_NOEXEC=y
CONFIG_PAX_PAGEEXEC=y
CONFIG_PAX_EMUTRAMP=y
CONFIG_PAX_MPROTECT=y
# CONFIG_PAX_MPROTECT_COMPAT is not set
# CONFIG_PAX_ELFRELOCS is not set
CONFIG_PAX_KERNEXEC=y
CONFIG_PAX_KERNEXEC_PLUGIN_METHOD_BTS=y
# CONFIG_PAX_KERNEXEC_PLUGIN_METHOD_OR is not set
CONFIG_PAX_KERNEXEC_PLUGIN_METHOD="bts"

#
# Address Space Layout Randomization
#
CONFIG_PAX_ASLR=y
CONFIG_PAX_RANDKSTACK=y
CONFIG_PAX_RANDUSTACK=y
CONFIG_PAX_RANDMMAP=y

#
# Miscellaneous hardening features
#
CONFIG_PAX_MEMORY_SANITIZE=y
CONFIG_PAX_MEMORY_STACKLEAK=y
CONFIG_PAX_MEMORY_STRUCTLEAK=y
CONFIG_PAX_MEMORY_UDEREF=y
CONFIG_PAX_REFCOUNT=y
CONFIG_PAX_CONSTIFY_PLUGIN=y
CONFIG_PAX_USERCOPY=y
# CONFIG_PAX_USERCOPY_DEBUG is not set
CONFIG_PAX_SIZE_OVERFLOW=y
CONFIG_PAX_LATENT_ENTROPY=y

#
# Memory Protections
#
CONFIG_GRKERNSEC_KMEM=y
# CONFIG_GRKERNSEC_IO is not set
CONFIG_GRKERNSEC_BPF_HARDEN=y
CONFIG_GRKERNSEC_PERF_HARDEN=y
# CONFIG_GRKERNSEC_RAND_THREADSTACK is not set
CONFIG_GRKERNSEC_PROC_MEMMAP=y
CONFIG_GRKERNSEC_KSTACKOVERFLOW=y
CONFIG_GRKERNSEC_BRUTE=y
CONFIG_GRKERNSEC_MODHARDEN=y
CONFIG_GRKERNSEC_HIDESYM=y
CONFIG_GRKERNSEC_RANDSTRUCT=y
CONFIG_GRKERNSEC_RANDSTRUCT_PERFORMANCE=y
CONFIG_GRKERNSEC_KERN_LOCKOUT=y

#
# Role Based Access Control Options
#
# CONFIG_GRKERNSEC_NO_RBAC is not set
CONFIG_GRKERNSEC_ACL_HIDEKERN=y
CONFIG_GRKERNSEC_ACL_MAXTRIES=3
CONFIG_GRKERNSEC_ACL_TIMEOUT=30

#
# Filesystem Protections
#
CONFIG_GRKERNSEC_PROC=y
CONFIG_GRKERNSEC_PROC_USER=y
CONFIG_GRKERNSEC_PROC_ADD=y
CONFIG_GRKERNSEC_LINK=y
CONFIG_GRKERNSEC_SYMLINKOWN=y
CONFIG_GRKERNSEC_FIFO=y
CONFIG_GRKERNSEC_SYSFS_RESTRICT=y
# CONFIG_GRKERNSEC_ROFS is not set
CONFIG_GRKERNSEC_DEVICE_SIDECHANNEL=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_CHMOD=y
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
CONFIG_GRKERNSEC_CHROOT_MKNOD=y
CONFIG_GRKERNSEC_CHROOT_SHMAT=y
CONFIG_GRKERNSEC_CHROOT_UNIX=y
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
CONFIG_GRKERNSEC_CHROOT_NICE=y
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
CONFIG_GRKERNSEC_CHROOT_CAPS=y
# CONFIG_GRKERNSEC_CHROOT_INITRD is not set

#
# Kernel Auditing
#
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set
CONFIG_GRKERNSEC_EXECLOG=y
CONFIG_GRKERNSEC_RESLOG=y
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y
CONFIG_GRKERNSEC_AUDIT_PTRACE=y
CONFIG_GRKERNSEC_AUDIT_CHDIR=y
CONFIG_GRKERNSEC_AUDIT_MOUNT=y
CONFIG_GRKERNSEC_SIGNAL=y
CONFIG_GRKERNSEC_FORKFAIL=y
CONFIG_GRKERNSEC_TIME=y
CONFIG_GRKERNSEC_PROC_IPADDR=y
CONFIG_GRKERNSEC_RWXMAP_LOG=y

#
# Executable Protections
#
CONFIG_GRKERNSEC_DMESG=y
CONFIG_GRKERNSEC_HARDEN_PTRACE=y
CONFIG_GRKERNSEC_PTRACE_READEXEC=y
CONFIG_GRKERNSEC_SETXID=y
CONFIG_GRKERNSEC_HARDEN_IPC=y
CONFIG_GRKERNSEC_TPE=y
CONFIG_GRKERNSEC_TPE_ALL=y
# CONFIG_GRKERNSEC_TPE_INVERT is not set
CONFIG_GRKERNSEC_TPE_GID=100

#
# Network Protections
#
CONFIG_GRKERNSEC_BLACKHOLE=y
CONFIG_GRKERNSEC_NO_SIMULT_CONNECT=y
# CONFIG_GRKERNSEC_SOCKET is not set

#
# Physical Protections
#
# CONFIG_GRKERNSEC_DENYUSB is not set

#
# Sysctl Support
#
CONFIG_GRKERNSEC_SYSCTL=y
CONFIG_GRKERNSEC_SYSCTL_ON=y

#
# Logging Options
#
CONFIG_GRKERNSEC_FLOODTIME=10
CONFIG_GRKERNSEC_FLOODBURST=3
CONFIG_KEYS=y
# CONFIG_PERSISTENT_KEYRINGS is not set
# CONFIG_BIG_KEYS is not set
# CONFIG_ENCRYPTED_KEYS is not set
CONFIG_KEYS_DEBUG_PROC_KEYS=y
CONFIG_SECURITY_DMESG_RESTRICT=y
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_XOR_BLOCKS=y
CONFIG_ASYNC_CORE=y
CONFIG_ASYNC_MEMCPY=y
CONFIG_ASYNC_XOR=y
CONFIG_ASYNC_PQ=y
CONFIG_ASYNC_RAID6_RECOV=y
CONFIG_CRYPTO=y

#


As the Seniors in Gentoo advise, I have started the transition to XATTR_PAX_FLAGS, and use paxctl-ng.

I currently use gdb debugger because of issues with applying TLS with my new provider in Postfix, I use it roughly as explained under non-interactive debugger on:

Postfix Debugging Howto
http://www.postfix.org/DEBUG_README.html

Just to mention with regard to the TPE issue which has an open bug IN_PROGRESS on bugs.gentoo.org

Bug 519566
https://bugs.gentoo.org/show_bug.cgi?id=519566

that I disabled tpe and tpe_restrict_all via sysctl:

Code: Select all

# cat /proc/sys/kernel/grsecurity/tpe
0
# cat /proc/sys/kernel/grsecurity/tpe_restrict_all
0
#


but it doesn't seem to change anything in this case (as it does with emerge and other python stuff).

The /usr/bin/gdb binary has by default, as I installed it with "emerge gdb":

Code: Select all

# paxctl-ng -v /usr/bin/gdb
/usr/bin/gdb:
      PT_PAX    : -e---
      XATTR_PAX : not found


which I changed:

Code: Select all

# paxctl-ng -F /usr/bin/gdb
# paxctl-ng -v /usr/bin/gdb
/usr/bin/gdb:
      PT_PAX    : -e---
      XATTR_PAX : -e---


and then I tried, hoping the issue would be relaxed:

Code: Select all

# paxctl-ng -m /usr/bin/gdb
# paxctl-ng -v /usr/bin/gdb
/usr/bin/gdb:
      PT_PAX    : -em--
      XATTR_PAX : -em--


But the issue wouldn't go away:

Code: Select all

Jan 31 13:41:12 g0n postfix/qmgr[21662]: A415438092E: from=<[email protected]>, size=1953, nrcpt=1 (queue active)
Jan 31 13:41:12 g0n kernel: [112535.267823] grsec: exec of /usr/libexec/postfix/trivial-rewrite (trivial-rewrite -n rewrite -t unix -u -D ) by /usr/libexec/postfix/trivial-rewrite[master:22640] uid/euid:0/0 gid/egid:0/0, parent /usr/libexec/postfix/master[master:2734] uid/euid:0/0 gid/egid:0/0
Jan 31 13:41:12 g0n postfix/trivial-rewrite[22640]: running: PATH=/bin:/usr/bin:/usr/local/bin; export PATH; (echo cont;?echo where) | gdb /usr/libexec/postfix/trivial-rewrite 22640 2>&1?>/etc/postfix/trivial-rewrite.22640.log & sleep 5
Jan 31 13:41:12 g0n kernel: [112535.274075] grsec: exec of /bin/bash (sh -c PATH=/bin:/usr/bin:/usr/local/bin; export PATH; (echo cont; echo where) | gdb /usr/libexec/postfix/trivial-rewrite 22640 2) by /bin/bash[trivial-rewrite:22642] uid/euid:0/0 gid/egid:0/0, parent /usr/libexec/postfix/trivial-rewrite[trivial-rewrite:22640] uid/euid:0/0 gid/egid:0/0
Jan 31 13:41:12 g0n kernel: [112535.276386] grsec: exec of /bin/sleep (sleep 5 ) by /bin/sleep[sh:22645] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:22642] uid/euid:0/0 gid/egid:0/0
Jan 31 13:41:12 g0n kernel: [112535.276772] grsec: exec of /usr/bin/gdb (gdb /usr/libexec/postfix/trivial-rewrite 22640 ) by /usr/bin/gdb[sh:22644] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:22642] uid/euid:0/0 gid/egid:0/0
Jan 31 13:41:12 g0n kernel: [112535.286078] grsec: exec of /usr/bin/iconv (iconv -l ) by /usr/bin/iconv[gdb:22646] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/gdb[gdb:22644] uid/euid:0/0 gid/egid:0/0
Jan 31 13:41:12 g0n kernel: [112535.311642] grsec: process /usr/libexec/postfix/trivial-rewrite(trivial-rewrite:22640) attached to via ptrace by /usr/bin/gdb[gdb:22644] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:22642] uid/euid:0/0 gid/egid:0/0
Jan 31 13:41:12 g0n kernel: [112535.316243] PAX: execution attempt in: <anonymous mapping>, 2de2802f000-2de28032000 2de2802f000
Jan 31 13:41:12 g0n kernel: [112535.316258] PAX: terminating task: /usr/bin/gdb(gdb):22649, uid/euid: 0/0, PC: 000002de2802f000, SP: 000003cbb08fa470
Jan 31 13:41:12 g0n kernel: [112535.316267] PAX: bytes at PC: cc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Jan 31 13:41:12 g0n kernel: [112535.316302] PAX: bytes at SP-8: 000002de2802f000 00000057380ebec0 e6c6b81c8df58500 0000005737ab80e0 00000057380ec000 00000057380ebec0 0000005738350880 0000005737ab80e0 0000000000000000 000003cbb08fa540 0000005737a639a1
Jan 31 13:41:12 g0n kernel: [112535.316352] grsec: bruteforce prevention initiated for the next 30 minutes or until service restarted, stalling each fork 30 seconds.  Please investigate the crash report for /usr/bin/gdb[gdb:22649] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/gdb[gdb:22644] uid/euid:0/0 gid/egid:0/0
Jan 31 13:41:12 g0n kernel: [112535.316387] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/gdb[gdb:22649] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/gdb[gdb:22644] uid/euid:0/0 gid/egid:0/0


I haven't used gdb much, and I really only tried what the Postfix wizards suggested for debugging, I can currently only stay at the outside of things with regard to debugging and all the logs filled with "no debugging symbols found"... I guess I'd be useful that I give the "stack trace when the process crashes", IIUC:

Code: Select all

# cat /etc/postfix/trivial-rewrite.22640.log
GNU gdb (Gentoo 7.8.1 vanilla) 7.8.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/libexec/postfix/trivial-rewrite...(no debugging symbols found)...done.
Attaching to program: /usr/libexec/postfix/trivial-rewrite, process 22640
Reading symbols from /lib64/libpcre.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/libpcre.so.1
Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /usr/lib64/libsqlite3.so.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/libsqlite3.so.0
Reading symbols from /usr/lib64/libdb-6.0.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib64/libdb-6.0.so
Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/libnss_compat.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libnss_compat.so.2
Reading symbols from /lib64/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib64/libnsl.so.1
Reading symbols from /lib64/libnss_nis.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libnss_nis.so.2
Reading symbols from /lib64/libnss_files.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/libnss_files.so.2
0x0000038f74eeb91a in waitpid () from /lib64/libc.so.6
(gdb) Continuing.
[Inferior 1 (process 22640) exited normally]
(gdb) (gdb) quit


If there is anything that any Senior here in Grsecurity forums finds time to kindly tell us about this issue, I'll be grateful.

I can also ask about this issue on Gentoo Forums, but I thought I'd post on my dearest of all FOSS programs' forum, that is Grsec Forums, first .

I'm mostly well these days, and I shouldn't be late to reply due to health issues. However, I have to say that I'm on alert with my unkind new provider and their disreputable friends, where even setting me up to accuse me of spamming seems to have been attempted against me, on top of undeniable censorship:

Postfix smtp-tls-wrapper, Bkp/Cloning Mthd, A Zerk Provider
https://forums.gentoo.org/viewtopic-t-999436.html

I hope some unpredictable prank from the aforementioned won't be in my way while I try and solve this issue. I will be back at intervals, although not very frequent, for a day and longer, to read possible replies, but I have to mention the above in case I am prevented by the aforementioned to keep my word. That is the sole reason I explain this situation of mine here. And I am sorry to have to put this for-that-eventuality disclaimer here.

Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr

[PaX Team]

can you post the output of

Code: Select all

grep PaX /proc/<pid of gdb>/status

please?

[timbgo]

Code: Select all

# grep PaX /proc/20408/status
PaX:   PemRs
#


[PaX Team]

ok so MPROTECT is really off yet it triggers on gdb - that's certainly not normal . can you tell me the steps to reproduce this?

[timbgo]

ok so MPROTECT is really off yet it triggers on gdb - that's certainly not
normal . can you tell me the steps to reproduce this?

To my best. I can try and reproduce how I did it.
emerge -s gdb gives me the version:

Code: Select all

   sys-devel/gdb
   Latest version available: 7.8.1
   Latest version installed: 7.8.1


What is in http://www.postfix.org/DEBUG_README.html#gdb under "... non-interactive debugger" is similar, but not same to what I have in my /etc/postfix/main.cf which lines I simply uncommented, without editing:

Code: Select all

debugger_command =
 PATH=/bin:/usr/bin:/usr/local/bin; export PATH; (echo cont;
 echo where) | gdb $daemon_directory/$process_name $process_id 2>&1
 >$config_directory/$process_name.$process_id.log & sleep 5


Also in my /etc/postfix/main.cf:

Code: Select all

debug_peer_level = 2
debug_peer_list = 127.0.0.1,195.29.150.2,195.29.150.5,178.218.164.164


and in my /etc/postfix/master.cf (just the lines that call the debugger):

Code: Select all

# cat /etc/postfix/master.cf | grep ' \-D'
smtp      inet  n       -       n       -       -       smtpd -D
tlsmgr    unix  -       -       n       1000?   1       tlsmgr -D
rewrite   unix  -       -       n       -       -       trivial-rewrite -D
smtp      unix  -       -       n       -       -       smtp -D
relay     unix  -       -       n       -       -       smtp -D


That's all IIRC. After that, I just reloaded with:

Code: Select all

# postfix reload


and those PAX "... terminating task: /usr/bin/gdb ..." and around showed up. Some mail was sent regardless, and even with TLSv1.2.

PaX Team, I am not completely sure if I need to tell more. Will check yet before I go to sleep which is rather soon. Else, tomorrow.
EDIT Sun 1 Feb 02:28:30 CET 2015
And I hope to check here first thing early in the morning {
]sic! Sun 1 Feb 08:06:12 CET 2015
}.
EDIT END

Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr

[timbgo]

I'm stuck with this, in the sense that it is not at all clear to me what causes this, described in previous posts.
There is some more information on Gentoo Forums on this issue:

Postfix smtp-tls-wrapper, Bkp/Cloning Mthd, A Zerk Provider
https://forums.gentoo.org/viewtopic-t-9 ... ml#7694556

Miroslav Rovis
Zagreb, Croatia
www.CroatiaFidelis.hr

[PaX Team]

i checked the gdb sources now and it's intentional behaviour (check gdb/common/linux-ptrace.c:linux_ptrace_test_ret_to_nx). they're trying to detect the presence of PaX/MPROTECT, though in a broken way since the code execution attempt on a non-executable page would fail on any recent CPU/kernel too...

[timbgo]

I trust you, PaX Team.

I'll take my (extensive, when available, currently am finally, and only now!, enabling RBAC hopefully successfully in my systems)...
I'll take my (extensive, when available) time to look it up.

Sad, sad, sad!
This is my peeve: that GNU mostly became SELinux supporters... which is denying all they started for: the freedom! There is no freedom without privacy and privacy is achieved only through security, and what true security for yuor privacy can you expect that program made by spies creates for you, for the Force and the Wisdom of the Universe's sake!
[the above line edited for clarity: Fri 20 Feb 20:22:39 CET 2015]
I'll try and follow you (as my low expertize permits) faithfully.
You, PaX Team and spender, remain my top heroes in FOSS.
Keep up the good spite for the good world of FOSS Linux users!

Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr

[timbgo]

Let everybody know:

GNU debugger checking for PaX and refusing to work with it
https://forums.gentoo.org/viewtopic-t-1011162.html

(Gentoo the grsecurity/PaX stronghold, lots of folks build grsec-hardened kernels there.)

[timbgo]

More I just wrote to reply to an opposing opinion to PaX Team's that I cited previously. Pls. see:

GNU debugger checking for PaX and refusing to work with it
https://forums.gentoo.org/viewtopic-t-1 ... ml#7706386

Thank you!

[timbgo]

The attachment with the important, basic for the bug, log, posted only a while ago:

https://541104.bugs.gentoo.org/attachment.cgi?id=397334

the bug:

https://bugs.gentoo.org/show_bug.cgi?id=541104
(GNU debugger employed via Postfix crashed PaX hardened kernel)

is now on Gentoo Bugzilla.

Devs, users, pls stand by PaX Team and spender here.

This is a direct dirty attack on their work.

The detractors of grsecurity as this one:

Grsecurity.net website down?
https://forums.gentoo.org/viewtopic-t-1 ... ml#7704316

appear to be bracing up for, basically, making sure their surveille and control your computers, brothers in *nix, should the worse of scenarios come to happen.

Think about it.

And if there's any of you sponsors with some any level serious means to spare, help here these two wizards. The FOSSdom is at stake, should any of those dirty players dirty wishes come to be.

[PaX Team]

uhm, Miro, please let's try to figure this out without all that drama, that doesn't serve any useful purpose. let's instead help the gentoo and gdb guys to resolve this to hopefully everyone's satisfaction.

[timbgo]

OK, PaX Team, I overreacted. Apologies.

[timbgo]

I looked up:

GNU debugger employed via Postfix crashed PaX hardened kernel
https://bugs.gentoo.org/show_bug.cgi?id=541104

and:

GNU debugger checking for PaX and refusing to work with it
https://forums.gentoo.org/viewtopic-t-1011162.html

and, since there is no new info, I was wondering has this issue been solved?

Regards,

Miroslav Rovis
Zagreb, Croatia
www.CroatiaFidelis.hr

[timbgo]

I may need to use debugger because I have an issue with Wireshark:

tshark -T fields -e data` crashes in versions after 2.0.x
https://bugs.wireshark.org/bugzilla/sho ... i?id=12616

Also probably new discussions about it will be at:

in >wireshark-2.0.2, tshark follow ssl stream segfaults
https://www.wireshark.org/lists/wiresha ... 00007.html
(the most recent message there)

the issue could be related to grsec-hardened kernel, but how then the issue disappeared when I downgraded to wireshark-2.0.2 ?

But I was really wondering, since in Gentoo there is now perfectly easy to patch sources with user patches ( as explained in:
https://wiki.gentoo.org/wiki//etc/portage/patches
), I was wondering, if gdb is still playing in such way (and it seems to me that it is), what would it take to patch it with a patch that removes those lines that check for pax, and install it and use it on a grsec-hardened kernel?

I still speak far too little C, but the patching of gdb sources, if anybody could do it, and that people could debug freely, would be great!

Regards!
---
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Try refute: rootkit hooks in kernel,
linux capabilities for intrusion? (Linus?)