exec_logging (and more) not working

[timbgo]

And also audit_chdir isn't working.

Code: Select all

g0n ~ # gradm -S
The RBAC system is currently enabled.
g0n ~ # grep RBAC /proc/$$/status
RBAC:   admin:S:/
g0n ~ # cat /proc/sys/kernel/grsecurity/exec_logging
1
g0n ~ # cat /proc/sys/kernel/grsecurity/audit_chdir
1
g0n ~ #


Another terminal, where I am just root (I'm showing just part of unrelated tailf'd messages; this is a simple copy-paste):

Code: Select all

Nov  7 14:28:40 g0n dhcpcd[17140]: eth1: removing route to 192.168.1.0/24
Nov  7 14:29:15 g0n smartd[3004]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 118 to 119
Nov  7 14:36:41 g0n dhcpcd[17140]: eth1: ignoring RA from fe80::1 (no public prefix, no managed address)

g0n log #
g0n log # date
Sat  7 Nov 14:41:46 CET 2015
g0n log # jobs
[1]+  Running                 tailf messages &
g0n log # date
Sat  7 Nov 14:48:10 CET 2015
g0n log # cd
g0n ~ # cd -
/var/log
g0n log # Nov  7 14:49:28 g0n postfix/tlsmgr[17805]: tlsmgr_cache_run_event: start TLS smtp session cache cleanup

g0n log #


It has always worked for me, the exec_logging and the audit_chdir.

It can be seen in other topics of mine, just one example:

crontab RBAC policy
viewtopic.php?f=5&t=4253

What could this be?

(I had searched forums for exec_logging and haven't found this mentioned.)

[timbgo]

To me, this is somewhat alarming.

I'm not able to figure out if there's anything that I should have posted upfront. But a few following things I believe should help.

Code: Select all

# uname -a
Linux g0n 4.2.5-hardened-151103 #1 SMP PREEMPT Wed Nov 4 01:18:05 CET 2015 x86_64 AMD Phenom(tm) II X4 965 Processor AuthenticAMD GNU/Linux
#

The very last "exec of" to be found in my /var/log/messages:

Code: Select all

Nov  7 03:12:43 g0n kernel: grsec: (admin:S:/) exec of /usr/bin/updatedb (/usr/bin/updatedb -f  ) by /usr/bin/updatedb[mlocate:29801] uid/euid:0/0 gid/egid:0/0, parent /etc/cron.daily/mlocate[mlocate:29793] uid/euid:0/0 gid/egid:0/0


(which is the time when my dcron runs its daily scheduled tasks.

The last "chdir to" to be found in my /var/log/messages:

Code: Select all

Nov  7 03:12:43 g0n kernel: grsec: (admin:S:/) chdir to /usr/local by /usr/bin/updatedb[updatedb:29801] uid/euid:0/0 gid/egid:0/0, parent /etc/cron.daily/mlocate[mlocate:29793] uid/euid:0/0 gid/egid:0/0


And it's me guessing (and only as I'm writing this), but, let me find the link:

Syslog-ng from Delay Logging to BrokenPipe/no Logging
https://forums.gentoo.org/viewtopic-t-1001994.html

it could be related to the:

Code: Select all

# equery  l syslog-ng
 * Searching for syslog-ng ...
[IP-] [  ] app-admin/syslog-ng-3.7.2:0


[to the] syslog-ng.

And not a grsecurity issue, other than... if it, who knows, for some reason, does not work with grsec (which can be lots of reasons).

I think I should report it on Gentoo.

spender and/or PaX Team, I'll be periodically logging in (in ever increasing intervals only), to see if you have any comments/other on this issue, since...

[Since] surely I am by no means in the world very competent here, and I don't know anything about what this really is for sure.

(
I'll however take it that I am probably right it is the new syslog-ng, if by downgrading to 3.4.8 which always worked, the problem goes away.

And readers will find about it in that Gentoo Forums topic, not here, unless I get different comments/other from Grsec devs.

Even before downgrading to 3.4.8 it worked after restarting syslog-ng (I got all the "exec of"'s for the emerging process, and the "chdir"'s in the /var/log/messages)

But I am back to:

Code: Select all

# equery  l syslog-ng
 * Searching for syslog-ng ...
 [IP-] [  ] app-admin/syslog-ng-3.4.8:0
#


and there is no more of this issue)

Regards!

[timbgo]

I apologize for misposting this (in case it has nothing to do with grsec). But it's just a tiny part missing.

I have posted about this, giving the links, on:

scary time stamp
https://bugs.gentoo.org/show_bug.cgi?id=533328#c12

and:

some logging stops working
https://github.com/balabit/syslog-ng/issues/766

And just for completeness, this is what also happened back when I had 3.7.2 installed (that was yesterday or the day before):

Code: Select all

top - 16:39:50 up 3 days,  6:41,  2 users,  load average: 1.61, 1.49, 1.64
Tasks: 165 total,   2 running, 162 sleeping,   1 stopped,   0 zombie
%Cpu(s): 13.3 us, 17.2 sy,  0.0 ni, 69.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 s
KiB Mem : 16402256 total,    96436 free,  1018264 used, 15287556 buff/cache
KiB Swap:        0 total,        0 free,        0 used. 15294576 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND   
10368 root      20   0  350984   4252   2836 R 127.5  0.0   1030:13 syslog-ng
 3092 root      20   0  255676  44484   7928 S   1.7  0.3 152:43.62 X         
    7 root      20   0       0      0      0 S   1.0  0.0  14:47.80 rcu_preem+
10295 root      20   0   24940   2928   2484 S   0.7  0.0  14:51.61 top       


(notice the %CPU:

Code: Select all

127.5  0.0   1030:13 syslog-ng


which is 127% of 400% (it's a 4 core AMD64)

Restarting it:

Code: Select all

/etc/init.d/syslog-ng restart


(note, if relevant: I restarted also dcron and postfix along)

I think I remember that the restarting solved the issue, in the sense that there was no processor power drain anymore.

This is now my complete report.

Regards!

[spender]

I don't have time to read all the posts, but what comes to mind is perhaps you set the audit_group sysctl by accident? That would prevent logging of those events except for processes running with the group you set.

-Brad

[timbgo]

I was fully busy ever since a day or two since I posted here. Still little time available..
(And I did check if there were replies... probably wasn't looking carefully enough... Sorry.)

I don't have time to read all the posts, but what comes to mind is perhaps you set the audit_group sysctl by accident? That would prevent logging of those events except for processes running with the group you set.

-Brad

No, it's not that. It's the issue with syslog-ng. Because it always goes away when I simply revert to the old:

Code: Select all

app-admin/syslog-ng-3.4.8


Any newer syslog-ng appears to not work, or have some issues, with grsec-hardened kernel.

Have a look at what Tibor, one of the authors (if not the leader) of Syslog-ng says at:

https://github.com/balabit/syslog-ng/issues/766

...
but this exec_logging should be an other problem
...

If I find time to delve into this, then I first would need to see how these issues now fare:

PAX terminating task on /usr/bin/gdb
viewtopic.php?f=3&t=4137&#p14962

and (same issue), on Gentoo Forums
:
GNU debugger checking for PaX and refusing to work with it
https://forums.gentoo.org/viewtopic-t-1011162.html
(where even PaX Team logged in to post)

and on Bugzilla:

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

Because I couldn't get the trace if GNU debugger is still bashing grsec like that...

And I don't use non-grsec kernels.

Can't promise to find time at all, but wanted to post this, to update the readers, and our kind developers.

(And in case I somehow find time, to know a little more before I begin.)

Regards!