grsecurity forums

Posted: **Thu Aug 22, 2013 1:42 am**

If you want the full picture, I believe you need to read the topic developed since some two days ago,
EDIT start
https://forums.grsecurity.net/viewtopic.php?f=3&t=3709
EDIT end
this I believe is the other side of the same coin what we will find here. So most of the time I won't go into details again on what is described in that first part.

Code: Select all: root@debinv35:/home/mr# uname -r 3.10.9-grsec-130821 root@debinv35:/home/mr# grub-mkconfig -o /boot/grub/grub.cfg Killed Generating grub.cfg ... Found linux image: /boot/vmlinuz-3.10.9-grsec-130821 Found initrd image: /boot/initrd.img-3.10.9-grsec-130821 Killed Killed Found linux image: /boot/vmlinuz-3.10.5-grsec-130807 Found initrd image: /boot/initrd.img-3.10.5-grsec-130807 Killed Killed Found linux image: /boot/vmlinuz-3.10.4-grsec-130806 Found initrd image: /boot/initrd.img-3.10.4-grsec-130806 Killed Killed Killed Syntax errors are detected in generated GRUB config file. Ensure that there are no errors in /etc/default/grub and /etc/grub.d/* files or please file a bug report with /boot/grub/grub.cfg.new file attached. done root@debinv35:/home/mr#

However, it's only Grsec/Pax that needs to be relaxed in some particular configuration options.

I kind of know it, because previous Grsec/Pax install on 3.10.5 kernel I checked, where Grsec/Pax I was yet only practicing installing (now the time for deploying more fully), runs grub-mkconfig faultlessly.

So, my current configuration with most of the Grsec/Pax bells and whistles deployed follows (somewhat based on Gentoo's grsecurity's guide, but I noticed they have been lagging behind, quite a few of the newer options not there either; so I'm really left with only the terse and precise kernel help).

Actually before the Grsecurity's 180 or so lines, I think I need to find some Debian security peculiarities if I haven't disabled all yet. Such as, and the readers should check this first when installing Grsec/Pax on Debian:

Code: Select all: # cat /boot/config-3.10.9-grsec-130821 | grep -i selin #

That is checking if anything pertaining to SELinux is installed. If it is, disable those options (Goes without saying, check on your own grsec kernel config file, don't just blindly copy my line(s). Applies to other places in my "prolific writing" (that's Pax Team's words) as well.

Code: Select all: │ │ Grsecurity ---> │ │ │ │ -*- Enable access key retention support │ │ │ │ < > TRUSTED KEYS │ │ │ │ < > ENCRYPTED KEYS │ │ │ │ [*] Enable the /proc/keys file by which keys may be viewed │ │ │ │ [ ] Restrict unprivileged access to the kernel syslog │ │ │ │ [ ] Enable different security models │ │ │ │ -*- Enable the securityfs filesystem │ │ │ │ [ ] Enable Intel(R) Trusted Execution Technology (Intel(R) TXT) │ │ │ │ Default security module (Unix Discretionary Access Controls) │ │ │ │ │ │

The above is just a paste. My pressing of '?' gives the name of the configuration option under "Enable the /proc/keys...":
CONFIG_KEYS_DEBUG_PROC_KEYS

I'll leave it, don't know if I need it or not... No. I'll deselect it. There's talk there of " LSM security " (Linux Securiy Model) and I know Grsec/Pax don't need those. So:

Code: Select all: │ │ [ ] Enable the /proc/keys file by which keys may be viewed │ │

I did find something peculiar. And will explain it verbosely. But first let's get you the long awaited Grsec/Pax configuration 180-something lines, that can be found in one consecutive row of lines in the /boot/config-my-grsec-patched-kernel.

Code: Select all: # # Security options # # # 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 # # Customize Configuration # # # PaX # CONFIG_PAX=y # # PaX Control # # CONFIG_PAX_SOFTMODE is not set # CONFIG_PAX_EI_PAX is not set CONFIG_PAX_PT_PAX_FLAGS=y # CONFIG_PAX_XATTR_PAX_FLAGS is not set 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=y # 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_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 is not set # # Memory Protections # CONFIG_GRKERNSEC_KMEM=y # CONFIG_GRKERNSEC_IO is not set CONFIG_GRKERNSEC_JIT_HARDEN=y CONFIG_GRKERNSEC_PERF_HARDEN=y CONFIG_GRKERNSEC_RAND_THREADSTACK=y CONFIG_GRKERNSEC_PROC_MEMMAP=y CONFIG_GRKERNSEC_BRUTE=y # CONFIG_GRKERNSEC_MODHARDEN is not set CONFIG_GRKERNSEC_HIDESYM=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 is not set # CONFIG_GRKERNSEC_PROC_USERGROUP is not set CONFIG_GRKERNSEC_LINK=y # CONFIG_GRKERNSEC_SYMLINKOWN is not set CONFIG_GRKERNSEC_FIFO=y CONFIG_GRKERNSEC_SYSFS_RESTRICT=y CONFIG_GRKERNSEC_ROFS=y 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_TPE is not set # # Network Protections # CONFIG_GRKERNSEC_RANDNET=y CONFIG_GRKERNSEC_BLACKHOLE=y CONFIG_GRKERNSEC_NO_SIMULT_CONNECT=y # CONFIG_GRKERNSEC_SOCKET is not set # # Sysctl Support # CONFIG_GRKERNSEC_SYSCTL=y CONFIG_GRKERNSEC_SYSCTL_ON=y # # Logging Options # CONFIG_GRKERNSEC_FLOODTIME=10 CONFIG_GRKERNSEC_FLOODBURST=6 CONFIG_KEYS=y # CONFIG_TRUSTED_KEYS is not set # CONFIG_ENCRYPTED_KEYS is not set CONFIG_KEYS_DEBUG_PROC_KEYS=y # CONFIG_SECURITY_DMESG_RESTRICT is not set # CONFIG_SECURITY is not set CONFIG_SECURITYFS=y # CONFIG_INTEL_TXT is not set CONFIG_DEFAULT_SECURITY_DAC=y CONFIG_DEFAULT_SECURITY="" CONFIG_XOR_BLOCKS=m CONFIG_ASYNC_CORE=m CONFIG_ASYNC_MEMCPY=m CONFIG_ASYNC_XOR=m CONFIG_ASYNC_PQ=m CONFIG_ASYNC_RAID6_RECOV=m CONFIG_CRYPTO=y

And now what I found.

Code: Select all: # cat /boot/config-3.10.9-grsec-130821 | grep PAX_MEMORY_SANITIZE #

(That is, it returns empty string!)
Not there! What do you mean?

Well, looking into the page in menuconfig where it should appear, and I'll show also the pages that open in between, from the initial to Grsecurity configuration, already shown above, so newbies might find it easier to follow.

Pls. note the pointer on each page, on the left, "->". That's not in the actual menuconfig pages, that is what I put there to tell you what to click to get the next page shown.

Code: Select all: │ │ [*] Grsecurity │ │ │ │ Configuration Method (Custom) ---> │ │ ->│ │ Customize Configuration ---> │ │

Code: Select all: ->│ │ PaX ---> │ │ │ │ Memory Protections ---> │ │ │ │ Role Based Access Control Options ---> │ │ │ │ Filesystem Protections ---> │ │ │ │ Kernel Auditing ---> │ │ │ │ Executable Protections ---> │ │ │ │ Network Protections ---> │ │ │ │ Sysctl Support ---> │ │ │ │ Logging Options ---> │ │

Code: Select all: │ │ [*] Enable various PaX features │ │ │ │ PaX Control ---> │ │ │ │ Non-executable pages ---> │ │ │ │ Address Space Layout Randomization ---> │ │ ->│ │ Miscellaneous hardening features ---> │ │

And the page that opens now does not have any:

Code: Select all: │ │ [*] Sanitize all freed memory │ │

at all! "Curious!" (I'm quoting myself here, from yesterday's post of mine, at end. Again, if you want to full picture, I believe you need to read the topic developed since some two days ago, this I believe is the other side of the same coin what we will find here).
Again, for those who would like to read faster than they can, the option just shown immediately above is not a paste from Debian, but a manual copy from one of my Gentoo box's 'make menuconfig' screen, where, surely, it shows.

Yesterday's tribulations with the use-after-free bug that crashed my Gentoo kernel which belong to a system that was offline at that time, but influenced, over local, non-connected-to-internet network, to which network all my boxes are connected, by one of my Debian clones systems (which I use online for browsing with Tor, and for downloading things etc.), which Debian box was online for pretty long intervals of time altogether...

Yesterday's tribulations that we had with the use-after-free bug would go on forever if Mathias Krause's recent contribution in that respect, which gave the kernel
CONFIG_PAX_MEMORY_SANITIZE=y option when you select it to get it to look like this: [*] Sanitize all freed memory. Just not in this Debian kernel of mine...

I'll show you this time the entire page, where that option is entirely missing. And these will be pastes.

Code: Select all: .config - Linux/x86 3.10.9 Kernel Configuration [...] rity > Customize Configuration > PaX > Miscellaneous hardening features ┌─────────────────── Miscellaneous hardening features ────────────────────┐ │ Arrow keys navigate the menu. <Enter> selects submenus --->. │ │ Highlighted letters are hotkeys. Pressing <Y> includes, <N> excludes, │ │ <M> modularizes features. Press <Esc><Esc> to exit, <?> for Help, </> │ │ for Search. Legend: [*] built-in [ ] excluded <M> module < > │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ [*] Sanitize kernel stack │ │ │ │ [*] Forcibly initialize local variables copied to userland │ │ │ │ [*] Prevent invalid userland pointer dereference │ │ │ │ [*] Prevent various kernel object reference counter overflows │ │ │ │ [*] Automatically constify eligible structures │ │ │ │ [*] Harden heap object copies between kernel and userland │ │ │ │ [*] Prevent various integer overflows in function size parameters│ │ │ │ [ ] Generate some entropy during boot │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ ├─────────────────────────────────────────────────────────────────────────┤ │ <Select> < Exit > < Help > < Save > < Load > │ └─────────────────────────────────────────────────────────────────────────┘

As you can see, I really meant entire page!

The missing [*] Sanitize all freed memory should feature on top, above: [*] Sanitize kernel stack.

This reconstruction is in so much detail is because I write to gain as many as I can more newbies into GNU/Linux because I very much enjoy using the nearly sole true free computing operating system which GNU/Linux is, and am fond of Grsecurity/Pax, because it is with Grsecurity/Pax that the free computing survives or perishes. And Grsecuriy/Pax is the absolute necessity for GNU/Linux in the sense of its freedom. Pls. look up my posts of the last two days for more...

What now?

I seem to have two issues to solve.

The one which i started with, that is I need to relax some, but which of so many, Grsec/Pax option so that grub-mkconfig works, and don't get killed.
Or use paxctl in some way maybe, or sysctl interface in some, but in which way, and which of these?

And I have this missing CONFIG_PAX_MEMORY_SANITIZE from options for Grsec/Pax alltogether.

I think I need to post this unresoved as it is right now.

But what I do then, no more delays, is dd-pack the images of the entire Debian system that IMO is the major cause of the havoc on my Gentoo box, because that compromised Debian system, actually the attacker programs/persons using it through bugs and my weak configuration of Grsec/Pax, also messed up a little my server of my local jigdo downloaded repo, where I can install clean Deabian from, the server being on another of my Gentoo boxes.
So this will be the last of the internet that this compromised Debian will see, because it goes into images.

It goes into images which I will keep for months if I remain physically free in my Croatia. In case either I learn enough to investigate, or in case some of the big guys, and I don't mean the developers who are busy with fixing holes in Linus's kernel, but I'll keep then just in case.

If I remain physically free in my Croatia. Because I'm a persecuted rightwing, tollerant rightwing with a lot of listening ear for honest leftwings, but I stand on the right, and my country has gone to traitors. Look up the first post of mine on these forums.grsecurity.net for a little more about it. Some of my friends have already been forced to emigrate, and some are in jail. The tall guy in some of this footage was again arrested lately, and it's only speech, but we would not be allowed to think and speak:

Al Jazeera, Clashes on the Eve of EU Referendum, Francišković et. Al. HRVATSKI
https://www.youtube.com/watch?v=_dX-ek2mPaU

So... I thought I would do other things, but how can I? I rely on the internet as any of you, and if I don't find my way around these obstacles I'll be left in the UDBA virtual cage (that's the tiny STASI in the countries that broke out of former stinking Yugoslavia, that still hold together via corrupt political "elites" and all kinds of traitors of their own people.. And to only think that the neighboring Hungary has just got out of debt ahead of time and is sending the IMF home! Hungary who we share the most of our history of harmony and friendship under the same crown of St. Isztvan... there were hegemonic tendencies on the part of the Hungarians later centuries, and we defeated them militarily for that reason... but no hegemony in earlier centuries, there was harmony... And my country is selling out to EU... Going the Greece's way... and restoring filthy yugoslavian ideology... And BTW, all kinds of services cooperate, surely with the biggest the most...)

So, all I can do now, and what I have to do now, is post this urgently.

But then, since the system is not defended properly because I haven't studied enough and understood well how to do it, esp. in these cicrumstances when some subjects lurk over eagerly at mere sight of the internet from my conputers...

But then I do need to restore and recreate my compromised system, and that may take longer.

This is the same issue as yesterday's, only on the other side, the non-properly Grsec/Pax configured Debian side.

I will however open a separate topic, and call it:

grsec: halting the system... kernel crash, the Debian side

Any advice on the two issues explained above?

Miroslav Rovis
Zagreb, Croatia

Posted: **Thu Aug 22, 2013 4:00 pm**

1. grub has nested function trampolines (you would have seen it in the kernel logs probably) so you'll either have to enable EMUTRAMP or disable MPROTECT on the grub binaries.
2. SANITIZE is not compatible with HIBERNATION, you'll have to choose.
3. please keep political, religious and other off topic content off this forum.

Posted: **Fri Aug 23, 2013 4:10 am**

PaX Team wrote:1. grub has nested function trampolines (you would have seen it in the kernel logs probably) so you'll either have to enable EMUTRAMP or disable MPROTECT on the grub binaries.

I managed to do this and have grub-mkconfig do its work. This is what I had prepared earlier. I hope it'll still be useful to someone, as most of my contributions so far, because I don't have solely my own interest in mind most never.
A reader with a need to fix quickly a similar problem of his own, and compare how Pax Team's advice worked on my system, skip ahead (find literals 'Pax Team's advice' in text below).
Every time there's the:

Code: Select all: Killed

line in the terminal (see the beginning of this topic), grsec logs what actually happened. I'm taking only a small number of lines out of the whole story of what that command (in top of page) does kern.log:

Code: Select all: Aug 22 11:40:37 debinv35 kernel: [37299.140424] grsec: exec of /usr/sbin/grub-probe (/usr/sbin/grub-probe --device /dev/sda1 --target=abstraction ) by /usr/sbin/grub-probe[10_linux:5655] uid/euid:0/0 gid/egid:0/0, parent /etc/grub.d/10_linux[10_linux:5651] uid/euid:0/0 gid/egid:0/0 Aug 22 11:40:37 debinv35 kernel: [37299.206087] PAX: execution attempt in: <stack>, 3b8bbc99000-3b8bbcbb000 3fffffdd000 Aug 22 11:40:37 debinv35 kernel: [37299.206097] PAX: terminating task: /usr/sbin/grub-probe(grub-probe):5655, uid/euid: 0/0, PC: 000003b8bbcb966c, SP: 000003b8bbcb93a8 Aug 22 11:40:37 debinv35 kernel: [37299.206101] PAX: bytes at PC: 41 bb 30 7a 43 00 49 ba 60 96 cb bb b8 03 00 00 49 ff e3 90 Aug 22 11:40:37 debinv35 kernel: [37299.206119] PAX: bytes at SP-8: 000003b8bbcb966c 0000000000429534 0000000000000083 0000000000003000 000000000007d000 00000000030fcd50 0000000000000000 0000000000000000 00000000009063eb 0000000000000000 0000000000000000 Aug 22 11:40:37 debinv35 kernel: [37299.206151] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/sbin/grub-probe[grub-probe:5655] uid/euid:0/0 gid/egid:0/0, parent /etc/grub.d/10_linux[10_linux:5651] uid/euid:0/0 gid/egid:0/0

That repeats some half a dozen times in similar fashion, each time there is a 'Killed' in the output.

Code: Select all: # file /usr/sbin/grub-probe /usr/sbin/grub-probe: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=52081b85f86c2b90210256da61f96c94e1074105, stripped #

I think maybe I could use paxctl on it...
It's only grub-probe that fails...

Anyways, I only got it to work after disabling all (because I went from right to left trying):

Code: Select all: -p-s-m-x-e-r [/usr/sbin/grub-probe]

and that's not very consoling.

This is the "minimum' to disable. Almost all!

Code: Select all: -p-s-m-x-eR- [/usr/sbin/grub-probe]

Wrong, well partly wrong, because that booted my system...
After reading Pax Team's advice, however, I got this to work, and I guess retain more of Pax program protection on it:

Code: Select all: # paxctl -z /usr/sbin/grub-probe # paxctl -RE /usr/sbin/grub-probe # paxctl -v /usr/sbin/grub-probe PaX control v0.7 Copyright 2004,2005,2006,2007,2009,2010,2011,2012 PaX Team <pageexec@freemail.hu> - PaX flags: --------E-R- [/usr/sbin/grub-probe] EMUTRAMP is enabled RANDMMAP is enabled #

Problem solved. I had looked into it longish to get the -p-s-m-x-e-r grub-update version to do the work, though, still have little notion now what exactly trampolines might mean, for now. Surely after your advice this looks much nicer.

PaX Team wrote:2. SANITIZE is not compatible with HIBERNATION, you'll have to choose.

I chose SANITIZE

PaX Team wrote:3. please keep political, religious and other off topic content off this forum.

I'll try to comply in most all occasions.

Thank you for your and Spender's great program. I'd like to be around not only to solve my problems of my computers' protection from intruders, but also because I'd like other people being able to use programs free of backdoors as well as to use the OS, the GNU/Linux that only in this fashion is free from either of the two evils mentioned previously in this very sentence, it is free from those only if your program is deployed, along with other measures having been taken.

So, I'd like to be around, if I can, and that goes in a fork, left and right (to name the branches somehow, no meaningful pun there), the left branch if I remain free in my life, such as if I don't go to jail for invented reasons like my friend Marko Francišković was jailed, if I remain free, which is uncertain, but possible, and, the right branch if you don't ban me from your site, which I hope you won't do.

What I would like to do, is, someday, possibly weeks, more likely months from now, once I am experienced in protecting my systems with Grsecurity/Pax, write proper user-to-user tips & tricks, esp. there where those are nearly completely lacking, such as in Debian, where they are lacking, and worse, where, as I hope you remember in my first post a few months ago, which you (either you Pax Team, or Spender) liked back then, pointing it out with a star to draw attention from the readers...
such as in Debian, which has a huge population of users and freedom in its veins since their establishment, but where Grsecurity/Pax was in aptitude severely dispromoted, vitriolically.

As I see it, OTOH, God is still in the constitutions of most all nations, and lots of people worldwide, of all the major religions, greet one another with God in their words and wishes... But if your request is that I may not even write "God bless all the readers!", and in only some of my posts I do, or mention God to point out what I mean by some expression, then pls. put me on moderation, because I can not ban God in words nor in thoughts from my life. Only probably about 1% or 2% of all my texts, taken as sentences, contain mentioning of God.

It never would be more than that much in the future either.

I wouldn't have written about politics a whole paragraph, if it wasn't for the persecution and the danger I am in, and the suffering of my persecuted friends. Politics is in only about two or three places in all that I wrote here, sufficiently marginally so, that any user searching for technical solution can skim through it quickly and skip it fast...
I don't intend to go on about politics any more, only that much I felt was humanely needed.

I hope you won't ban me, also bearing in mind my marginal but not completely negligable contribution here.

Again, my thanks go to you, Pax Team, and to Spender, for the great program Grsecurity/Pax!

Posted: **Fri Aug 23, 2013 9:20 pm**

Compiling and installing the changes offered above, where I chose to have, you'll see later, oh you will, this is a developing story, SANITIZE and forgot about HIBERNATION which was on from the initial, non-grsec kernel back when I developed this solution for protecting my SOHO (explained in my previous posts).
I told Pax Team that in the more proper deployment of grsecurity, where grub-mkconfig wouldn't work (that's in top of this topic and on), which deployment I finally embark on, having first embarked on mere installing of Grsec/Pax, which is somewhat hard for new Debian users...
...that in that deployment, for the above grub problems, only /usr/sbin/grub-probe needed fixing, as it is shown above (I hope the post is there, sure I am preparing this post offline, you would too, wait to read why!).
But I wasn't watching carefully.
Here's what happened, the entire output of installing the grsecurity-patched kernel package, this is, as the topis says, one of my Debian boxes.

Code: Select all: # dpkg -i linux- #Miroslav Rovis' comment: this was just me pressing tab linux-firmware-image_3.10.9-grsec-130823-2_amd64.deb linux-headers-3.10.9-grsec-130823_3.10.9-grsec-130823-2_amd64.deb linux-image-3.10.9-grsec-130823_3.10.9-grsec-130823-2_amd64.deb linux-libc-dev_3.10.9-grsec-130823-2_amd64.deb root@debinv38:/Cmn/src# dpkg -i linux-*.deb (Reading database ... 227155 files and directories currently installed.) Preparing to replace linux-firmware-image 3.10.9-grsec-130821-1 (using linux-firmware-image_3.10.9-grsec-130823-2_amd64.deb) ... Unpacking replacement linux-firmware-image ... Selecting previously unselected package linux-headers-3.10.9-grsec-130823. Unpacking linux-headers-3.10.9-grsec-130823 (from linux-headers-3.10.9-grsec-130823_3.10.9-grsec-130823-2_amd64.deb) ... Selecting previously unselected package linux-image-3.10.9-grsec-130823. Unpacking linux-image-3.10.9-grsec-130823 (from linux-image-3.10.9-grsec-130823_3.10.9-grsec-130823-2_amd64.deb) ... Preparing to replace linux-libc-dev 3.10.9-grsec-130821-1 (using linux-libc-dev_3.10.9-grsec-130823-2_amd64.deb) ... Unpacking replacement linux-libc-dev ... Setting up linux-firmware-image (3.10.9-grsec-130823-2) ... Setting up linux-headers-3.10.9-grsec-130823 (3.10.9-grsec-130823-2) ... Setting up linux-image-3.10.9-grsec-130823 (3.10.9-grsec-130823-2) ... update-initramfs: Generating /boot/initrd.img-3.10.9-grsec-130823 Generating grub.cfg ... Found background image: .background_cache.png Found linux image: /boot/vmlinuz-3.10.9-grsec-130823 Found initrd image: /boot/initrd.img-3.10.9-grsec-130823 Found linux image: /boot/vmlinuz-3.10.9-grsec-130821 Found initrd image: /boot/initrd.img-3.10.9-grsec-130821 Found linux image: /boot/vmlinuz-3.10.5-grsec-130807 Found initrd image: /boot/initrd.img-3.10.5-grsec-130807 Found linux image: /boot/vmlinuz-3.10.4-grsec-130806 Found initrd image: /boot/initrd.img-3.10.4-grsec-130806 Killed Syntax errors are detected in generated GRUB config file. Ensure that there are no errors in /etc/default/grub and /etc/grub.d/* files or please file a bug report with /boot/grub/grub.cfg.new file attached. done Setting up linux-libc-dev (3.10.9-grsec-130823-2) ... #

Now take note that there, the script/program thinks, are "Syntax errors".
But none, I checked. I checked by moving the /boot/grub/grub.cfg.new to /boot/grub/grub.cfg, because after careful inspection I saw there are no syntax errors.
And the system booted me into:

Code: Select all: # uname -r 3.10.9-grsec-130823 #

with the

Code: Select all: CONFIG_PAX_MEMORY_SANITIZE=y

that was sorely missing in 3.10.9-grsec-130821, given my cicumstances.
Having started to finally, slowly, figure out what some tricky things in the logs mean, I do have to say first that I admire how Grsec/Pax is arranged, and that the logging that this twin program offers is a great feature to have!
Having been slowly able to figure out what things there in the mumbo mean, I saw this thing happen at the end, around the time that grub-mkinstall script throws out the "Syntax errors" claim.
[[ Just a note before I paste those lines from /var/log/kern.log. It's hard for me to know the best measure, how many of the lines to post, and I thougt more is better than risking it to be too little, due to my insufficient competence in the matter, just pls. notice that the grsec/pax's throws the error at end of this paste, thank you ]]
[[ No I was wrong, this cannot be too much. I just looked up maybe most of grub-mkconfig script/program's output in kern.log and it's probably 15 times what I'll paste, and I did notice the "denied resource overstep", so far three times, no four times, and it's 30 times more, during the grub-mkconfig's run.., No, probably a 100 times more, there's a novel there...
1st denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/grub-mount

Code: Select all: Aug 23 13:53:06 debinv38 kernel: [39042.709455] grsec: exec of /sbin/blockdev (blockdev --setro /dev/sda2 ) by /sbin/blockdev[50mounted-tests:7064] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7057] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:06 debinv38 kernel: [39042.713801] grsec: exec of /bin/mount (mount -o ro -t LVM2_member /dev/sda2 /var/lib/os-prober/mount ) by /bin/mount[50mounted-tests:7065] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7057] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:06 debinv38 kernel: [39042.721525] grsec: exec of /bin/kmod (/sbin/modprobe -q -- fs-LVM2_member ) by /bin/kmod[kworker/u4:3:7067] uid/euid:0/0 gid/egid:0/0, parent /[kworker/u4:3:7066] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:06 debinv38 kernel: [39042.729908] grsec: exec of /bin/rmdir (rmdir /var/lib/os-prober/mount ) by /bin/rmdir[50mounted-tests:7068] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7057] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:06 debinv38 kernel: [39042.734435] grsec: exec of /sbin/blockdev (blockdev --setrw /dev/sda2 ) by /sbin/blockdev[50mounted-tests:7069] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7057] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:06 debinv38 kernel: [39042.739727] grsec: exec of /bin/readlink (readlink -f /dev/sda3 ) by /bin/readlink[os-prober:7071] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/os-prober[os-prober:7070] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:06 debinv38 kernel: [39042.744586] grsec: exec of /bin/grep (grep -q ^/dev/sda3 /tmp/os-prober.7wujid/raided-map ) by /bin/grep[os-prober:7072] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/os-prober[os-prober:6897] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:06 debinv38 kernel: [39042.749624] grsec: exec of /bin/grep (grep -q ^/dev/sda3 /tmp/os-prober.7wujid/swaps-map ) by /bin/grep[os-prober:7073] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/os-prober[os-prober:6897] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:06 debinv38 kernel: [39042.756879] grsec: exec of /bin/grep (grep -q ^/dev/sda3 /tmp/os-prober.7wujid/mounted-map ) by /bin/grep[os-prober:7074] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/os-prober[os-prober:6897] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:06 debinv38 kernel: [39042.762314] grsec: exec of /usr/bin/logger (logger -t os-prober debug: running /usr/lib/os-probes/50mounted-tests on /dev/sda3 ) by /usr/bin/logger[os-prober:7075] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/os-prober[os-prober:6897] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:06 debinv38 kernel: [39042.767991] grsec: exec of /usr/lib/os-probes/50mounted-tests (/usr/lib/os-probes/50mounted-tests /dev/sda3 ) by /usr/lib/os-probes/50mounted-tests[os-prober:7076] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/os-prober[os-prober:6897] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:06 debinv38 kernel: [39042.775983] grsec: exec of /sbin/blkid (blkid -o value -s TYPE /dev/sda3 ) by /sbin/blkid[50mounted-tests:7079] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7077] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:06 debinv38 kernel: [39042.785872] grsec: exec of /bin/mkdir (mkdir /var/lib/os-prober/mount ) by /bin/mkdir[50mounted-tests:7080] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7076] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:06 debinv38 kernel: [39042.793166] grsec: exec of /usr/bin/grub-mount (grub-mount /dev/sda3 /var/lib/os-prober/mount ) by /usr/bin/grub-mount[50mounted-tests:7081] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7076] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:06 debinv38 kernel: [39042.798901] PAX: execution attempt in: <stack>, 3d8e1b26000-3d8e1b47000 3fffffde000 Aug 23 13:53:06 debinv38 kernel: [39042.798916] PAX: terminating task: /usr/bin/grub-mount(grub-mount):7081, uid/euid: 0/0, PC: 000003d8e1b45cb0, SP: 000003d8e1b45c68 Aug 23 13:53:06 debinv38 kernel: [39042.798923] PAX: bytes at PC: 41 bb b0 11 43 00 49 ba a0 5c b4 e1 d8 03 00 00 49 ff e3 90 Aug 23 13:53:06 debinv38 kernel: [39042.799085] PAX: bytes at SP-8: 00000000004421ea 0000000000403d2e 000003d8e1b45cb0 0000000000431a1e 0000000000440b7e 0000000000000003 000003d8e1b45e28 0000000000431317 000003d8e1b45e28 00000000004055b0 ba49004311b0bb41 Aug 23 13:53:06 debinv38 kernel: [39042.799143] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/grub-mount[grub-mount:7081] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7076] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:06 debinv38 kernel: [39042.801765] grsec: exec of /sbin/blockdev (blockdev --getro /dev/sda3 ) by /sbin/blockdev[50mounted-tests:7082] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7076] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:06 debinv38 kernel: [39042.807411] grsec: exec of /sbin/blockdev (blockdev --setro /dev/sda3 ) by /sbin/blockdev[50mounted-tests:7083] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7076] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:06 debinv38 kernel: [39042.811704] grsec: exec of /bin/mount (mount -o ro -t LVM2_member /dev/sda3 /var/lib/os-prober/mount ) by /bin/mount[50mounted-tests:7084] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7076] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:06 debinv38 kernel: [39042.820568] grsec: exec of /bin/kmod (/sbin/modprobe -q -- fs-LVM2_member ) by /bin/kmod[kworker/u4:3:7086] uid/euid:0/0 gid/egid:0/0, parent /[kworker/u4:3:7085] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:06 debinv38 kernel: [39042.829846] grsec: exec of /bin/rmdir (rmdir /var/lib/os-prober/mount ) by /bin/rmdir[50mounted-tests:7087] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7076] uid/euid:0/0 gid/egid:0/0

2nd denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/grub-mount

Code: Select all: Aug 23 13:53:07 debinv38 kernel: [39043.578734] grsec: exec of /sbin/blkid (blkid -o value -s TYPE /dev/mapper/vg_C-build ) by /sbin/blkid[50mounted-tests:7345] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7343] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:07 debinv38 kernel: [39043.657844] grsec: exec of /bin/mkdir (mkdir /var/lib/os-prober/mount ) by /bin/mkdir[50mounted-tests:7346] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7342] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:07 debinv38 kernel: [39043.661554] grsec: exec of /usr/bin/grub-mount (grub-mount /dev/mapper/vg_C-build /var/lib/os-prober/mount ) by /usr/bin/grub-mount[50mounted-tests:7347] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7342] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:07 debinv38 kernel: [39043.665083] PAX: execution attempt in: <stack>, 387a24b9000-387a24db000 3fffffdd000 Aug 23 13:53:07 debinv38 kernel: [39043.665093] PAX: terminating task: /usr/bin/grub-mount(grub-mount):7347, uid/euid: 0/0, PC: 00000387a24d9ad0, SP: 00000387a24d9a88 Aug 23 13:53:07 debinv38 kernel: [39043.665096] PAX: bytes at PC: 41 bb b0 11 43 00 49 ba c0 9a 4d a2 87 03 00 00 49 ff e3 90 Aug 23 13:53:07 debinv38 kernel: [39043.665113] PAX: bytes at SP-8: 00000000004421ea 0000000000403d2e 00000387a24d9ad0 0000000000431a1e 0000000000440b7e 0000000000000003 00000387a24d9c48 0000000000431317 00000387a24d9c48 00000000004055b0 ba49004311b0bb41 Aug 23 13:53:07 debinv38 kernel: [39043.665148] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/grub-mount[grub-mount:7347] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7342] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:07 debinv38 kernel: [39043.666689] grsec: exec of /sbin/blockdev (blockdev --getro /dev/mapper/vg_C-build ) by /sbin/blockdev[50mounted-tests:7348] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7342] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:07 debinv38 kernel: [39043.669375] grsec: exec of /sbin/blockdev (blockdev --setro /dev/mapper/vg_C-build ) by /sbin/blockdev[50mounted-tests:7349] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7342] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:07 debinv38 kernel: [39043.673270] grsec: exec of /bin/mount (mount -o ro -t ext4 /dev/mapper/vg_C-build /var/lib/os-prober/mount ) by /bin/mount[50mounted-tests:7350] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7342] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:07 debinv38 kernel: [39043.703837] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: (null) Aug 23 13:53:07 debinv38 kernel: [39043.703870] grsec: mount of /dev/mapper/vg_C-build to /var/lib/os-prober/mount by /bin/mount[mount:7350] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7342] uid/euid:0/0 gid/egid:0/0

3rd denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/grub-mount

Code: Select all: Aug 23 13:53:07 debinv38 kernel: [39043.578734] grsec: exec of /sbin/blkid (blkid -o value -s TYPE /dev/mapper/vg_C-build ) by /sbin/blkid[50mounted-tests:7345] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7343] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:07 debinv38 kernel: [39043.657844] grsec: exec of /bin/mkdir (mkdir /var/lib/os-prober/mount ) by /bin/mkdir[50mounted-tests:7346] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7342] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:07 debinv38 kernel: [39043.661554] grsec: exec of /usr/bin/grub-mount (grub-mount /dev/mapper/vg_C-build /var/lib/os-prober/mount ) by /usr/bin/grub-mount[50mounted-tests:7347] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7342] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:07 debinv38 kernel: [39043.665083] PAX: execution attempt in: <stack>, 387a24b9000-387a24db000 3fffffdd000 Aug 23 13:53:07 debinv38 kernel: [39043.665093] PAX: terminating task: /usr/bin/grub-mount(grub-mount):7347, uid/euid: 0/0, PC: 00000387a24d9ad0, SP: 00000387a24d9a88 Aug 23 13:53:07 debinv38 kernel: [39043.665096] PAX: bytes at PC: 41 bb b0 11 43 00 49 ba c0 9a 4d a2 87 03 00 00 49 ff e3 90 Aug 23 13:53:07 debinv38 kernel: [39043.665113] PAX: bytes at SP-8: 00000000004421ea 0000000000403d2e 00000387a24d9ad0 0000000000431a1e 0000000000440b7e 0000000000000003 00000387a24d9c48 0000000000431317 00000387a24d9c48 00000000004055b0 ba49004311b0bb41 Aug 23 13:53:07 debinv38 kernel: [39043.665148] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/grub-mount[grub-mount:7347] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7342] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:07 debinv38 kernel: [39043.666689] grsec: exec of /sbin/blockdev (blockdev --getro /dev/mapper/vg_C-build ) by /sbin/blockdev[50mounted-tests:7348] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7342] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:07 debinv38 kernel: [39043.669375] grsec: exec of /sbin/blockdev (blockdev --setro /dev/mapper/vg_C-build ) by /sbin/blockdev[50mounted-tests:7349] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7342] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:07 debinv38 kernel: [39043.673270] grsec: exec of /bin/mount (mount -o ro -t ext4 /dev/mapper/vg_C-build /var/lib/os-prober/mount ) by /bin/mount[50mounted-tests:7350] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7342] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:07 debinv38 kernel: [39043.703837] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: (null) Aug 23 13:53:07 debinv38 kernel: [39043.703870] grsec: mount of /dev/mapper/vg_C-build to /var/lib/os-prober/mount by /bin/mount[mount:7350] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7342] uid/euid:0/0 gid/egid:0/0

4th denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/grub-mount

Code: Select all: Aug 23 13:53:07 debinv38 kernel: [39043.578734] grsec: exec of /sbin/blkid (blkid -o value -s TYPE /dev/mapper/vg_C-build ) by /sbin/blkid[50mounted-tests:7345] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7343] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:07 debinv38 kernel: [39043.657844] grsec: exec of /bin/mkdir (mkdir /var/lib/os-prober/mount ) by /bin/mkdir[50mounted-tests:7346] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7342] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:07 debinv38 kernel: [39043.661554] grsec: exec of /usr/bin/grub-mount (grub-mount /dev/mapper/vg_C-build /var/lib/os-prober/mount ) by /usr/bin/grub-mount[50mounted-tests:7347] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7342] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:07 debinv38 kernel: [39043.665083] PAX: execution attempt in: <stack>, 387a24b9000-387a24db000 3fffffdd000 Aug 23 13:53:07 debinv38 kernel: [39043.665093] PAX: terminating task: /usr/bin/grub-mount(grub-mount):7347, uid/euid: 0/0, PC: 00000387a24d9ad0, SP: 00000387a24d9a88 Aug 23 13:53:07 debinv38 kernel: [39043.665096] PAX: bytes at PC: 41 bb b0 11 43 00 49 ba c0 9a 4d a2 87 03 00 00 49 ff e3 90 Aug 23 13:53:07 debinv38 kernel: [39043.665113] PAX: bytes at SP-8: 00000000004421ea 0000000000403d2e 00000387a24d9ad0 0000000000431a1e 0000000000440b7e 0000000000000003 00000387a24d9c48 0000000000431317 00000387a24d9c48 00000000004055b0 ba49004311b0bb41 Aug 23 13:53:07 debinv38 kernel: [39043.665148] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/grub-mount[grub-mount:7347] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7342] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:07 debinv38 kernel: [39043.666689] grsec: exec of /sbin/blockdev (blockdev --getro /dev/mapper/vg_C-build ) by /sbin/blockdev[50mounted-tests:7348] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7342] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:07 debinv38 kernel: [39043.669375] grsec: exec of /sbin/blockdev (blockdev --setro /dev/mapper/vg_C-build ) by /sbin/blockdev[50mounted-tests:7349] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7342] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:07 debinv38 kernel: [39043.673270] grsec: exec of /bin/mount (mount -o ro -t ext4 /dev/mapper/vg_C-build /var/lib/os-prober/mount ) by /bin/mount[50mounted-tests:7350] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7342] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:07 debinv38 kernel: [39043.703837] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: (null) Aug 23 13:53:07 debinv38 kernel: [39043.703870] grsec: mount of /dev/mapper/vg_C-build to /var/lib/os-prober/mount by /bin/mount[mount:7350] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/50mounted-tests[50mounted-tests:7342] uid/euid:0/0 gid/egid:0/0

5th denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/grub-script-check

Code: Select all: Aug 23 13:53:08 debinv38 kernel: [39044.554009] grsec: exec of /bin/ls (ls /var/lib*/ld*.so* ) by /bin/ls[90linux-distro:7585] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/mounted/90linux-distro[90linux-distro:7584] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:08 debinv38 kernel: [39044.557231] grsec: exec of /bin/ls (ls /var/usr/lib*/ld*.so* ) by /bin/ls[90linux-distro:7584] uid/euid:0/0 gid/egid:0/0, parent /usr/lib/os-probes/mounted/90linux-distro[90linux-distro:7583] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:08 debinv38 kernel: [39044.560800] grsec: exec of /usr/bin/logger (logger -t os-prober debug: running /usr/lib/os-probes/mounted/90solaris on mounted /dev/mapper/vg_r-var ) by /usr/bin/logger[os-prober:7586] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/os-prober[os-prober:6897] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:08 debinv38 kernel: [39044.562842] grsec: exec of /usr/lib/os-probes/mounted/90solaris (/usr/lib/os-probes/mounted/90solaris /dev/mapper/vg_r-var /var ext4 ) by /usr/lib/os-probes/mounted/90solaris[os-prober:7587] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/os-prober[os-prober:6897] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:08 debinv38 kernel: [39044.565934] grsec: exec of /bin/rm (rm -rf /tmp/os-prober.7wujid ) by /bin/rm[os-prober:7588] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/os-prober[os-prober:6897] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:08 debinv38 kernel: [39044.585537] grsec: exec of /etc/grub.d/40_custom (/etc/grub.d/40_custom ) by /etc/grub.d/40_custom[grub-mkconfig:7589] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/grub-mkconfig[grub-mkconfig:6400] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:08 debinv38 kernel: [39044.586776] grsec: exec of /usr/bin/tail (tail -n +3 /etc/grub.d/40_custom ) by /usr/bin/tail[40_custom:7589] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/grub-mkconfig[grub-mkconfig:6400] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:08 debinv38 kernel: [39044.589839] grsec: exec of /etc/grub.d/41_custom (/etc/grub.d/41_custom ) by /etc/grub.d/41_custom[grub-mkconfig:7590] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/grub-mkconfig[grub-mkconfig:6400] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:08 debinv38 kernel: [39044.591402] grsec: exec of /bin/cat (cat ) by /bin/cat[41_custom:7591] uid/euid:0/0 gid/egid:0/0, parent /etc/grub.d/41_custom[41_custom:7590] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:08 debinv38 kernel: [39044.593965] grsec: exec of /bin/grep (grep ^password /boot/grub/grub.cfg.new ) by /bin/grep[grub-mkconfig:7592] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/grub-mkconfig[grub-mkconfig:6400] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:08 debinv38 kernel: [39044.595985] grsec: exec of /bin/chmod (chmod 444 /boot/grub/grub.cfg.new ) by /bin/chmod[grub-mkconfig:7593] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/grub-mkconfig[grub-mkconfig:6400] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:08 debinv38 kernel: [39044.608446] grsec: exec of /usr/bin/grub-script-check (/usr/bin/grub-script-check /boot/grub/grub.cfg.new ) by /usr/bin/grub-script-check[grub-mkconfig:7594] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/grub-mkconfig[grub-mkconfig:6400] uid/euid:0/0 gid/egid:0/0 Aug 23 13:53:08 debinv38 kernel: [39044.612720] PAX: execution attempt in: <stack>, 3a6ba820000-3a6ba841000 3fffffde000 Aug 23 13:53:08 debinv38 kernel: [39044.612728] PAX: terminating task: /usr/bin/grub-script-check(grub-script-che):7594, uid/euid: 0/0, PC: 000003a6ba83fd30, SP: 000003a6ba83e6d8 Aug 23 13:53:08 debinv38 kernel: [39044.612731] PAX: bytes at PC: 41 bb 30 27 40 00 49 ba 20 fd 83 ba a6 03 00 00 49 ff e3 90 Aug 23 13:53:08 debinv38 kernel: [39044.612743] PAX: bytes at SP-8: 0000000000000011 0000000000404011 0000000001c93510 0000000000000000 0000000001c93490 0000000001c93510 0000000001c93511 0000000001c95551 0000000001c95550 0000000000405ca6 0000000000000002 Aug 23 13:53:08 debinv38 kernel: [39044.612773] grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/grub-script-check[grub-script-che:7594] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/grub-mkconfig[grub-mkconfig:6400] uid/euid:0/0 gid/egid:0/0 Aug 23 13:55:26 debinv38 kernel: [39182.666884] grsec: exec of /bin/date (date ) by /bin/date[bash:7595] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3313] uid/euid:0/0 gid/egid:0/0 Aug 23 13:55:41 debinv38 kernel: [39197.279971] grsec: exec of /bin/cat (cat ) by /bin/cat[bash:7596] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:3343] uid/euid:1000/1000 gid/egid:1000/1000 Aug 23 13:55:48 debinv38 kernel: [39204.769099] grsec: exec of /bin/ls (ls --color=auto -ltr ) by /bin/ls[bash:7597] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:3406] uid/euid:1000/1000 gid/egid:1000/1000

Yeah, 5 instances. And I don't understand what to do, how to fix these errors, yet.
However, what I do understand, is that I was able to simply:

Code: Select all: # mv /boot/grub/grub.cfg.new /boot/grub/grub.cfg

and I'll bet that'll work on this other box as in the previous (booted fine), because I want to have the SANITIZE feature on before I go online.
This here box of the other try, so I can explain things possibly also for other users like me, is still on:

Code: Select all: # uname -r 3.10.9-grsec-130821 #

without the SANITIZE feature.
[[ A note after I, Miroslav Rovis wrote all this and the next post:
I am dividing these, for easier reading, in two posts but they were written in a consecutive effort through time, up until some 5 hours ago when I was overwhelmed by sleep. Only sleeping and poring over these issues here, and hardly anything much else for any longer time now... And I hope there are not any much more serious hurdles to me finally posting this. Read on! ]]

Posted: **Fri Aug 23, 2013 9:21 pm**

So I might be back to solve this issue, for those two executables in question. But later.
Because now I only need my kernel fixed probably just enough for the challenge of another short time on the internet.
Because we, and here's the news that I promised at the beginning of this post [[ note: before I divided this originally one post to-be in two posts now ]]
I mean we, because we, the tollerant ri... [[ self censorship, pls. read my previous posts, hope DuckDuckGo.com won't hide it from you, if you search by some of the words here ]] don't torture people.
It would be torturing my readers with impatience, and we don't do that.

Because the same bug has appeared on the other Debian box of mine, not this one that I am writing these and getting ready for trying if the syntax of /boot/grub/grub.cnf is borked, which it isn't, by rebooting into the new today's kernel with the SANITIZE feature, else I'm afraid the program that may be using this after-free bug may spread onto other computers in my SOHO...

This other Debian box, and that is the point...
This other Debian box that the same bug (do you think that I couldn't recognize it, after Spender's explanation and after me having typed by hand all the mumbo-jumbo of the Oops?)...
But I could probably end up having to post this bug in similar fashion [[ note upon last proofreading: possibly not, the situation has worsened very much, the systems are too compromised, so once I probably send you the pictures, Spender and Pax Team, please kindly post the pictures of this after-free bug in my Debian box for the viewers to understand the whole story ]], since posting on some sites that actually want to charge you never mind the minusculeness of the 800k of the image, else it is gone as soon as they see you are not a commercial dodo... is not my way of doing things...

Spender and Pax Team, do you want this picture too?

I hope I am not moderated, and if I really am not, I will start transcribing again [[ note on last proofreading; no I hardly could do that, and if I don't do that, believe me it completely fits the description: just this time what was done through it, and that I might make and effort to transcribe, if Spender and Pax Team don't let you have the picture, is the part of the Call Trace that is not about, like the last time, nfsd_THIS_AND_THAT, like the last time, but about ext4_exit_fs, generic_shutdown_super, kill_block_super, SyS_umount, system_call_fastpath and syret_check, the Call Trace line before the Code ]]... [[ I was saying here that I would be transcribing again ]] similar to the other, the Gentoo side of the story, which is in separate topic... can't see the name, am not online yet...

I hope I am not moderated, and if I am, and even without mentioning neither the Good Subject of the Universe, nor the Big Intruder/Surveillor Subject of the World, overtly by their names, nor indulging so much into non-techie stuff... Well not more than other people who write on programs and stuff do...

If I am, it's a serious handicap, because it is hard on me.

And that is not the sole news, but the other is probably less interesting.
There was another crash but, Brad and Pax Team, you already have the kernel of that crash, because it occurred on the Gentoo box with that kernel that I sent you already.

I have the picture of that crash, the same mobile phone camera picture, and it's still probably some more info in the matter, but I don't know.

I have to, and I believe I should be allowed to, with quite some insistence, but without putting it up to anybody as any requirement, no, I am still happy to be useful in the GNU/Linux world for the sake of it...

But I have to kindly ask the really competent big boys who are reading this, because this is curious, IMO, and is and will be read (and why keep it to yourself, you whoever who reads this?, if you love the world, show this to others!), please somebody tell me more, not necessarily in the matters that are strictly Grsecurity/Pax, but if necessary in wider terms. Please tell me this:

What, where, in which fashion, how to find it and all the rest...

These boxes that crashed were the sole that I connected to the internet, having felt the danger...
And only they crashed!
Even after having restored, the other Debian box, the one that already crashed, this one certainly has the same issues...
Even after having restored it from what I thought was a backup giving me clean Debian install, because I took great care to install offline from my local Apache into clean boxes, restored from backup of the images of a box in clean state, after having downloaded packages, and tried to really shun continuing to use the boxes that were exposed online to any significant measure...

Tell me what to check for, where to look for problems, in which fashion these things work, how to find what uses this bug and all the rest... as much as you can... Links to tutorials any?

I am quite certain good-intentioned people know what I am asking for here.

I have also noticed strange delays, and reports of strange nfsd (I think) delays in some of my Debian boxes, and wonder if the special kind of virus (clamav has only found some stupid Windoze Trojans and things in old mail in my boxes so far)..
I have also noticed strange delays, and reports of strange nfsd delays in my Debian systems, but am again overwrought and can't find them pronto...

And I also have a previous Call Trace of the same bug in the Debian box that crashed.
And I'll end up this post with this last item (if those nfsd or network, can't remember the words of the lines in the kern.log or messages don't turn into free-after-bug grsec halted kernel because of sucpicious kernel crash)...

Same doubt as earlier I have now, how much to post. Because it's three, now I see, Call Traces...

Code: Select all: Aug 21 14:39:52 debinv35 kernel: [ 8862.953841] grsec: exec of /sbin/dhclient-script (/sbin/dhclient-script ) by /sbin/dhclient-script[dhclient:3718] uid/euid:0/0 gid/egid:0/0, parent /sbin/dhclient[dhclient:3312] uid/euid:0/0 gid/egid:0/0 Aug 21 14:39:52 debinv35 kernel: [ 8862.962495] grsec: exec of /bin/run-parts (run-parts --list /etc/dhcp/dhclient-enter-hooks.d ) by /bin/run-parts[dhclient-script:3719] uid/euid:0/0 gid/egid:0/0, parent /sbin/dhclient-script[dhclient-script:3718] uid/euid:0/0 gid/egid:0/0 Aug 21 14:39:52 debinv35 kernel: [ 8862.969625] grsec: exec of /bin/mv (mv /etc/samba/dhcp.conf.new /etc/samba/dhcp.conf ) by /bin/mv[dhclient-script:3720] uid/euid:0/0 gid/egid:0/0, parent /sbin/dhclient-script[dhclient-script:3718] uid/euid:0/0 gid/egid:0/0 Aug 21 14:39:52 debinv35 kernel: [ 8862.978060] grsec: exec of /bin/run-parts (run-parts --list /etc/dhcp/dhclient-exit-hooks.d ) by /bin/run-parts[dhclient-script:3721] uid/euid:0/0 gid/egid:0/0, parent /sbin/dhclient-script[dhclient-script:3718] uid/euid:0/0 gid/egid:0/0 Aug 21 14:40:11 debinv35 kernel: [ 8882.032092] INFO: task mount.nfs:3717 blocked for more than 120 seconds. Aug 21 14:40:11 debinv35 kernel: [ 8882.032101] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Aug 21 14:40:11 debinv35 kernel: [ 8882.032106] mount.nfs D ffff88013fc0fb00 0 3717 3716 0x00000000 Aug 21 14:40:11 debinv35 kernel: [ 8882.032115] ffff8801071e57f0 0000000000000082 ffffffff816ef8f0 0000000000000246 Aug 21 14:40:11 debinv35 kernel: [ 8882.032123] 000000000000fb00 ffff8801071e5c70 ffff8801071e5c70 ffff8801071e57f0 Aug 21 14:40:11 debinv35 kernel: [ 8882.032129] ffff88011c0e8670 ffff8801071e57f0 ffff88011c0e8674 0000000000000002 Aug 21 14:40:11 debinv35 kernel: [ 8882.032136] Call Trace: Aug 21 14:40:11 debinv35 kernel: [ 8882.032150] [<ffffffff813578e1>] ? schedule_preempt_disabled+0x5/0x6 Aug 21 14:40:11 debinv35 kernel: [ 8882.032159] [<ffffffff813569bb>] ? __mutex_lock_common.isra.8+0x19c/0x1b8 Aug 21 14:40:11 debinv35 kernel: [ 8882.032166] [<ffffffff813567ec>] ? mutex_lock+0x17/0x27 Aug 21 14:40:11 debinv35 kernel: [ 8882.032175] [<ffffffff81102136>] ? walk_component+0x5f/0x1a2 Aug 21 14:40:11 debinv35 kernel: [ 8882.032183] [<ffffffff811026bd>] ? link_path_walk+0x1dc/0x471 Aug 21 14:40:11 debinv35 kernel: [ 8882.032191] [<ffffffff81102cd6>] ? path_lookupat+0x53/0x2ee Aug 21 14:40:11 debinv35 kernel: [ 8882.032199] [<ffffffff81102f90>] ? filename_lookup+0x1f/0xa9 Aug 21 14:40:11 debinv35 kernel: [ 8882.032207] [<ffffffff81103094>] ? do_path_lookup+0x28/0x2d Aug 21 14:40:11 debinv35 kernel: [ 8882.032214] [<ffffffff81103242>] ? vfs_path_lookup+0x39/0x5a Aug 21 14:40:11 debinv35 kernel: [ 8882.032224] [<ffffffff81147722>] ? proc_alloc_inum+0x39/0x96 Aug 21 14:40:11 debinv35 kernel: [ 8882.032232] [<ffffffff8110face>] ? alloc_mnt_ns.isra.18+0x8d/0xab Aug 21 14:40:11 debinv35 kernel: [ 8882.032239] [<ffffffff81110654>] ? create_mnt_ns+0xa/0x52 Aug 21 14:40:11 debinv35 kernel: [ 8882.032246] [<ffffffff8111252d>] ? mount_subtree+0x35/0x7f Aug 21 14:40:11 debinv35 kernel: [ 8882.032275] [<ffffffffa054c507>] ? nfs_follow_remote_path+0xd0/0x123 [nfsv4] Aug 21 14:40:11 debinv35 kernel: [ 8882.032298] [<ffffffffa04c7f55>] ? nfs_fs_mount+0x621/0x695 [nfs] Aug 21 14:40:11 debinv35 kernel: [ 8882.032315] [<ffffffffa04c8362>] ? nfs_clone_super+0x60/0x60 [nfs] Aug 21 14:40:11 debinv35 kernel: [ 8882.032331] [<ffffffffa04c5b67>] ? nfs_block_bits+0x4f/0x4f [nfs] Aug 21 14:40:11 debinv35 kernel: [ 8882.032339] [<ffffffff810fbf89>] ? mount_fs+0xc/0xa3 Aug 21 14:40:11 debinv35 kernel: [ 8882.032347] [<ffffffff8110fd7b>] ? vfs_kern_mount+0x60/0xe1 Aug 21 14:40:11 debinv35 kernel: [ 8882.032355] [<ffffffff81111e73>] ? do_mount+0x675/0x7fd Aug 21 14:40:11 debinv35 kernel: [ 8882.032362] [<ffffffff81111749>] ? copy_mount_options+0xd3/0x15d Aug 21 14:40:11 debinv35 kernel: [ 8882.032370] [<ffffffff81112079>] ? SyS_mount+0x7e/0xb7 Aug 21 14:40:11 debinv35 kernel: [ 8882.032377] [<ffffffff8135d009>] ? system_call_fastpath+0x18/0x1d Aug 21 14:40:11 debinv35 kernel: [ 8882.032384] [<ffffffff8135d239>] ? int_with_check+0x1c/0x24 Aug 21 14:42:11 debinv35 kernel: [ 9002.032104] INFO: task mount.nfs:3717 blocked for more than 120 seconds. Aug 21 14:42:11 debinv35 kernel: [ 9002.032114] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Aug 21 14:42:11 debinv35 kernel: [ 9002.032119] mount.nfs D ffff88013fc0fb00 0 3717 3716 0x00000000 Aug 21 14:42:11 debinv35 kernel: [ 9002.032128] ffff8801071e57f0 0000000000000082 ffffffff816ef8f0 0000000000000246 Aug 21 14:42:11 debinv35 kernel: [ 9002.032136] 000000000000fb00 ffff8801071e5c70 ffff8801071e5c70 ffff8801071e57f0 Aug 21 14:42:11 debinv35 kernel: [ 9002.032142] ffff88011c0e8670 ffff8801071e57f0 ffff88011c0e8674 0000000000000002 Aug 21 14:42:11 debinv35 kernel: [ 9002.032149] Call Trace: Aug 21 14:42:11 debinv35 kernel: [ 9002.032164] [<ffffffff813578e1>] ? schedule_preempt_disabled+0x5/0x6 Aug 21 14:42:11 debinv35 kernel: [ 9002.032172] [<ffffffff813569bb>] ? __mutex_lock_common.isra.8+0x19c/0x1b8 Aug 21 14:42:11 debinv35 kernel: [ 9002.032180] [<ffffffff813567ec>] ? mutex_lock+0x17/0x27 Aug 21 14:42:11 debinv35 kernel: [ 9002.032188] [<ffffffff81102136>] ? walk_component+0x5f/0x1a2 Aug 21 14:42:11 debinv35 kernel: [ 9002.032196] [<ffffffff811026bd>] ? link_path_walk+0x1dc/0x471 Aug 21 14:42:11 debinv35 kernel: [ 9002.032205] [<ffffffff81102cd6>] ? path_lookupat+0x53/0x2ee Aug 21 14:42:11 debinv35 kernel: [ 9002.032213] [<ffffffff81102f90>] ? filename_lookup+0x1f/0xa9 Aug 21 14:42:11 debinv35 kernel: [ 9002.032220] [<ffffffff81103094>] ? do_path_lookup+0x28/0x2d Aug 21 14:42:11 debinv35 kernel: [ 9002.032228] [<ffffffff81103242>] ? vfs_path_lookup+0x39/0x5a Aug 21 14:42:11 debinv35 kernel: [ 9002.032237] [<ffffffff81147722>] ? proc_alloc_inum+0x39/0x96 Aug 21 14:42:11 debinv35 kernel: [ 9002.032245] [<ffffffff8110face>] ? alloc_mnt_ns.isra.18+0x8d/0xab Aug 21 14:42:11 debinv35 kernel: [ 9002.032252] [<ffffffff81110654>] ? create_mnt_ns+0xa/0x52 Aug 21 14:42:11 debinv35 kernel: [ 9002.032260] [<ffffffff8111252d>] ? mount_subtree+0x35/0x7f Aug 21 14:42:11 debinv35 kernel: [ 9002.032289] [<ffffffffa054c507>] ? nfs_follow_remote_path+0xd0/0x123 [nfsv4] Aug 21 14:42:11 debinv35 kernel: [ 9002.032312] [<ffffffffa04c7f55>] ? nfs_fs_mount+0x621/0x695 [nfs] Aug 21 14:42:11 debinv35 kernel: [ 9002.032329] [<ffffffffa04c8362>] ? nfs_clone_super+0x60/0x60 [nfs] Aug 21 14:42:11 debinv35 kernel: [ 9002.032345] [<ffffffffa04c5b67>] ? nfs_block_bits+0x4f/0x4f [nfs] Aug 21 14:42:11 debinv35 kernel: [ 9002.032353] [<ffffffff810fbf89>] ? mount_fs+0xc/0xa3 Aug 21 14:42:11 debinv35 kernel: [ 9002.032360] [<ffffffff8110fd7b>] ? vfs_kern_mount+0x60/0xe1 Aug 21 14:42:11 debinv35 kernel: [ 9002.032368] [<ffffffff81111e73>] ? do_mount+0x675/0x7fd Aug 21 14:42:11 debinv35 kernel: [ 9002.032376] [<ffffffff81111749>] ? copy_mount_options+0xd3/0x15d Aug 21 14:42:11 debinv35 kernel: [ 9002.032383] [<ffffffff81112079>] ? SyS_mount+0x7e/0xb7 Aug 21 14:42:11 debinv35 kernel: [ 9002.032390] [<ffffffff8135d009>] ? system_call_fastpath+0x18/0x1d Aug 21 14:42:11 debinv35 kernel: [ 9002.032397] [<ffffffff8135d239>] ? int_with_check+0x1c/0x24 Aug 21 14:44:11 debinv35 kernel: [ 9122.032094] INFO: task mount.nfs:3717 blocked for more than 120 seconds. Aug 21 14:44:11 debinv35 kernel: [ 9122.032103] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Aug 21 14:44:11 debinv35 kernel: [ 9122.032108] mount.nfs D ffff88013fc0fb00 0 3717 3716 0x00000000 Aug 21 14:44:11 debinv35 kernel: [ 9122.032117] ffff8801071e57f0 0000000000000082 ffffffff816ef8f0 0000000000000246 Aug 21 14:44:11 debinv35 kernel: [ 9122.032125] 000000000000fb00 ffff8801071e5c70 ffff8801071e5c70 ffff8801071e57f0 Aug 21 14:44:11 debinv35 kernel: [ 9122.032131] ffff88011c0e8670 ffff8801071e57f0 ffff88011c0e8674 0000000000000002 Aug 21 14:44:11 debinv35 kernel: [ 9122.032138] Call Trace: Aug 21 14:44:11 debinv35 kernel: [ 9122.032152] [<ffffffff813578e1>] ? schedule_preempt_disabled+0x5/0x6 Aug 21 14:44:11 debinv35 kernel: [ 9122.032161] [<ffffffff813569bb>] ? __mutex_lock_common.isra.8+0x19c/0x1b8 Aug 21 14:44:11 debinv35 kernel: [ 9122.032168] [<ffffffff813567ec>] ? mutex_lock+0x17/0x27 Aug 21 14:44:11 debinv35 kernel: [ 9122.032177] [<ffffffff81102136>] ? walk_component+0x5f/0x1a2 Aug 21 14:44:11 debinv35 kernel: [ 9122.032185] [<ffffffff811026bd>] ? link_path_walk+0x1dc/0x471 Aug 21 14:44:11 debinv35 kernel: [ 9122.032193] [<ffffffff81102cd6>] ? path_lookupat+0x53/0x2ee Aug 21 14:44:11 debinv35 kernel: [ 9122.032201] [<ffffffff81102f90>] ? filename_lookup+0x1f/0xa9 Aug 21 14:44:11 debinv35 kernel: [ 9122.032209] [<ffffffff81103094>] ? do_path_lookup+0x28/0x2d Aug 21 14:44:11 debinv35 kernel: [ 9122.032217] [<ffffffff81103242>] ? vfs_path_lookup+0x39/0x5a Aug 21 14:44:11 debinv35 kernel: [ 9122.032226] [<ffffffff81147722>] ? proc_alloc_inum+0x39/0x96 Aug 21 14:44:11 debinv35 kernel: [ 9122.032234] [<ffffffff8110face>] ? alloc_mnt_ns.isra.18+0x8d/0xab Aug 21 14:44:11 debinv35 kernel: [ 9122.032241] [<ffffffff81110654>] ? create_mnt_ns+0xa/0x52 Aug 21 14:44:11 debinv35 kernel: [ 9122.032248] [<ffffffff8111252d>] ? mount_subtree+0x35/0x7f Aug 21 14:44:11 debinv35 kernel: [ 9122.032277] [<ffffffffa054c507>] ? nfs_follow_remote_path+0xd0/0x123 [nfsv4] Aug 21 14:44:11 debinv35 kernel: [ 9122.032300] [<ffffffffa04c7f55>] ? nfs_fs_mount+0x621/0x695 [nfs] Aug 21 14:44:11 debinv35 kernel: [ 9122.032318] [<ffffffffa04c8362>] ? nfs_clone_super+0x60/0x60 [nfs] Aug 21 14:44:11 debinv35 kernel: [ 9122.032333] [<ffffffffa04c5b67>] ? nfs_block_bits+0x4f/0x4f [nfs] Aug 21 14:44:11 debinv35 kernel: [ 9122.032341] [<ffffffff810fbf89>] ? mount_fs+0xc/0xa3 Aug 21 14:44:11 debinv35 kernel: [ 9122.032349] [<ffffffff8110fd7b>] ? vfs_kern_mount+0x60/0xe1 Aug 21 14:44:11 debinv35 kernel: [ 9122.032357] [<ffffffff81111e73>] ? do_mount+0x675/0x7fd Aug 21 14:44:11 debinv35 kernel: [ 9122.032364] [<ffffffff81111749>] ? copy_mount_options+0xd3/0x15d Aug 21 14:44:11 debinv35 kernel: [ 9122.032372] [<ffffffff81112079>] ? SyS_mount+0x7e/0xb7 Aug 21 14:44:11 debinv35 kernel: [ 9122.032379] [<ffffffff8135d009>] ? system_call_fastpath+0x18/0x1d Aug 21 14:44:11 debinv35 kernel: [ 9122.032386] [<ffffffff8135d239>] ? int_with_check+0x1c/0x24 Aug 21 14:47:21 debinv35 kernel: [ 9312.146803] grsec: exec of /sbin/dhclient-script (/sbin/dhclient-script ) by /sbin/dhclient-script[dhclient:3724] uid/euid:0/0 gid/egid:0/0, parent /sbin/dhclient[dhclient:3312] uid/euid:0/0 gid/egid:0/0 Aug 21 14:47:21 debinv35 kernel: [ 9312.155202] grsec: exec of /bin/run-parts (run-parts --list /etc/dhcp/dhclient-enter-hooks.d ) by /bin/run-parts[dhclient-script:3725] uid/euid:0/0 gid/egid:0/0, parent /sbin/dhclient-script[dhclient-script:3724] uid/euid:0/0 gid/egid:0/0 Aug 21 14:47:21 debinv35 kernel: [ 9312.162505] grsec: exec of /bin/mv (mv /etc/samba/dhcp.conf.new /etc/samba/dhcp.conf ) by /bin/mv[dhclient-script:3726] uid/euid:0/0 gid/egid:0/0, parent /sbin/dhclient-script[dhclient-script:3724] uid/euid:0/0 gid/egid:0/0 Aug 21 14:47:21 debinv35 kernel: [ 9312.171373] grsec: exec of /bin/run-parts (run-parts --list /etc/dhcp/dhclient-exit-hooks.d ) by /bin/run-parts[dhclient-script:3727] uid/euid:0/0 gid/egid:0/0, parent /sbin/dhclient-script[dhclient-script:3724] uid/euid:0/0 gid/egid:0/0 Aug 21 14:55:30 debinv35 kernel: [ 9801.459545] grsec: exec of /sbin/dhclient-script (/sbin/dhclient-script ) by /sbin/dhclient-script[dhclient:3730] uid/euid:0/0 gid/egid:0/0, parent /sbin/dhclient[dhclient:3312] uid/euid:0/0 gid/egid:0/0

May the Joy and Peace of Mind of the Universe call you all to free and honest computing, and not deceit and disguise in your shady deals on the honest and poor, for gain that leaves your inner self empty and discontent!

Miroslav Rovis,
Zagreb, Croatia

It really depends on whether now I am moderated again (which will hit me like a slap in the face, that's how I would feel it), or not, which will make me joyful, it depends on that how quickly I can provide what I offered, if it is pleasing Spender and Pax Team to have it.

Oh, more development in the story.
This Debian box, I'll give out now full names, this: debinv38, the other is debinv35, has something like a full-blown keylogger or some program to that effect.
Why do i think so?
Because it won't except my own password, which is not at all anymore new to me, and it's not my typoes of any kind (I'm a touch typist, and you others who touch type know that only knew passwords or illness or some serious reason make you mistype passwords typed hundreds of times more than two or three times, don't you?).
And what I had is my LXDE login prompt winding me on with a good password typed in for no reason.
You know, like, say, when you ten years ago, such as I did, tried to install your old Windoze NT or XP onto a new hard disk, because you just bought a bigger HDD, and typed all correctly, but the XP or sumesuch started to log you in, but within seconds logged you out and showed the login prompt to you again, and you could repeat it as many times as you wanted, you couldn't log in.
My systems are compromised. I don't have anymore doubts about it.
Monkeys don't write bibles. Pls. find somewhere among my posts on Gentoo forums what I mean, I sure can not spend time online much longer to find the link.

What I possibly missed to clearly say, is, by the behaviour of the invisible intruder program it seems to me that they got a lot of info on my boxes, but not all, and I thank the entire GNU/Linux community for most of my data being safe still.
In past years I did notice mysterious disappearance of data, but in comparison to the volume of my, say, video collection (pls. look up my Youtube channel, it's pretty many videos, and only for reasons of censorship (I got even cut off from the internet completely in a few occasions), and for reasons of oftentimes trickling connection I am on in comparison to the connection I pay for), and many other regimatic hurdles, are there not twice or three times more there.
I'm saying, only relatively small losses so far of my data have I suffered.

The intruders (hi, there!) having figured out my tactics, they figured out it's the local network they need to break into.

And that's how the sole of the Gentoo systems that I used to connect online and which was, for that reason, the easiest one to infect with these virus-like kind of programs...

And I believe that this sole of my Gentoo system that I went online with was broken into not only via it's own connection to the internet, which was somewhere in avarage once a month and not for much else but only downloading Gentoo packages for updates (the eix... layman... emerge ...)... but even more via the local connection from the Debian box when the latter, often daily, or a few times a week, I connected to the internet for browsing and other.

Now I remember what I wanted not to forget to say.

I use macchanger, but it is only of relative help, because the router "broadband" modem which is my connection to the internet, couldn't wait to advertize it's MAC address, and I don't know how I could get to it, because it is under GNU licence, but that is too much for me to study and do (a very serious amount of time of dedicated studying)...

But this is what I wanted to say:
The program that used that after-free bug, and which is less visible to me than ghosts, you just feel, you don't see nor touch them...
That program has changed the MAC address of one of the network cards (there are two, one for the local-, the other for the inter-net).
Yes it did... I can emphasize to you enough how it really really did.

Unless, that is, there have some invisible monkeys come into my computer from outer space... Sure I'm joking now...

So, this is what I post now, and then, since to me it is now 99.99% clear that this is intrusion into my systems (intrusions of this kind are done in near perfectly invisible way, aren't they? Best sold-out minds of computing profusely paid, ain't it?)...

So, this is what I post now, and then, Spender and Pax Team, pls. don't hesitate to tell me if you need that picture and that kernel (sure I am ready to send it to you pronto, no questions asked, because I really might soon be blocked...
If I continue to use these compromised systems of mine, I could possibly lose control of them...
Remember (you who read my previous posts), how I already explained that the server, Apache server on one of the Gentoo boxes, where I served my Debian packages from for local installs, is compromised, and wouldn't serve anymore (cloning that I use allowed me to recover that function in my SOHO)...

So, this is what I post now, and then, Spender and Pax Team, pls. the sooner the better tell me if you want those, because I need to come up with some solution, and I can not stay online...

again I sign,
Miroslav Rovis
Vankina 4
10020 Zagreb,
Croatia
01 6602 633 (but tricks are played by the regime on my phones, censored, for short)
091 2660 202 ( -- ditto -- )
m.rovis@inet.hr not using, too much hacking straight away
m51r@yahoo.com also censored
miro.rovis@gmail.com this the worst, the ugliest, for me
www.CroatiaFidelis.hr no English there yet, careful about trusting Google translate pls.

Sorry for the many typoes, I can not log into this debinv35 box, and my eyes hurt (allergic of tumbleweed pollen, plant imported to Europe from the Americas centuries ago)... I can't use the network from this box because it is too compromised... can't use any network...
Ah, becuase their programs have obviously been layered into my box gradually since I installed Debian.

Now, but this is really final.
I sent a letter to Spender and to Pax Team, and I was stupid enough to encrypt it with my GnuPG key for Spender's key... Sorry!...
But I am saying that now because Spender got nerveous for it, and I understand it now, and I sincerely apologize.
In that letter I explained how from Debian weekly builds page, the jigdo files of Debian GNU/Linux Amd64 Testing Weekly Builds... how that page for the download of the jigdo files for me, contained only old builds for the entire last week from now...

How I was effectively blacklisted from accessing that exact page so I wouldn't get the jigdo files, at that sigle point of deliberate failure of download (actually of downloaded old not new) which then meant I couldn't go to any mirrors to download the entire Debian new packages collection...
Unless only Debian AMD64 and the sources (also could only download old jigdos) were not worked on for that week which for me seems highly unlikely.

I would like to make that letter in its entirety available in some of the next posts, because it is clear to me that some stupid people could otherwise end up blaming you or Pax Team for my ranting...
The sole topic of that letter was trying to explain how I was probably blacklisted from downloading Debian Testing Weekly Builds for my system. There is nothing else there. That is why I want to post it.

Like I started saying... The Debian boxes need complete reinstall, which is looong time offline for me...

Spender and Pax Team, pls hurry up to tell me if you want those or not.

Thank you!

Of course I here have to say that if you don't read from me, go figure what could have happened. Read my posts. I want to live and work with my computers! And I would surely like to be around here as well.

Posted: **Fri Aug 23, 2013 9:23 pm**

And there was yet another crash on debinv35, taken photo of, sure.

Posted: **Thu Aug 29, 2013 1:21 am**

I can cofirm that the majority of my suppositions/conjectures/guesses were so very probably true.
The SOHO is now quiet.
You know why?
Because the Debian (no PIE, no canaries for the SSP, as toolchain, along with other deficiencies) which I connect to the internet with, is not connected to the local network at all since then.
Yes there seem to have been some route for the attackers into the SOHO through internet-connected Debian.
And now all is quiet, no crashes.
So it can not be a Gentoo issue really? Can it? The problems were not raised by some Gentoo failures, right? But were introduced through the internet and the local nertwork via Debian, don't you think?
I wish all the best to all good programmers and you can see for yourself which iones are worthy of praise by looking at crashes in my SOHO, what reduced them to mere denial of service, and where it was applied.
I wish to expand, but I haven't yet solved some more impoprtant and pressing issues as you can read here:
https://forums.grsecurity.net/viewtopic.php?f=3&t=3709&p=13455#p13455
Thanks!
Miroslav Rovis
Zagreb, Croatia

Posted: **Wed Oct 30, 2013 2:35 pm**

I don't have time to read the entire thread. If some reader knows where these links fit in the text, pls. let us know!

And in case these images are cropped on your monitor (like on mine 1024x768 monitor), pls use these links:
http://www.croatiafidelis.hr/gnu/grsec/2013-08-23_14.54.00_debinv35_1280x1080.jpg

http://www.croatiafidelis.hr/gnu/grsec/2013-08-24_02.55.42_debinv35_1280x1080.jpg

http://www.croatiafidelis.hr/gnu/grsec/2013-08-25_18.37.28_debinv35_1280x1080.jpg

Posted: **Wed Oct 30, 2013 3:39 pm**

can you try to reproduce this on a more recent kernel (3.11.x)?

Posted: **Thu Oct 31, 2013 6:12 am**

I beg upfront for your patience in gaining my understanding.
What baffles me is that I posted, and you can figure that preparing these things cost me time dearly, this new bug-after-free report:
https://forums.grsecurity.net/viewtopic.php?f=3&t=3841
Only started it, of course.
So this old one I first have to re-read if your question is related to it only, and not the new one at all.
So pls. disperse my misunderstanding if it is not too deep...
Also I am right now trying to complete the tip on the Debian Forums
http://forums.debian.net/viewtopic.php?f=16&t=108616&p=516892
because I care that newbies understand how great the two-pack of programs Grsecurity/Pax is.

Posted: **Wed Jan 15, 2014 1:42 pm**

I just wrote:
viewtopic.php?f=3&t=3709&p=13820#p13820
and here is the beginning of my story of attacks and more proofs for the Grsecurity.

I do have more proofs but, alas, it's such a huge task to present it!

Namely, upon seeing how deep the invasion (incomplete, but deep) was (it was sufficient having used simply Tor browser from a USB stick (the recommended way) on an otherwise quaranteened-from-the-SOHO system previously while accessing the Internet (or was it some recess that the Mallory's code was stored in, in so many of the available places in the ROMs or firmware or somesuch, maybe of one of my Ethernet cards or somewhere else in my computer that was the only one in the last month or so that accessed the internet of all my computers?), to have various spyware deployed, and those defaults on Debian, such as either SELinux, Yama or AppArmor, are blind stupids that let those programs do what they fee like doingl...

Only upon having compiled and installed the Grsecurity patched kernel were those programs revealed in the marvelous logs that Grsecurity keeps on all things relevant that are happening in a system, and sure enough, were prevented from doing their abominable work!

Pls. note, that my Debian system was (still in) infected (state) while fast shut off from the Internet, and, had been infected, or was being infected, obviously either from (probably) one of the USB sticks, and from either some of those hidden recesses that spies made the manafacturer build in somewhere in the USB stick -- such things exist, they do!, or from somewhere else where the hacking code was stowed away in the computer (the only one, again, that accessed the internet days ago before the HDD in it was completely zeroed out, and clone-restored the installation on it from another of my Debian computers (of same hardware), where this other one that I installed Debian from scratch onto, hasn't had any access to the Internet in about one month!

There is only one more suspect, but less likely: the SOHO itself, the hub of it, the 8-way router (8 sockets connection),, which is always, but I mean always offilne, which has never ever been used to go to the Internet, but still a suspect, because it at least in theory could have had malicious code installed onto it through those computers that either:
1) had some access to the internet via other Ethernet cards (pls. mind that most of my computers have two Ethernet cards), even though those other cards had been quaratined while accessing the Internet, fast shut, that is the SOHO accessing cards uplugged from their SOHO sockets... But still, programming does wonders... and code could take effect for later connections...
2) through any of the rumminging in my computers that went on over the WiFi that I inadvertently left connected on the Internet router of my SOHO, that has had only that one computer that showed malicious programs working in it to my recent surprise, of all, connect to the internet (but not when connected to SOHO)...
Only that one computer that showed malicious programs working in it which as mentioned above, only Grsecurity revealed, but Yama, AppArmor and SELinux in the default installed kernel (of 2013-12-27, the latest, from Jigdo Debian downloads), allowed to work...
The WiFi is on the Internet router, not on the SOHO router, so only computers connecting to Internet could have been compromised. Only that one in some one month time of last, but others at other times previously...
I reported on that WiFI connection, somewhat, here:
viewtopic.php?f=3&t=3841
3) through my mobile phone in a Gentoo system of mine, when I, and on that issue I am still not certain, had even thought that my GPG keys were stolen (but they probably weren't). so I revoked my new RSA key... On that issue I have reported but very briefly and incompletely on yet...

As I said in the beginning of this post, alas, it's such a huge task to present this!
Namely, having understood it, and I know now that at least I have to, and that is the first task that I am going to dedicate my time and effort next, but it's still hours, till I do it (hopefully not longer)...
Namely, having understood that the supposedly clean system of mine was compromised, and upon the reinstall of Debian from scratch (the Testing branch, from jigdo downloaded DVDs, the bleeding edge of Debian)...
After having understood that the system was still infected, and while not only offline, but HDD zeroed out!... But RAM left to cool for hours...
[[ Here I get my system rebooted in I don't know which way... But it's the quarantined online system off from the SOHO... I lost a few paragraphs here, sorry! ]]
I'll try and go on with this...
...
Ah, I remember I went explaining how then I clearly figured out that I needed a completely SOHO-quarantined, not online-quarantined clean install from scratch Debian box, from which I would be able to clone clean Debian installs onto my other two Debian boxes, and I was explaining how I spent some two days to build the hardware, so now I have three Debian boxes, not two, of the same MBO and same capacity HDDs, perfect for cloning.

If, I also wrote and lost as the system malfunctioned... Oh, but here it is, the exact log of what happened, which I don't completely understand, but knowledgeable visitors of this forums do:

Code: Select all: Jan 15 13:28:01 naibd9 kernel: [ 3600.641275] grsec: exec of /usr/bin/md5sum (md5sum debian-testing-amd64-DVD-2.iso ) by /usr/bin/md5sum[iso_check-del_0:6692] uid/euid:0/0 gid/egid:0/0, parent /Cmn/Debian/iso_check-del_00.sh[iso_check-del_0:6691] uid/euid:0/0 gid/egid:0/0 Jan 15 13:28:12 naibd9 kernel: [ 3612.394244] grsec: exec of /usr/bin/mplayer1 (mplayer Dizalo usko, ni ta zato!-KQGF1-W37Q4.mp4 ) by /usr/bin/mplayer1[bash:6694] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:5861] uid/euid:1000/1000 gid/egid:1000/1000 Jan 15 13:28:32 naibd9 kernel: [ 3631.864078] grsec: exec of /usr/bin/mplayer1 (mplayer Dizalo usko, ni ta zato!-KQGF1-W37Q4.mp4 ) by /usr/bin/mplayer1[bash:6698] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:5861] uid/euid:1000/1000 gid/egid:1000/1000 Jan 15 13:29:38 naibd9 kernel: [ 3698.388597] PAX: size overflow detected in function __ilog2_u64 include/linux/log2.h:42 cicus.740_22 max, count: 11 Jan 15 13:29:38 naibd9 kernel: [ 3698.388606] CPU: 0 PID: 2927 Comm: freshclam Not tainted 3.12.7-grsec-140109 #2 Jan 15 13:29:38 naibd9 kernel: [ 3698.388609] Hardware name: /AT8 32X(ATI RD580-ULI M1575), BIOS 6.00 PG 05/19/2006 Jan 15 13:29:38 naibd9 kernel: [ 3698.388612] 0000000000000000 0000000000000000 ffffffff813b97bd ffffffff81ab47c3 Jan 15 13:29:38 naibd9 kernel: [ 3698.388616] ffffffff8111bffc ffffffff81acf2f2 0000000000000000 0000000000099778 Jan 15 13:29:38 naibd9 kernel: [ 3698.388620] 0000000000006400 ffffffff813b7224 ffff8800ce3c1458 ffffffff810d68d9 Jan 15 13:29:38 naibd9 kernel: [ 3698.388624] Call Trace: Jan 15 13:29:38 naibd9 kernel: [ 3698.388634] [<ffffffff813b97bd>] ? dump_stack+0x41/0x51 Jan 15 13:29:38 naibd9 kernel: [ 3698.388639] [<ffffffff8111bffc>] ? report_size_overflow+0x33/0x3d Jan 15 13:29:38 naibd9 kernel: [ 3698.388643] [<ffffffff813b7224>] ? __ilog2_u64+0x44/0x46 Jan 15 13:29:38 naibd9 kernel: [ 3698.388647] [<ffffffff810d68d9>] ? balance_dirty_pages_ratelimited+0x432/0x721 Jan 15 13:29:38 naibd9 kernel: [ 3698.388683] [<ffffffffa01a5ec0>] ? ext4_exit_fs+0x7f5/0x1e75d [ext4] Jan 15 13:29:38 naibd9 kernel: [ 3698.388688] [<ffffffff810cda8c>] ? generic_file_buffered_write+0x1f8/0x264 Jan 15 13:29:38 naibd9 kernel: [ 3698.388700] [<ffffffffa01a5d30>] ? ext4_exit_fs+0x665/0x1e75d [ext4] Jan 15 13:29:38 naibd9 kernel: [ 3698.388704] [<ffffffff810ce811>] ? __generic_file_aio_write+0x257/0x287 Jan 15 13:29:38 naibd9 kernel: [ 3698.388707] [<ffffffff810ce891>] ? generic_file_aio_write+0x50/0x85 Jan 15 13:29:38 naibd9 kernel: [ 3698.388719] [<ffffffffa0168bc1>] ? ext4_file_write+0x2e2/0x310 [ext4] Jan 15 13:29:38 naibd9 kernel: [ 3698.388723] [<ffffffff8111676f>] ? do_sync_write+0x60/0x85 Jan 15 13:29:38 naibd9 kernel: [ 3698.388727] [<ffffffff811177d4>] ? vfs_write+0xfb/0x174 Jan 15 13:29:38 naibd9 kernel: [ 3698.388730] [<ffffffff81117ba3>] ? SyS_write+0x62/0x98 Jan 15 13:29:38 naibd9 kernel: [ 3698.388735] [<ffffffff813c27c8>] ? system_call_fastpath+0x16/0x1b Jan 15 13:29:55 naibd9 kernel: [ 3714.687686] grsec: exec of /usr/bin/bc (bc ) by /usr/bin/bc[iso_check-del_0:6706] uid/euid:0/0 gid/egid:0/0, parent /Cmn/Debian/iso_check-del_00.sh[iso_check-del_0:6704] uid/euid:0/0 gid/egid:0/0 Jan 15 13:29:55 naibd9 kernel: [ 3714.815744] grsec: exec of /bin/mv (mv -v debian-testing-amd64-DVD-2.iso Old/ ) by /bin/mv[iso_check-del_0:6707] uid/euid:0/0 gid/egid:0/0, parent /Cmn/Debian/iso_check-del_00.sh[iso_check-del_0:6684] uid/euid:0/0 gid/egid:0/0 Jan 15 13:29:55 naibd9 kernel: [ 3714.979782] grsec: exec of /bin/umount (umount -v d-2 ) by /bin/umount[iso_check-del_0:6708] uid/euid:0/0 gid/egid:0/0, parent /Cmn/Debian/iso_check-del_00.sh[iso_check-del_0:6684] uid/euid:0/0 gid/egid:0/0 Jan 15 13:29:55 naibd9 kernel: [ 3715.015363] grsec: unmount of /dev/loop2 by /bin/umount[umount:6708] uid/euid:0/0 gid/egid:0/0, parent /Cmn/Debian/iso_check-del_00.sh[iso_check-del_0:6684] uid/euid:0/0 gid/egid:0/0

As usual, I am not sure if I am pasting too much, or too little...

But I was also saying, something to the effect, that I hope the SOHO itself is not that much compromised, through 1) 2) or 3) as I explained above...

I know I need to post the logs that show how there was that infection with malicious code which the default SELinux, Yama and AppArmor did nothing about, in that box that I thought I installed clean...
Give me more time pls. I now first need some rest.
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr

Posted: **Wed Jan 15, 2014 2:11 pm**

You need some professional help, man.

Posted: **Fri Jan 17, 2014 11:57 am**

Jan 15 13:29:38 naibd9 kernel: [ 3698.388597] PAX: size overflow detected in function __ilog2_u64 include/linux/log2.h:42 cicus.740_22 max, count: 11
Jan 15 13:29:38 naibd9 kernel: [ 3698.388606] CPU: 0 PID: 2927 Comm: freshclam Not tainted 3.12.7-grsec-140109 #2
Jan 15 13:29:38 naibd9 kernel: [ 3698.388609] Hardware name: /AT8 32X(ATI RD580-ULI M1575), BIOS 6.00 PG 05/19/2006
Jan 15 13:29:38 naibd9 kernel: [ 3698.388612] 0000000000000000 0000000000000000 ffffffff813b97bd ffffffff81ab47c3
Jan 15 13:29:38 naibd9 kernel: [ 3698.388616] ffffffff8111bffc ffffffff81acf2f2 0000000000000000 0000000000099778
Jan 15 13:29:38 naibd9 kernel: [ 3698.388620] 0000000000006400 ffffffff813b7224 ffff8800ce3c1458 ffffffff810d68d9
Jan 15 13:29:38 naibd9 kernel: [ 3698.388624] Call Trace:
Jan 15 13:29:38 naibd9 kernel: [ 3698.388634] [<ffffffff813b97bd>] ? dump_stack+0x41/0x51
Jan 15 13:29:38 naibd9 kernel: [ 3698.388639] [<ffffffff8111bffc>] ? report_size_overflow+0x33/0x3d
Jan 15 13:29:38 naibd9 kernel: [ 3698.388643] [<ffffffff813b7224>] ? __ilog2_u64+0x44/0x46
Jan 15 13:29:38 naibd9 kernel: [ 3698.388647] [<ffffffff810d68d9>] ? balance_dirty_pages_ratelimited+0x432/0x721

Hi, thanks for the report. Could you please send me your .config and the results (mm/page-writeback.*) of make mm/page-writeback.o EXTRA_CFLAGS=-fdump-tree-all ?

Posted: **Sat Jan 18, 2014 4:49 am**

ephox wrote:Jan 15 13:29:38 naibd9 kernel: [ 3698.388597] PAX: size overflow detected in function __ilog2_u64 include/linux/log2.h:42 cicus.740_22 max, count: 11
Jan 15 13:29:38 naibd9 kernel: [ 3698.388606] CPU: 0 PID: 2927 Comm: freshclam Not tainted 3.12.7-grsec-140109 #2
Jan 15 13:29:38 naibd9 kernel: [ 3698.388609] Hardware name: /AT8 32X(ATI RD580-ULI M1575), BIOS 6.00 PG 05/19/2006
Jan 15 13:29:38 naibd9 kernel: [ 3698.388612] 0000000000000000 0000000000000000 ffffffff813b97bd ffffffff81ab47c3
Jan 15 13:29:38 naibd9 kernel: [ 3698.388616] ffffffff8111bffc ffffffff81acf2f2 0000000000000000 0000000000099778
Jan 15 13:29:38 naibd9 kernel: [ 3698.388620] 0000000000006400 ffffffff813b7224 ffff8800ce3c1458 ffffffff810d68d9
Jan 15 13:29:38 naibd9 kernel: [ 3698.388624] Call Trace:
Jan 15 13:29:38 naibd9 kernel: [ 3698.388634] [<ffffffff813b97bd>] ? dump_stack+0x41/0x51
Jan 15 13:29:38 naibd9 kernel: [ 3698.388639] [<ffffffff8111bffc>] ? report_size_overflow+0x33/0x3d
Jan 15 13:29:38 naibd9 kernel: [ 3698.388643] [<ffffffff813b7224>] ? __ilog2_u64+0x44/0x46
Jan 15 13:29:38 naibd9 kernel: [ 3698.388647] [<ffffffff810d68d9>] ? balance_dirty_pages_ratelimited+0x432/0x721

Hi, thanks for the report. Could you please send me your .config and the results (mm/page-writeback.*) of make mm/page-writeback.o EXTRA_CFLAGS=-fdump-tree-all ?

Very gladly. ephox!
Just, pls. first thing, forgive me for being late... Oh... Late...

Sorry again for confusion...
I'm seeing this only now, and promply replying.
I'll try and explain clearly. I can't remember is I saved that box, the dd disk dump of it...
Because I wasn't able to get the network on that box *at all* or if I got it, then on any Ethernet on that box I had problems that caused the SOHO router to blink (8-way router, no Internet ever), and switched off), up until I cloned the newest of my Debian disk dump from a clean system (dumps of all the system partitions actually),
But the config, it it's just the config, I might find the one...

But:

ephox wrote:the results (mm/page-writeback.*) of make mm/page-writeback.o EXTRA_CFLAGS=-fdump-tree-all

I at this time, don't understand it. Postponing research on it, till I'm rested, as I'll explain below that I need rtest.

But. Pls. allow more time. I am dead tired after having worked for about maybe two days mostly on compiling Grsecuriy/Pax kernel Debian package, that is now here:

http://www.croatiafidelis.hr/gnu/deb/src-3.12.8-grsec/

Debian users, pls. see in that topic and reply there, esp. if you have issues with my packages:

viewtopic.php?f=3&t=3835

Namely, I have never yet been a developer and I still don't cosider myself one, but those are packages that I believe, and people, now I'm talking to you developers, pls. tell me if I'm wrong... but those are packages that I believe can be installed on any AMD64 Debian, or almost any...

And from that work, as well as from various security problems with my network, I am now dead tired...
So, pls. allow more time.
Miroslav Rovis,
Zagreb, Croatia
http://www.CroatiaFidelis.hr

Posted: **Sat Jan 18, 2014 3:41 pm**

Hi, ephos!
EDIT START
sorry, it's ephox, e-fox, but can't go and correct the upload dir name
EDIT END

I actually pretty quickly figured out what your instructions meant.

I entered into /Cmn/src/linux-3.12.8 on the clean box, because I don't have a kernel unpacked in this Internet-only-no-SOHO box (and it was 3.12.7), and that 3.12.8 is the kernel that I uploaded the Debian packages for newbies to try and install Grsecurity/Pax patched Debian kernel on their AMD64 boxes. I don't have enough room on my /usr or /home containing partition, so I compile the kernel in a custom directory elsewhere, and it doesn't get copied over when I clone one of my Debian boxes, the cleanest SOHO-only, of course, onto another Debian box (the very tear-and-wear Internet-only-no-SOHO box, only one of my three Debian boxes, now three, used to be two, but attacks have made me go and rebuild some of the hardware stowed away as last reserve)...

So, I was saying, in another Debian box, with the kernel sources, I entered into /where-i-keep/src/linux-3.12.8/ and issued there:

# make mm/page-writeback.o EXTRA_CFLAGS=-fdump-tree-all

The output of the compilation that ensued, if copied elsewhere in a dir is, on this clean system some 30+ MB and gzipped it's some 6MB, easy to upload on my site, but I believe you don't need this clean system "writing back dirty pages at the address_space level" collection, but from the now non-extant dirty system.
(on which anyway, there was no kernel source to run the make mm/writeback.o ... on)...

But... But... If it is about the kernel source itself, and regardless of the intrusions/something-else/brokenness of the system that made that Call trace above happen... which I now think I understand that it is about...

So, in my previous paragraph, I was somewhat wrong... I mean then it's about that particular kernel in question, and not about where it is deployed...

Then I can probably find both the kernel and its .config.

I would need to rummage a little through my backup dd dumps, and fsarchiver dumps, as well as through the screencasts which I keep when I go online (to find out which exact kernel it was, it's not 3.12.7 but some earlier), because the system of the time that the Call trace above was produced does not exist. As I said, whatever the brokenness was that was in whichever way induced in it, but it was just impossible to use Ethernet cards which I previously used to connect to Internet with (this is more precise description than what I stated in the previous post before I took some rest, in my first reply to your request), on the SOHO, and worse, any card that was in the box, during quite long time of that box being connected to the Internet (downloading Debian testing and source jigdo DVDs, some 80GB on a connection of 640kB/s max, fraction of what I pay to my provider, censorship, but not indulging about it here), usually two cards in my Debian boxes, any card would make the SOHO router blink and switch off, of course not from power, but all the eight connections that it has...

Physically switching that SOHO router off, unplugging it, actually, from the mains, and plugging it back in, would make it blink and reconnect all of the 8 possible connections, whichever of them it had connected, but if that dirty system remained connected, it wouldn't last long, minutes only, or even less, and it would reblink and connect off and no lights any of whichever of the 8 connections whether physically connected or not.

But the SOHO router is functioning fine, without that box (haven't tried yet with a cloned from clean Debian installation now on it) being connected to it... Sic! Functioning fine!

Haven't tried yet with a cloned from clean Debian installation now on this SOHO-router-blinking-and-swithing-off box, and I probably won't be trying that so soon, I am using growisofs and writing a session at a time on a DVD when I need to transfer a few files from that box or onto that box. Then I'll pull of the plug on the system, and replace some other Ethernet card in, and will probably be only then, able to connect it to the SOHO, and clone some good Debian install onto it...

This sounds incredible and it I'm still amazed for watching all the blinking and switching off happen, and it is as true and honest as you can believe me. I don't think any analysis could find me to be a lier. Rigged conviction 2 yrs time suspended (from 2010 to 2012), but no one can say it wasn't rigged for political reasons and stay truthful themselves...

So let's see if I finally understand correctly.

I could try and find out which kernel that was, recompile it and give back to you those dirty writeback tests, and that I can do on any of my same MBO Debian systems?

If it is useful for GNU Linux and the free world of honest developers and users, I could try and do it...

Since I am not certain that I got it right, I'll wait for your confirmation.

Still thinking... Let me see... I saw similar symptoms again, on the 3.12.7 kernel clone that is now in that same box... I have one of the terminal of the Lxterminal frozen upon simply trying to 'cat > some_text.txt' in it, just as I saw last time, before I saw the Call Trace...

Yes, I do have a new Call trace, quite a few of them, and I can first thing post the new Call Traces here, I guess...

On another note, I'm sure someone like you and the our shiny white hats who mend the GNU Linux stray-ways of the kernel read fast enough for my long post (in which for newbie newbier than me there is, I think, a line of thinking could help them figure out more in this hard task a newbie user have if he wants to secure their system, like I am trying, so, I guess, in that sense, it is not too verbose....

But I hope you read fast enough and have reached here where we are now probably close to solving this issue (not altogether, no, the Debian is yet far from salvaged... if ever it will be... still hopeful it will be...), to solving this part about Call Traces and dirty pages writeback...

I looked up, I don't have a source of 3.12.7 deployed as it happens to be after a compilation (some 12G it is for 3.12.8, which I still have deployed on one of my Debians).

I suppose these new Call Traces, because the system is still there, you will prefer from the old Call Trace above, in the post of mine second to previous, I believe, when you asked for the .config, which I know is the same file as /boot/config-3.12.7-grsec-140113-16 which I will post and enter the link here:

http://www.CroatiaFidelis.hr/gnu/grsec/ ... -140113-16
P.S. also there:
http://www.CroatiaFidelis.hr/gnu/grsec/ ... -140117-06

(P.S. actually all the links will be viewable/downloadable --if all goes well-- and SHA256SUMS signed with my key will be there:
http://www.CroatiaFidelis.hr/gnu/grsec/ephos-3.12.x/
in that directory)

. The whole of kern.log I will also post, and give the link here:

http://www.CroatiaFidelis.hr/gnu/grsec/ ... ern.log.gz
EDIT START Sat Jan 18 16:08:11 EST 2014
No, it just must be too risky keeping the whole kern.log public.
After all it is in /var/log readable only by root... so, I'll post just excerpts with the Call Traces, so the public can, if they want, learn as much as possible.
Here, this is what I almost *only* get when I connect to the Internet, more rarely also offline sometimes, but *only* on the boxes that had been connected. I don't get these on my boxes solely on my SOHO (even though I am not anymore sure that my SOHO has no malware by now in the router itself... Here is excerpts from /var/log/kern.log:

Code: Select all: ...[snip]... Jan 18 03:54:40 naibd7 kernel: [11855.797952] grsec: chdir to /usr/share/vim/vim74/plugin by /usr/bin/vim.basic[vi:4003] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:2949] uid/euid:1000/1000 gid/egid:1000/1000 Jan 18 03:54:40 naibd7 kernel: [11855.797964] grsec: chdir to /home/mr by /usr/bin/vim.basic[vi:4003] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:2949] uid/euid:1000/1000 gid/egid:1000/1000 Jan 18 03:57:06 naibd7 kernel: [12002.104074] INFO: task bash:3234 blocked for more than 120 seconds. Jan 18 03:57:06 naibd7 kernel: [12002.104083] Not tainted 3.12.7-grsec-140113-16 #2 Jan 18 03:57:06 naibd7 kernel: [12002.104086] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jan 18 03:57:06 naibd7 kernel: [12002.104088] bash D ffff8801271f65c0 0 3234 2947 0x00000000 Jan 18 03:57:06 naibd7 kernel: [12002.104094] ffff8801271f6280 0000000000000086 0000000000010f80 ffff8801271f6730 Jan 18 03:57:06 naibd7 kernel: [12002.104098] 0000000000010f80 ffff8801271f6730 ffff8801271f6280 ffff8800cd9d7ba0 Jan 18 03:57:06 naibd7 kernel: [12002.104102] ffff8800bd0c5cd8 ffff8800bd0c5ce0 ffffffff00000000 ffff8800bd0c5ce8 Jan 18 03:57:06 naibd7 kernel: [12002.104106] Call Trace: Jan 18 03:57:06 naibd7 kernel: [12002.104117] [<ffffffff814cbe4d>] ? rwsem_down_write_failed+0xfd/0x1b0 Jan 18 03:57:06 naibd7 kernel: [12002.104124] [<ffffffff812766d3>] ? call_rwsem_down_write_failed+0x13/0x20 Jan 18 03:57:06 naibd7 kernel: [12002.104129] [<ffffffff8131e8e0>] ? n_tty_chars_in_buffer+0x90/0x90 Jan 18 03:57:06 naibd7 kernel: [12002.104135] [<ffffffff814c9eab>] ? down_write+0x2b/0x2d Jan 18 03:57:06 naibd7 kernel: [12002.104139] [<ffffffff81322be3>] ? tty_set_termios+0x33/0x380 Jan 18 03:57:06 naibd7 kernel: [12002.104143] [<ffffffff81322aac>] ? tty_wait_until_sent+0x3c/0x140 Jan 18 03:57:06 naibd7 kernel: [12002.104147] [<ffffffff8132360f>] ? set_termios+0x19f/0x400 Jan 18 03:57:06 naibd7 kernel: [12002.104151] [<ffffffff81323df0>] ? tty_mode_ioctl+0x580/0x820 Jan 18 03:57:06 naibd7 kernel: [12002.104155] [<ffffffff8131dafc>] ? tty_ioctl+0x77c/0xd20 Jan 18 03:57:06 naibd7 kernel: [12002.104161] [<ffffffff8119840e>] ? do_vfs_ioctl+0x43e/0x720 Jan 18 03:57:06 naibd7 kernel: [12002.104165] [<ffffffff8119872e>] ? SyS_ioctl+0x3e/0x80 Jan 18 03:57:06 naibd7 kernel: [12002.104169] [<ffffffff814d3e6a>] ? system_call_fastpath+0x16/0x1b Jan 18 03:57:06 naibd7 kernel: [12002.104173] [<ffffffff814d3e9c>] ? sysret_check+0x28/0x67 Jan 18 03:57:06 naibd7 kernel: [12002.104183] INFO: task kworker/0:0:3967 blocked for more than 120 seconds. Jan 18 03:57:06 naibd7 kernel: [12002.104185] Not tainted 3.12.7-grsec-140113-16 #2 Jan 18 03:57:06 naibd7 kernel: [12002.104187] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jan 18 03:57:06 naibd7 kernel: [12002.104189] kworker/0:0 D ffff880127a0baa0 0 3967 2 0x00000000 Jan 18 03:57:06 naibd7 kernel: [12002.104194] Workqueue: events ffffffff81325250 Jan 18 03:57:06 naibd7 kernel: [12002.104196] ffff880127a0b760 0000000000000046 0000000000010f80 ffff880127a0bc10 Jan 18 03:57:06 naibd7 kernel: [12002.104200] 0000000000010f80 ffff880127a0bc10 ffff880127a0b760 ffff880036f0dd48 Jan 18 03:57:06 naibd7 kernel: [12002.104203] ffff8800bd0c5cd8 ffffffffffffffff ffff8800bd0c5ce0 ffff8800bd0c5c00 Jan 18 03:57:06 naibd7 kernel: [12002.104207] Call Trace: Jan 18 03:57:06 naibd7 kernel: [12002.104211] [<ffffffff814cbd15>] ? rwsem_down_read_failed+0xf5/0x130 Jan 18 03:57:06 naibd7 kernel: [12002.104216] [<ffffffff812766a4>] ? call_rwsem_down_read_failed+0x14/0x30 Jan 18 03:57:06 naibd7 kernel: [12002.104220] [<ffffffff814c9e6f>] ? down_read+0x1f/0x30 Jan 18 03:57:06 naibd7 kernel: [12002.104224] [<ffffffff8132247b>] ? n_tty_receive_buf2+0x3b/0xc0 Jan 18 03:57:06 naibd7 kernel: [12002.104228] [<ffffffff81325315>] ? flush_to_ldisc+0xc5/0x120 Jan 18 03:57:06 naibd7 kernel: [12002.104233] [<ffffffff81079f36>] ? process_one_work+0x166/0x420 Jan 18 03:57:06 naibd7 kernel: [12002.104237] [<ffffffff8107b0ed>] ? worker_thread+0x11d/0x3c0 Jan 18 03:57:06 naibd7 kernel: [12002.104241] [<ffffffff8107afd0>] ? rescuer_thread+0x330/0x330 Jan 18 03:57:06 naibd7 kernel: [12002.104245] [<ffffffff8108226f>] ? kthread+0xaf/0xc0 Jan 18 03:57:06 naibd7 kernel: [12002.104249] [<ffffffff810821c0>] ? insert_kthread_work+0x40/0x40 Jan 18 03:57:06 naibd7 kernel: [12002.104252] [<ffffffff814d3db4>] ? ret_from_fork+0x74/0xa0 Jan 18 03:57:06 naibd7 kernel: [12002.104256] [<ffffffff810821c0>] ? insert_kthread_work+0x40/0x40 Jan 18 03:59:06 naibd7 kernel: [12122.104074] INFO: task bash:3234 blocked for more than 120 seconds. Jan 18 03:59:06 naibd7 kernel: [12122.104082] Not tainted 3.12.7-grsec-140113-16 #2 Jan 18 03:59:06 naibd7 kernel: [12122.104083] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jan 18 03:59:06 naibd7 kernel: [12122.104086] bash D ffff8801271f65c0 0 3234 2947 0x00000000 Jan 18 03:59:06 naibd7 kernel: [12122.104090] ffff8801271f6280 0000000000000086 0000000000010f80 ffff8801271f6730 Jan 18 03:59:06 naibd7 kernel: [12122.104093] 0000000000010f80 ffff8801271f6730 ffff8801271f6280 ffff8800cd9d7ba0 Jan 18 03:59:06 naibd7 kernel: [12122.104096] ffff8800bd0c5cd8 ffff8800bd0c5ce0 ffffffff00000000 ffff8800bd0c5ce8 Jan 18 03:59:06 naibd7 kernel: [12122.104099] Call Trace: Jan 18 03:59:06 naibd7 kernel: [12122.104109] [<ffffffff814cbe4d>] ? rwsem_down_write_failed+0xfd/0x1b0 Jan 18 03:59:06 naibd7 kernel: [12122.104115] [<ffffffff812766d3>] ? call_rwsem_down_write_failed+0x13/0x20 Jan 18 03:59:06 naibd7 kernel: [12122.104120] [<ffffffff8131e8e0>] ? n_tty_chars_in_buffer+0x90/0x90 Jan 18 03:59:06 naibd7 kernel: [12122.104124] [<ffffffff814c9eab>] ? down_write+0x2b/0x2d Jan 18 03:59:06 naibd7 kernel: [12122.104127] [<ffffffff81322be3>] ? tty_set_termios+0x33/0x380 Jan 18 03:59:06 naibd7 kernel: [12122.104130] [<ffffffff81322aac>] ? tty_wait_until_sent+0x3c/0x140 Jan 18 03:59:06 naibd7 kernel: [12122.104134] [<ffffffff8132360f>] ? set_termios+0x19f/0x400 Jan 18 03:59:06 naibd7 kernel: [12122.104137] [<ffffffff81323df0>] ? tty_mode_ioctl+0x580/0x820 Jan 18 03:59:06 naibd7 kernel: [12122.104140] [<ffffffff8131dafc>] ? tty_ioctl+0x77c/0xd20 Jan 18 03:59:06 naibd7 kernel: [12122.104144] [<ffffffff8119840e>] ? do_vfs_ioctl+0x43e/0x720 Jan 18 03:59:06 naibd7 kernel: [12122.104147] [<ffffffff8119872e>] ? SyS_ioctl+0x3e/0x80 Jan 18 03:59:06 naibd7 kernel: [12122.104150] [<ffffffff814d3e6a>] ? system_call_fastpath+0x16/0x1b Jan 18 03:59:06 naibd7 kernel: [12122.104153] [<ffffffff814d3e9c>] ? sysret_check+0x28/0x67 Jan 18 03:59:06 naibd7 kernel: [12122.104163] INFO: task kworker/0:0:3967 blocked for more than 120 seconds. Jan 18 03:59:06 naibd7 kernel: [12122.104165] Not tainted 3.12.7-grsec-140113-16 #2 Jan 18 03:59:06 naibd7 kernel: [12122.104166] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jan 18 03:59:06 naibd7 kernel: [12122.104167] kworker/0:0 D ffff880127a0baa0 0 3967 2 0x00000000 Jan 18 03:59:06 naibd7 kernel: [12122.104172] Workqueue: events ffffffff81325250 Jan 18 03:59:06 naibd7 kernel: [12122.104173] ffff880127a0b760 0000000000000046 0000000000010f80 ffff880127a0bc10 Jan 18 03:59:06 naibd7 kernel: [12122.104176] 0000000000010f80 ffff880127a0bc10 ffff880127a0b760 ffff880036f0dd48 Jan 18 03:59:06 naibd7 kernel: [12122.104179] ffff8800bd0c5cd8 ffffffffffffffff ffff8800bd0c5ce0 ffff8800bd0c5c00 Jan 18 03:59:06 naibd7 kernel: [12122.104181] Call Trace: Jan 18 03:59:06 naibd7 kernel: [12122.104184] [<ffffffff814cbd15>] ? rwsem_down_read_failed+0xf5/0x130 Jan 18 03:59:06 naibd7 kernel: [12122.104188] [<ffffffff812766a4>] ? call_rwsem_down_read_failed+0x14/0x30 Jan 18 03:59:06 naibd7 kernel: [12122.104191] [<ffffffff814c9e6f>] ? down_read+0x1f/0x30 Jan 18 03:59:06 naibd7 kernel: [12122.104194] [<ffffffff8132247b>] ? n_tty_receive_buf2+0x3b/0xc0 Jan 18 03:59:06 naibd7 kernel: [12122.104198] [<ffffffff81325315>] ? flush_to_ldisc+0xc5/0x120 Jan 18 03:59:06 naibd7 kernel: [12122.104202] [<ffffffff81079f36>] ? process_one_work+0x166/0x420 Jan 18 03:59:06 naibd7 kernel: [12122.104205] [<ffffffff8107b0ed>] ? worker_thread+0x11d/0x3c0 Jan 18 03:59:06 naibd7 kernel: [12122.104208] [<ffffffff8107afd0>] ? rescuer_thread+0x330/0x330 Jan 18 03:59:06 naibd7 kernel: [12122.104211] [<ffffffff8108226f>] ? kthread+0xaf/0xc0 Jan 18 03:59:06 naibd7 kernel: [12122.104214] [<ffffffff810821c0>] ? insert_kthread_work+0x40/0x40 Jan 18 03:59:06 naibd7 kernel: [12122.104216] [<ffffffff814d3db4>] ? ret_from_fork+0x74/0xa0 Jan 18 03:59:06 naibd7 kernel: [12122.104219] [<ffffffff810821c0>] ? insert_kthread_work+0x40/0x40 Jan 18 03:59:18 naibd7 kernel: [12133.489094] grsec: exec of /bin/cat (cat /Cmn/src-3.12.8-grsec/grsec_debian_v3.12.8.sh ) by /bin/cat[bash:4014] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:2949] uid/euid:1000/1000 gid/egid:1000/1000 Jan 18 04:01:06 naibd7 kernel: [12242.104074] INFO: task bash:3234 blocked for more than 120 seconds. Jan 18 04:01:06 naibd7 kernel: [12242.104083] Not tainted 3.12.7-grsec-140113-16 #2 Jan 18 04:01:06 naibd7 kernel: [12242.104085] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jan 18 04:01:06 naibd7 kernel: [12242.104088] bash D ffff8801271f65c0 0 3234 2947 0x00000000 Jan 18 04:01:06 naibd7 kernel: [12242.104093] ffff8801271f6280 0000000000000086 0000000000010f80 ffff8801271f6730 Jan 18 04:01:06 naibd7 kernel: [12242.104096] 0000000000010f80 ffff8801271f6730 ffff8801271f6280 ffff8800cd9d7ba0 Jan 18 04:01:06 naibd7 kernel: [12242.104099] ffff8800bd0c5cd8 ffff8800bd0c5ce0 ffffffff00000000 ffff8800bd0c5ce8 Jan 18 04:01:06 naibd7 kernel: [12242.104102] Call Trace: Jan 18 04:01:06 naibd7 kernel: [12242.104113] [<ffffffff814cbe4d>] ? rwsem_down_write_failed+0xfd/0x1b0 Jan 18 04:01:06 naibd7 kernel: [12242.104119] [<ffffffff812766d3>] ? call_rwsem_down_write_failed+0x13/0x20 Jan 18 04:01:06 naibd7 kernel: [12242.104124] [<ffffffff8131e8e0>] ? n_tty_chars_in_buffer+0x90/0x90 Jan 18 04:01:06 naibd7 kernel: [12242.104130] [<ffffffff814c9eab>] ? down_write+0x2b/0x2d Jan 18 04:01:06 naibd7 kernel: [12242.104133] [<ffffffff81322be3>] ? tty_set_termios+0x33/0x380 Jan 18 04:01:06 naibd7 kernel: [12242.104137] [<ffffffff81322aac>] ? tty_wait_until_sent+0x3c/0x140 Jan 18 04:01:06 naibd7 kernel: [12242.104140] [<ffffffff8132360f>] ? set_termios+0x19f/0x400 Jan 18 04:01:06 naibd7 kernel: [12242.104143] [<ffffffff81323df0>] ? tty_mode_ioctl+0x580/0x820 Jan 18 04:01:06 naibd7 kernel: [12242.104146] [<ffffffff8131dafc>] ? tty_ioctl+0x77c/0xd20 Jan 18 04:01:06 naibd7 kernel: [12242.104151] [<ffffffff8119840e>] ? do_vfs_ioctl+0x43e/0x720 Jan 18 04:01:06 naibd7 kernel: [12242.104154] [<ffffffff8119872e>] ? SyS_ioctl+0x3e/0x80 Jan 18 04:01:06 naibd7 kernel: [12242.104158] [<ffffffff814d3e6a>] ? system_call_fastpath+0x16/0x1b Jan 18 04:01:06 naibd7 kernel: [12242.104161] [<ffffffff814d3e9c>] ? sysret_check+0x28/0x67 Jan 18 04:01:06 naibd7 kernel: [12242.104171] INFO: task kworker/0:0:3967 blocked for more than 120 seconds. Jan 18 04:01:06 naibd7 kernel: [12242.104173] Not tainted 3.12.7-grsec-140113-16 #2 Jan 18 04:01:06 naibd7 kernel: [12242.104174] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jan 18 04:01:06 naibd7 kernel: [12242.104176] kworker/0:0 D ffff880127a0baa0 0 3967 2 0x00000000 Jan 18 04:01:06 naibd7 kernel: [12242.104181] Workqueue: events ffffffff81325250 Jan 18 04:01:06 naibd7 kernel: [12242.104182] ffff880127a0b760 0000000000000046 0000000000010f80 ffff880127a0bc10 Jan 18 04:01:06 naibd7 kernel: [12242.104185] 0000000000010f80 ffff880127a0bc10 ffff880127a0b760 ffff880036f0dd48 Jan 18 04:01:06 naibd7 kernel: [12242.104188] ffff8800bd0c5cd8 ffffffffffffffff ffff8800bd0c5ce0 ffff8800bd0c5c00 Jan 18 04:01:06 naibd7 kernel: [12242.104191] Call Trace: Jan 18 04:01:06 naibd7 kernel: [12242.104194] [<ffffffff814cbd15>] ? rwsem_down_read_failed+0xf5/0x130 Jan 18 04:01:06 naibd7 kernel: [12242.104198] [<ffffffff812766a4>] ? call_rwsem_down_read_failed+0x14/0x30 Jan 18 04:01:06 naibd7 kernel: [12242.104202] [<ffffffff814c9e6f>] ? down_read+0x1f/0x30 Jan 18 04:01:06 naibd7 kernel: [12242.104205] [<ffffffff8132247b>] ? n_tty_receive_buf2+0x3b/0xc0 Jan 18 04:01:06 naibd7 kernel: [12242.104208] [<ffffffff81325315>] ? flush_to_ldisc+0xc5/0x120 Jan 18 04:01:06 naibd7 kernel: [12242.104213] [<ffffffff81079f36>] ? process_one_work+0x166/0x420 Jan 18 04:01:06 naibd7 kernel: [12242.104216] [<ffffffff8107b0ed>] ? worker_thread+0x11d/0x3c0 Jan 18 04:01:06 naibd7 kernel: [12242.104219] [<ffffffff8107afd0>] ? rescuer_thread+0x330/0x330 Jan 18 04:01:06 naibd7 kernel: [12242.104223] [<ffffffff8108226f>] ? kthread+0xaf/0xc0 Jan 18 04:01:06 naibd7 kernel: [12242.104226] [<ffffffff810821c0>] ? insert_kthread_work+0x40/0x40 Jan 18 04:01:06 naibd7 kernel: [12242.104228] [<ffffffff814d3db4>] ? ret_from_fork+0x74/0xa0 Jan 18 04:01:06 naibd7 kernel: [12242.104231] [<ffffffff810821c0>] ? insert_kthread_work+0x40/0x40 Jan 18 04:03:06 naibd7 kernel: [12362.104076] INFO: task bash:3234 blocked for more than 120 seconds. Jan 18 04:03:06 naibd7 kernel: [12362.104086] Not tainted 3.12.7-grsec-140113-16 #2 Jan 18 04:03:06 naibd7 kernel: [12362.104088] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jan 18 04:03:06 naibd7 kernel: [12362.104091] bash D ffff8801271f65c0 0 3234 2947 0x00000000 Jan 18 04:03:06 naibd7 kernel: [12362.104096] ffff8801271f6280 0000000000000086 0000000000010f80 ffff8801271f6730 Jan 18 04:03:06 naibd7 kernel: [12362.104100] 0000000000010f80 ffff8801271f6730 ffff8801271f6280 ffff8800cd9d7ba0 Jan 18 04:03:06 naibd7 kernel: [12362.104103] ffff8800bd0c5cd8 ffff8800bd0c5ce0 ffffffff00000000 ffff8800bd0c5ce8 Jan 18 04:03:06 naibd7 kernel: [12362.104107] Call Trace: Jan 18 04:03:06 naibd7 kernel: [12362.104117] [<ffffffff814cbe4d>] ? rwsem_down_write_failed+0xfd/0x1b0 Jan 18 04:03:06 naibd7 kernel: [12362.104124] [<ffffffff812766d3>] ? call_rwsem_down_write_failed+0x13/0x20 Jan 18 04:03:06 naibd7 kernel: [12362.104130] [<ffffffff8131e8e0>] ? n_tty_chars_in_buffer+0x90/0x90 Jan 18 04:03:06 naibd7 kernel: [12362.104135] [<ffffffff814c9eab>] ? down_write+0x2b/0x2d Jan 18 04:03:06 naibd7 kernel: [12362.104139] [<ffffffff81322be3>] ? tty_set_termios+0x33/0x380 Jan 18 04:03:06 naibd7 kernel: [12362.104142] [<ffffffff81322aac>] ? tty_wait_until_sent+0x3c/0x140 Jan 18 04:03:06 naibd7 kernel: [12362.104146] [<ffffffff8132360f>] ? set_termios+0x19f/0x400 Jan 18 04:03:06 naibd7 kernel: [12362.104150] [<ffffffff81323df0>] ? tty_mode_ioctl+0x580/0x820 Jan 18 04:03:06 naibd7 kernel: [12362.104153] [<ffffffff8131dafc>] ? tty_ioctl+0x77c/0xd20 Jan 18 04:03:06 naibd7 kernel: [12362.104158] [<ffffffff8119840e>] ? do_vfs_ioctl+0x43e/0x720 Jan 18 04:03:06 naibd7 kernel: [12362.104162] [<ffffffff8119872e>] ? SyS_ioctl+0x3e/0x80 Jan 18 04:03:06 naibd7 kernel: [12362.104165] [<ffffffff814d3e6a>] ? system_call_fastpath+0x16/0x1b Jan 18 04:03:06 naibd7 kernel: [12362.104169] [<ffffffff814d3e9c>] ? sysret_check+0x28/0x67 Jan 18 04:03:06 naibd7 kernel: [12362.104178] INFO: task kworker/0:0:3967 blocked for more than 120 seconds. Jan 18 04:03:06 naibd7 kernel: [12362.104180] Not tainted 3.12.7-grsec-140113-16 #2 Jan 18 04:03:06 naibd7 kernel: [12362.104182] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jan 18 04:03:06 naibd7 kernel: [12362.104183] kworker/0:0 D ffff880127a0baa0 0 3967 2 0x00000000 Jan 18 04:03:06 naibd7 kernel: [12362.104188] Workqueue: events ffffffff81325250 Jan 18 04:03:06 naibd7 kernel: [12362.104190] ffff880127a0b760 0000000000000046 0000000000010f80 ffff880127a0bc10 Jan 18 04:03:06 naibd7 kernel: [12362.104193] 0000000000010f80 ffff880127a0bc10 ffff880127a0b760 ffff880036f0dd48 Jan 18 04:03:06 naibd7 kernel: [12362.104196] ffff8800bd0c5cd8 ffffffffffffffff ffff8800bd0c5ce0 ffff8800bd0c5c00 Jan 18 04:03:06 naibd7 kernel: [12362.104200] Call Trace: Jan 18 04:03:06 naibd7 kernel: [12362.104203] [<ffffffff814cbd15>] ? rwsem_down_read_failed+0xf5/0x130 Jan 18 04:03:06 naibd7 kernel: [12362.104208] [<ffffffff812766a4>] ? call_rwsem_down_read_failed+0x14/0x30 Jan 18 04:03:06 naibd7 kernel: [12362.104212] [<ffffffff814c9e6f>] ? down_read+0x1f/0x30 Jan 18 04:03:06 naibd7 kernel: [12362.104215] [<ffffffff8132247b>] ? n_tty_receive_buf2+0x3b/0xc0 Jan 18 04:03:06 naibd7 kernel: [12362.104219] [<ffffffff81325315>] ? flush_to_ldisc+0xc5/0x120 Jan 18 04:03:06 naibd7 kernel: [12362.104224] [<ffffffff81079f36>] ? process_one_work+0x166/0x420 Jan 18 04:03:06 naibd7 kernel: [12362.104227] [<ffffffff8107b0ed>] ? worker_thread+0x11d/0x3c0 Jan 18 04:03:06 naibd7 kernel: [12362.104231] [<ffffffff8107afd0>] ? rescuer_thread+0x330/0x330 Jan 18 04:03:06 naibd7 kernel: [12362.104235] [<ffffffff8108226f>] ? kthread+0xaf/0xc0 Jan 18 04:03:06 naibd7 kernel: [12362.104238] [<ffffffff810821c0>] ? insert_kthread_work+0x40/0x40 Jan 18 04:03:06 naibd7 kernel: [12362.104241] [<ffffffff814d3db4>] ? ret_from_fork+0x74/0xa0 Jan 18 04:03:06 naibd7 kernel: [12362.104244] [<ffffffff810821c0>] ? insert_kthread_work+0x40/0x40 Jan 18 04:05:06 naibd7 kernel: [12482.104096] INFO: task bash:3234 blocked for more than 120 seconds. Jan 18 04:05:06 naibd7 kernel: [12482.104105] Not tainted 3.12.7-grsec-140113-16 #2 Jan 18 04:05:06 naibd7 kernel: [12482.104107] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jan 18 04:05:06 naibd7 kernel: [12482.104109] bash D ffff8801271f65c0 0 3234 2947 0x00000000 Jan 18 04:05:06 naibd7 kernel: [12482.104114] ffff8801271f6280 0000000000000086 0000000000010f80 ffff8801271f6730 Jan 18 04:05:06 naibd7 kernel: [12482.104118] 0000000000010f80 ffff8801271f6730 ffff8801271f6280 ffff8800cd9d7ba0 Jan 18 04:05:06 naibd7 kernel: [12482.104121] ffff8800bd0c5cd8 ffff8800bd0c5ce0 ffffffff00000000 ffff8800bd0c5ce8 Jan 18 04:05:06 naibd7 kernel: [12482.104125] Call Trace: Jan 18 04:05:06 naibd7 kernel: [12482.104136] [<ffffffff814cbe4d>] ? rwsem_down_write_failed+0xfd/0x1b0 Jan 18 04:05:06 naibd7 kernel: [12482.104143] [<ffffffff812766d3>] ? call_rwsem_down_write_failed+0x13/0x20 Jan 18 04:05:06 naibd7 kernel: [12482.104148] [<ffffffff8131e8e0>] ? n_tty_chars_in_buffer+0x90/0x90 Jan 18 04:05:06 naibd7 kernel: [12482.104153] [<ffffffff814c9eab>] ? down_write+0x2b/0x2d Jan 18 04:05:06 naibd7 kernel: [12482.104157] [<ffffffff81322be3>] ? tty_set_termios+0x33/0x380 Jan 18 04:05:06 naibd7 kernel: [12482.104160] [<ffffffff81322aac>] ? tty_wait_until_sent+0x3c/0x140 Jan 18 04:05:06 naibd7 kernel: [12482.104164] [<ffffffff8132360f>] ? set_termios+0x19f/0x400 Jan 18 04:05:06 naibd7 kernel: [12482.104168] [<ffffffff81323df0>] ? tty_mode_ioctl+0x580/0x820 Jan 18 04:05:06 naibd7 kernel: [12482.104171] [<ffffffff8131dafc>] ? tty_ioctl+0x77c/0xd20 Jan 18 04:05:06 naibd7 kernel: [12482.104176] [<ffffffff8119840e>] ? do_vfs_ioctl+0x43e/0x720 Jan 18 04:05:06 naibd7 kernel: [12482.104180] [<ffffffff8119872e>] ? SyS_ioctl+0x3e/0x80 Jan 18 04:05:06 naibd7 kernel: [12482.104184] [<ffffffff814d3e6a>] ? system_call_fastpath+0x16/0x1b Jan 18 04:05:06 naibd7 kernel: [12482.104187] [<ffffffff814d3e9c>] ? sysret_check+0x28/0x67 Jan 18 04:05:06 naibd7 kernel: [12482.104197] INFO: task kworker/0:0:3967 blocked for more than 120 seconds. Jan 18 04:05:06 naibd7 kernel: [12482.104199] Not tainted 3.12.7-grsec-140113-16 #2 Jan 18 04:05:06 naibd7 kernel: [12482.104200] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Jan 18 04:05:06 naibd7 kernel: [12482.104202] kworker/0:0 D ffff880127a0baa0 0 3967 2 0x00000000 Jan 18 04:05:06 naibd7 kernel: [12482.104207] Workqueue: events ffffffff81325250 Jan 18 04:05:06 naibd7 kernel: [12482.104209] ffff880127a0b760 0000000000000046 0000000000010f80 ffff880127a0bc10 Jan 18 04:05:06 naibd7 kernel: [12482.104212] 0000000000010f80 ffff880127a0bc10 ffff880127a0b760 ffff880036f0dd48 Jan 18 04:05:06 naibd7 kernel: [12482.104215] ffff8800bd0c5cd8 ffffffffffffffff ffff8800bd0c5ce0 ffff8800bd0c5c00 Jan 18 04:05:06 naibd7 kernel: [12482.104218] Call Trace: Jan 18 04:05:06 naibd7 kernel: [12482.104222] [<ffffffff814cbd15>] ? rwsem_down_read_failed+0xf5/0x130 Jan 18 04:05:06 naibd7 kernel: [12482.104226] [<ffffffff812766a4>] ? call_rwsem_down_read_failed+0x14/0x30 Jan 18 04:05:06 naibd7 kernel: [12482.104230] [<ffffffff814c9e6f>] ? down_read+0x1f/0x30 Jan 18 04:05:06 naibd7 kernel: [12482.104234] [<ffffffff8132247b>] ? n_tty_receive_buf2+0x3b/0xc0 Jan 18 04:05:06 naibd7 kernel: [12482.104238] [<ffffffff81325315>] ? flush_to_ldisc+0xc5/0x120 Jan 18 04:05:06 naibd7 kernel: [12482.104242] [<ffffffff81079f36>] ? process_one_work+0x166/0x420 Jan 18 04:05:06 naibd7 kernel: [12482.104246] [<ffffffff8107b0ed>] ? worker_thread+0x11d/0x3c0 Jan 18 04:05:06 naibd7 kernel: [12482.104249] [<ffffffff8107afd0>] ? rescuer_thread+0x330/0x330 Jan 18 04:05:06 naibd7 kernel: [12482.104253] [<ffffffff8108226f>] ? kthread+0xaf/0xc0 Jan 18 04:05:06 naibd7 kernel: [12482.104256] [<ffffffff810821c0>] ? insert_kthread_work+0x40/0x40 Jan 18 04:05:06 naibd7 kernel: [12482.104259] [<ffffffff814d3db4>] ? ret_from_fork+0x74/0xa0 Jan 18 04:05:06 naibd7 kernel: [12482.104263] [<ffffffff810821c0>] ? insert_kthread_work+0x40/0x40 Jan 18 04:06:35 naibd7 kernel: [12570.765871] grsec: exec of /usr/bin/vim.basic (vi /Cmn/mr/Deb_Grsec_03.txt ) by /usr/bin/vim.basic[bash:4018] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:2949] uid/euid:1000/1000 gid/egid:1000/1000 Jan 18 04:06:35 naibd7 kernel: [12570.767764] grsec: chdir to /home/mr by /usr/bin/vim.basic[vi:4018] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:2949] uid/euid:1000/1000 gid/egid:1000/1000 ...[snip]....

EDIT END

. I know it's a little risky having your system exposed, but it is also both a challenge, and also it is my trust in Grsecurity/Pax developers, so I'm risking willingly exposing my system publically. I want the newbies to have more means to figure out how things now stand in the GNU Linux world and it's stray-ways that need very determined correcting (read: patching in dev terms), for which the public at large is so little ungratefully, and maybe even worse, not even aware of!

So if what I supposed, these new Call Traces, are better than old, is not true, and you need the old, correct me. Because I'm going for the new ones...

And my question is, what do I do? Namely I don't have 3.12.7 source unpacked and in the state as it is after compilation and production of the Debian set of packages linux-XXXX-grsec-XXXX.deb.

So what do I do? I unpack the source, put the config-3.12.7-grsec-140113-16 back in as .config and run:

# make mm/page-writeback.o EXTRA_CFLAGS=-fdump-tree-all

Long winding road, but I hope I reached the point where you can keep up with my insufficient understanding and direct me simply and easily.

Yet after more thinking.

Actually, I haven't finished trying to solve all I can before posting all of this online. And I can only be offline writing this. Too unsecure the Debian, as yet, in the attacks I am under...

mkdir /Cmn/src/
cd /Cmn/src/
tar xvf /Cmn/dLo.OLD/bakd_DEL/src_CP/linux-3.12.7.tar
cp -iav /boot/config-3.12.7-grsec-140113-16 linux-3.12.7/.config
cd linux-3.12.7/
make mm/page-writeback.o EXTRA_CFLAGS=-fdump-tree-all

But, alas, on this last-before the newest Debian install, I don't have the development tools installed, because I havent run:
# apt-get build-essential fakeroot
on it, and I can't, because too risky this box to connect to SOHO.

I only got:

make: command not found.

So I have to try on another system, and I hope, it doesn't depend on which kernel it is currently running, because, in my reinstalling Debian, I only have development tools installed on one system of the three, and on that one, 3.12.8-grsec is the running kernel.

So, I went for the same procedure in this newest box, and, since it wasn't a compiled kernel, it asked for a few options, only a few, to choose from, which I didn't have the nerve to think about, and then it went compiling, but is finished soon, and the results are here:

http://www.CroatiaFidelis.hr/gnu/grsec/ ... ack.tar.gz
P.S. also:
http://www.CroatiaFidelis.hr/gnu/grsec/ ... ack.tar.gz

I hope that is what you needed.
Really did my best ;-)

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

grsecurity forums

grsec: halting the system... kernel crash, the Debian side

grsec: halting the system... kernel crash, the Debian side

Re: grsec: halting the system... kernel crash, the Debian si

Re: grsec: halting the system... kernel crash, the Debian si

Re: grsec: halting the system... kernel crash, the Debian si

Re: grsec: halting the system... kernel crash, the Debian si

Re: grsec: halting the system... kernel crash, the Debian si

Re: grsec: halting the system... kernel crash, the Debian si

Re: grsec: halting the system... kernel crash, the Debian si

Re: grsec: halting the system... kernel crash, the Debian si

Re: grsec: halting the system... kernel crash, the Debian si

Re: grsec: halting the system... kernel crash, the Debian si

Re: grsec: halting the system... kernel crash, the Debian si

Re: grsec: halting the system... kernel crash, the Debian si

Re: grsec: halting the system... kernel crash, the Debian si

Re: grsec: halting the system... kernel crash, the Debian si