miroR
commented
6 years ago Open miroR opened 6 years ago
miroR
commented
6 years ago miroR
commented
6 years ago Again, my time online is minimal, always traced (but working on PCAPs is many many times multiple than the time online, for non-experts)... And, just for the less expert than me visiting here, these all (likely, pls. correct me if I'm wrong) troffeys of grsec-unoff. Troffeys, not failures. And I'm making two posts, so not to lose the first post, as often the attacks happen right, or soon, affer I come online.
theLOICofFRANCE
commented
6 years ago @miroR Hi,
If you want us to help you, you will have to avoid opening any exits at all times and perform the tasks you are asked to do so that we can diagnose your problem or even ideally reproduce it.
1] minipli asked you to try with a recent kernel (4.14.4). Have you tried? 2] SKY2 just lost the connection without crashing. This could be due to your router, an outdated software that uses promiscuous mode, or one of your scripts. 3] Update your bios (version 2.80) that might fix the NX warn.
Regards,
miroR
commented
6 years ago On 171207-15:12+0000, Loïc wrote:
@miroR Hi,
If you want us to help you, you will have to avoid opening any exits at all times I apologize. But it also felt a little like my hardware was in peril to some extent. I have already lost Ethernet cards, and DVD drives in the past due to intrusions, and I could prove it, it time would permit me to. Also verly likely one TV card I lost. I'm not joking. My MBOs are one set (doing Air-Gap installing and cloning as I explained here or elsewhere --see why I can't be more precise just next-- so I have at least two of same kind MBOs in a set)... [my MBOs are one set] 4 yrs old, the other set 10 years old, and no chance to get any new set soon. I can't risk them too openly online for too long.
I am also sorry for the reply that I am due to the email by [MEncoder-users] Mencoder involved in system crashes? WAS: DVD rip (to avi) using mencoder Reimar Döffinger in this or one of the other issues of mine (the reason for not being precise coming).
The truth is --if you allow that I am being honest all this time-- every time I've gone online in the past (how long? three weeks intensly, but also a few weeks, nay, at least one month earlier, only less intense), I have had crashes starting when I came online, or soon afterwards, or from the hidden recesses in the system that exploit users can possibly store their stuff. Even after fresh cloning, but then usually the crashing vanishes after one or --rarely-- two crashes. However, the crashing is not always with the ethers which you write below, it is sometimes also with some of the: Mencoder, MPlayer, FFmpeg, (or even other, but those are the most likely candidates).
The reason that I am writing without referring to precise issues/web-archived emails that I mention, has just been said in the above paragraph. I have to be cautious with my time online, so I can't first go online and copy the links, I have to send this first --also because: what if a crash makes it impossible to send this tonight?-- and... And more.
And more, but good stuff, I would hope. I can now (but only now) more confidently go online because I finally completed deployment of grsec RBAC system (I manually installed, from spender's cvsweb that you gave me the links in some of my recent issues, the latest gradm of some 10 days ago). The learning was pretty bad, because there were so many crashes, so the cycle that grsec needs to do the learning (first the full learning, but also later lots of subject learning) hardly ever got completed. And there was little hope that those cycles would complete --not in the online clone-machine, and most important work I do in it, I don't do it in the master Air-Gapped machine-- and I had to spend days figuring out manually a hundred details for subjects and objects here and there... But that work I have pretty much completed finally.
Pls. notice that the crashes were so bad as I explain above. And how much it took me to get RBAC finally deployed. Thank you!
and perform the tasks you are asked to do so that we can diagnose your problem or even ideally reproduce it. I appreciate your and minipli's work and help. (Pls. understand I have, and will be, doing what I can... Which also means, not more than I am capable of doing.) That said, let me look at your kind suggestions below. 1] minipli asked you to try with a recent kernel (4.14.4). Have you tried? Ah, I see. The most recent, not the 4.9? I thought I should go for the vanilla 4.9.x... But I'll follow this more clearly explained (for non-expert) advice of yours instead. Of course if I am able to understand what I need to do once I visit minipli's github, then I'll take 4.14.4 and try. It will be at least one to two hours, the compiling, so hopefully tomorrow morning. Again, if I am able to understand what I need to do, which I assure you I will do my best to... Except...
Except: I would be much more vulnerable for online without grsec-unoff... However, I can try my usual FFmpeg sessions, MPlayer playing and Mencoder, and Tzap recording, and see if I get any crashes.
2] SKY2 just lost the connection without crashing. This could be due to your router, an outdated software that uses promiscuous mode, or one of your scripts. I have found one of the possible reasons. I was going online the wrong way with the refurbished ifupdown program in Ceres, the Devuan unstable (corresponding to Debian unstable). I had the macchanger turned on in (this is previous state, and it was so for long weeks):
cat /etc/default/macchanger | grep true
ENABLE_ON_POST_UP_DOWN=true # And then I would get Ethernet II notice in the PCAPs --which I only now understand what it meant, phew!--. Logging into my router solved that for me, once I saw some five or more different MACs all on the same port, i.e. all that I created from one same machine, one same Ethernet Sky2 card. Now that line above is commented out, and I assign to the eth1 in question a fake, but always same, MAC myself, before going online.
However, my Pale Moon: $ palemoon -v Moonchild Productions Pale Moon 27.4.0 # crashed yesterday (or the day before, can't remember) when I discovered the multiple MACs asigned to same port, same eth1 in same machine, from same eth1 Ether... [my Pale Moon crashed yesterday], and there weren't multiple assigned MACs, so... ( and I can't update Pale Moon very soon, I compile it myself, long time needed )
And also, really, I was sticking carefully to one fake MAC, but there were more crashes regardless, so that wrong use of the new ifupdown program along with such macchanger config as above was not the cause of all of those crashes in all the 5 or so issues that I authored... Wrong ifupdown program use consisted in me mostly running:
which in the older ifupdown was almost fine. In the new it is not needed, it's obviously harmful... Once the ifup down reassigned it all, the eth1 had a new MAC...
Some recent crashes that I had were very likely due to wrong/missing rules. I had one with Postfix crashing today... But just didn't have the strength any more to take it down manually --it's some 30 minutes of typing--, hoping it would be in the logs... But the logs were completely empty of what I saw on the screen. Information lost forever... I do remember it was because this line was missing in this subject:
subject /usr/lib/postfix/sbin o { / h [...] /usr/lib/postfix rx /usr/lib/x86_64-linux-gnu rx /var/spool r /var/spool/postfix rwcdl /var/tmp rwcdl /tmp rwcdl -CAP_ALL +CAP_DAC_READ_SEARCH +CAP_KILL
This line: +CAP_KILL was missing. I saw it when I couldn't shutdown the machine having logged into the role shutdown... Postfix stuck at being unable to kill some of its process. But the crash happened later once I rebooted! However once I added that line --and a few other stuff around Postfix: it's complex, the manually fixing of subjects-- Postfix now behaves. So that crash --unreported in tech terms, since not in the logs-- was probably isolated incident. But it is also the pattern of some of the crashes: missing or wrong RBAC rules.
3] Update your bios (version 2.80) that might fix the NX warn. Thanks for looking into it! I will. I didn't expect there was an update... I get lost in doing things... Sorry!
Regards,
I hope crashes won't be so bad to delay my testing that I promised above: vanilla recent kernel compile, and FFmpeg, MPlayer, Mencoder, my tzap scripts (which I will also post for your kind perusal), and other work that I do.
BTW, 4.9.67 running here --no separate modules, and only what my hardware needs--, and after one belated crash --which I feel it's due to previously to installing it having been online-- is running just fine... However, haven't been online with it yet... --well, other than two times some 70 seconds, first to fix RBAC perms, and second to get new mail, yours included.
But 4.9.67 hasn't been under much strain here, yet. But it will be, because I'll start a long FFmpeg session on the recordings of some two days or so, and see if this time my machine won't crash... I'll let all of it running during the night: Tzap recording, Mencoder recording, FFmpeg conversions on previously recorded either AVIs taken by Mencoder, or M2Ts recorded by Tzap, and if MPlayer, which I'll set so, wakes me up in the morning, I'll know it all worked fine...
But it hasn't in most of these nights... I mostly had crashes, and no wakup music.
The same work as above I can try with vanilla.
But I don't think I should go online with vanilla, wouldn't feel safe, not if these are intrusion attempts, be it only part of all these somewhat diverse crashes that I've had so far...
While trying to send this, here's, among a few rules for /usr/lib/postfix/sbin that grsec asks me to fix, [here's] from the logs, without comments:
Dec 7 23:24:36 gdOv kernel: [22845.096786] IPv4: martian source 255.255.255.255 from 192.168.1.1, on dev eth1 Dec 7 23:24:36 gdOv kernel: [22845.096808] ll header: 00000000: 00 30 4f 47 37 17 2c 95 7f 8b 44 87 08 00 .0OG7.,...N... Dec 7 23:24:36 gdOv kernel: [22845.118784] IPv4: martian source 255.255.255.255 from 192.168.1.1, on dev eth1 Dec 7 23:24:36 gdOv kernel: [22845.118807] ll header: 00000000: 00 30 4f 47 37 17 2c 95 7f 8b 44 87 08 00 .0OG7.,...N...
Regards! -- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr
miroR
commented
6 years ago I have stressed the system, this clone that I use for online, without sparing it since my last night's post. E.g. FFmpeg, which by default runs with all processing power, has been on since I went to sleep very early, minutes into this day (UTC), and it's still churning on videos. Will be lots of garbage videos to clean, because I recorded mostly indiscriminately, to record a lot for testing purposes.
And also mencoder was recording on Hauppauge HVR3000 composite input all the time (lot of garbage, indiscriminately).
And so was tzap (same note). I promised I would post the scripts:
$ cat /usr/local/bin/tzap-cat-g0.sh
#!/bin/bash
#
# This script is run e.g.:
# tzap-cat.sh "Nova TV" Nova
# as normal user.
# Run this in a dir where you have all the perms, and where you record your channels.
# Can only be (other that this script with tzap in its name) one tzap running:
ps aux | grep -v tzap-cat | grep [t]zap | awk '{ print $2 }' > tzap.pid
echo cat tzap.pid
cat tzap.pid
#read FAKE
# and likely cat you mostly use to temporary stuff, such as quick look at text
# files, else getting the right pid of cat may be problematic:
ps aux | grep -v tzap-cat | grep [c]at | awk '{ print $2 }' > cat.pid
echo cat cat.pid
cat cat.pid
#read FAKE
# (The above may not be the best way to do it, but is the way that I know.)
tzap_pid=$(cat tzap.pid)
kill $tzap_pid
echo cat tzap.pid
cat tzap.pid
#read FAKE
cat_pid=$(cat cat.pid)
kill $cat_pid
echo cat cat.pid
cat cat.pid
#read FAKE
echo "Next Enter tzaps the $0 $1 $2 (one more to cat-record)"
#read FAKE
# Change this if your adapter is not the second as below, and also not dvr1 but
# dvr0 (whatever dvr stand for; digital video record ?). The case below is such
# because my old Hauppauge HVR-3000 is the second card, and the -d1 is for the
# DVB-T (DVB-S being at dvr0).
# The $1 must be the name of the channel as in your:
# /home/<you>/.mplayer/channels.conf
tzap -a0 -f1 -d1 -r "$1" & tzap_pid=$!
echo $tzap_pid
echo "Next Enter cat-records the $0 $1 $2"
#read FAKE
# This line above, the the one below are actually not used the next time this
# script is run, getting the pids (this script gets the pids anew instead), to
# maybe kill this tzap/cat session, and start another one, usually on a
# different channel:
echo $tzap_pid > tzap.pid
# and this does the recording (the $2 really could be modified from $1, turning
# ' ' into '_'), but, no time):
ts=$(date +H%m%d_%H%M) #[t]ime[s]tamp
sleep 3 && cat /dev/dvb/adapter0/dvr1 > ${2}_${ts}.m2t & cat_pid=$! And:
$ cat /usr/local/bin/tzap-cat-kill.sh
#!/bin/bash
ps aux | grep -E 'tzap|cat' | awk '{ print $2 }'
echo "hit Enter"
#read FAKE
ps aux | grep -E '[t]zap|[c]at' | awk '{ print $2 }'
echo "hit Enter"
#read FAKE
for i in $(ps aux | grep -E '[t]zap|[c]at' | awk '{ print $2 }'); do
kill -9 $i;
done ;
$Just in case... I don't think anything causing issues to be found in these (primitive) scripts.
And lots of mplayer runs. Lot's of. E.g. with a command line like this:
for i in $(ls -1 *.mkv|sed 's/\.mkv//'|grep Compo); do ls -l $i.avi $i.mkv; midentify $i.avi|egrep 'FILENAME|LENG'; midentify $i.mkv|egrep 'FILENAME|LENG'; echo mplayer -osdlevel 3 -geometry 0:0 -speed 2 $i.avi; read FAKE; mplayer -osdlevel 3 -geometry 0:0 -speed 2 $i.avi; echo mplayer -osdlevel 3 -geometry 200:0 -speed 1 $i.mkv; read FAKE; mplayer -osdlevel 3 -geometry 200:0 -speed 1 $i.mkv; ask; if [ "$?" == 0 ]; then mv -iv $i.mkv OK/ && rm -v $i.avi; read FAKE; fi; done;That script lists every Compo_NNNNNN_NNNN.avi file (where NNNNNN_NNNN can be, say 171208_0659, the timestamp, because I run mencoder on Composite input with:
mencoder tv:// -profile mpeg4_capt_HaupP -o Compo_`date +H%m%d_%H%M`.avi
where I have this config:
$ cat ~/.mplayer/mencoder.conf | grep -A09 '\[mpeg4_capt_HaupP]'
[mpeg4_capt_HaupP]
profile-desc="mpeg4 capture"
tv=input=1:driver=v4l2:device=/dev/video0:normid=3:input=1:alsa=1:adevice=hw.2,0:audiorate=48000:amode=1:width=768:height=576
ovc=lavc=1
lavcopts=vcodec=mpeg4:autoaspect=1:vqscale=4:vb_strategy=1:vmax_b_frames=2:mbd=0:turbo=1
vf=softskip,harddup
mc=0
noskip=1
oac=mp3lame=1
#lameopts=cbr=1:preset=standard
I actually ran strace on:
$ ls -ltr ~/strace.d/tzap-cat-* ~/strace.d/mplayer_171206_1* ~/strace.d/mencoder_17120* | tail -7
-rw-r--r-- 1 mr mr 425198 2017-12-06 17:30 /home/mr/strace.d/mplayer_171206_173001
-rw-r--r-- 1 mr mr 34461 2017-12-06 17:30 /home/mr/strace.d/tzap-cat-g0.sh_171206_173004
-rw-r--r-- 1 mr mr 416603 2017-12-06 17:30 /home/mr/strace.d/mplayer_171206_173011
-rw-r--r-- 1 mr mr 1366221 2017-12-06 17:59 /home/mr/strace.d/mencoder_171206_175909
-rw-r--r-- 1 mr mr 840610 2017-12-06 17:59 /home/mr/strace.d/mencoder_171206_175941
-rw-r--r-- 1 mr mr 76842985 2017-12-06 18:35 /home/mr/strace.d/mencoder_171206_180001
-rw-r--r-- 1 mr mr 71710 2017-12-07 17:10 /home/mr/strace.d/mencoder_171207_171029
I doubt there is anything to be found in there...
Also the old 27.4.0 Pale Moon is on all the time. It crashed, but that was restrected to it only. It's probably just some kind of problem with the addons not behaving as PAX would like:
Dec 8 00:03:13 gdOv kernel: [25162.961621] grsec: (mr:U:/usr/bin/sudo) exec of /usr/bin/sudo (sudo -s kill 8237 8239 8240 ) by /usr/bin/sudo[uncenz-kill:8416] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/local/bin/uncenz-kill[uncenz-kill:8386] uid/euid:1000/1000 gid/egid:1000/1000
Dec 8 00:03:13 gdOv kernel: [25162.976127] grsec: (root:U:/bin/bash) exec of /bin/bash (/bin/bash -c kill 8237 8239 8240 ) by /bin/bash[sudo:8417] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/sudo[sudo:8416] uid/euid:0/0 gid/egid:0/0
Dec 8 00:07:54 gdOv kernel: [25443.915858] PAX: execution attempt in: <stack>, 38aa8d43000-38aa8d68000 3fffffda000
Dec 8 00:07:54 gdOv kernel: [25443.915867] PAX: terminating task: /usr/lib/palemoon/palemoon(palemoon):8266, uid/euid: 1000/1000, PC: 0000038aa8d61a20, SP: 0000038aa8d60418
Dec 8 00:07:54 gdOv kernel: [25443.915875] PAX: bytes at PC: b8 78 b3 b2 5c 03 00 00 00 1a d6 a8 8a 03 00 00 00 00 00 00
Dec 8 00:07:54 gdOv kernel: [25443.915885]
Dec 8 00:07:54 gdOv kernel: [25443.915886] PAX: bytes at SP-8: 0000035cdf946c85 0000035cdf94c8a8 0000035cb2b378d0 0000038aa8d60c08 0000035ca931a128 0000038aa8d60850 0000035cb2b378d0 0000038aa8d604d0 0000038aa8d60510 0000000000000083 0000035cd1ce7600
Dec 8 00:07:54 gdOv kernel: [25443.915892]
Dec 8 00:07:54 gdOv kernel: [25443.916286] grsec: (mr:U:/usr/lib/palemoon/palemoon) denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/lib/palemoon/palemoon[palemoon:8266] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:3537] uid/euid:1000/1000 gid/egid:1000/1000
On the standard input (because in my lean OpenBox, I start programs from xterm, I had:
mr@gdOv:~$ 1512691451901 addons.update-checker WARN Request for https://addons.palemoon.org/integration/addon-manager/internal/update?reqVersion=2&id=uBlock0@raymondhill.net&version=1.13.0&maxAppVersion=27.*&status=userDisabled&appID={8de7fcbb-c55c-4fbe-bfc5-fc555c87dbc4}&appVersion=27.4.0&appOS=Linux&appABI=x86_64-gcc3&locale=en-US¤tAppVersion=27.4.0&updateType=112&compatMode=normal timed out
1512691451918 addons.update-checker WARN Request for https://addons.palemoon.org/integration/addon-manager/internal/update?reqVersion=2&id=uMatrix@raymondhill.net&version=1.0.1b1&maxAppVersion=27.*&status=userDisabled&appID={8de7fcbb-c55c-4fbe-bfc5-fc555c87dbc4}&appVersion=27.4.0&appOS=Linux&appABI=x86_64-gcc3&locale=en-US¤tAppVersion=27.4.0&updateType=112&compatMode=normal timed out
1512691451930 addons.update-checker WARN Request for https://addons.palemoon.org/integration/addon-manager/internal/update?reqVersion=2&id={73a6fe31-595d-460b-a920-fcc0f8843232}&version=5.0.5&maxAppVersion=*&status=userDisabled&appID={8de7fcbb-c55c-4fbe-bfc5-fc555c87dbc4}&appVersion=27.4.0&appOS=Linux&appABI=x86_64-gcc3&locale=en-US¤tAppVersion=27.4.0&updateType=112&compatMode=normal timed out
1512691451935 addons.update-checker WARN Request for https://addons.palemoon.org/integration/addon-manager/internal/update?reqVersion=2&id={972ce4c6-7e08-4474-a285-3208198ce6fd}&version=27.4.0&maxAppVersion=27.4.0&status=userEnabled&appID={8de7fcbb-c55c-4fbe-bfc5-fc555c87dbc4}&appVersion=27.4.0&appOS=Linux&appABI=x86_64-gcc3&locale=en-US¤tAppVersion=27.4.0&updateType=112&compatMode=normal timed out
[1]+ Killed palemoon
mr@gdOv:~$
Otherwise there have been no (other) issues, well no bad issues as for days on end earlier, no real issues whatsoever anymore now!
$ uname -a
Linux gdOv 4.9.67-unofficial+grsec171207-14 #1 SMP Thu Dec 7 15:15:37 UTC 2017 x86_64 GNU/Linux
But I think maybe I found one other reason for the (earlier) crashes.
Tor was running all the time when the crashes were happening, all these weeks. It's the Devuan/Debian Tor that runs as a "daemon", managed by (Devuan maintained) OpenRC in my boxen, and started by the init service (old sysvinit here; BTW, my system is a no-dbus system, I don't trust it, so I don't install it).
I decided it was time to try and disable Tor.
This is the state since, IIRC yesterday around yesterday morning plus minus a couple of hours (but my recollection is not always correct):
# /etc/init.d/tor status
[FAIL] tor is not running ... failed!
#
Because I had noticed earlier --only it takes time getting into my understanding properly-- these lines in my:
Dec 07 17:04:57.000 [notice] Tor 0.2.9.12 (git-2b1e823d7bc05a37) opening log file.
Dec 07 17:04:57.586 [warn] OpenSSL version from headers does not match the version we're running with. If you get weird crashes, that might be why. (Compiled with 1010006f: OpenSSL 1.1.0f 25 May 2017; running with 1010007f: OpenSSL 1.1.0g 2 Nov 2017).
Dec 07 17:04:57.612 [notice] Tor 0.2.9.12 (git-2b1e823d7bc05a37) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0g and Zlib 1.2.8.
Pls. notice "weird crashes, that might be why".
Could that have to do with these crashes in the six issues that I have reported recently? If, so more info needed.
More info needed if so, and for more I think it would be good to try and ask some Tor developers about this. And I'll try and contact some on them. Just give me a little more time.
And, if I have no more crashes, I now have nothing to reproduce... I will compile and actually try and keep regularly compiling latest vanilla kernels --is it really not the 4.9 equivalent of the grsec-unoff patched kernels that I compile, rather than the latest kernel from kernel.org like 4.14.x ?
That's it for now, waiting for more suggestions/advice/directions/clarifications/questions!
miroR
commented
6 years ago confirmation/information on tor failure with weird crashes due to "OpenSSL version from headers does not match" https://trac.torproject.org/projects/tor/ticket/24564
Still no crashes... I think I should enable Tor, and if the crashes are back --but won't be taking to many of them to declare this issue, actually these issues, solved-- than that's it.
And if that's it, I hope Tor devs give use more clue...
miroR
commented
6 years ago This is beyond me completely. Tor is enabled:
# /etc/init.d/tor status
[ ok ] tor is running.
#And yet, browsing with tor-browser, and apt-get update/upgrade 'ing via tor+https went as smooth as I never expected.
And no crashes whatsoever (other than having to use safe-mode with Pale Moon, else it crashes along the lines I explained above, w/o bringing any harm to the system).
I don't know what those crashes were caused with. I will try and strain my system tonight like I made it work hard last night and with those same programs as I explained above, and... maybe we'll know more...
Regards!
theLOICofFRANCE
commented
6 years ago Pale-Moon seems to me less sure than Firefox. If you want a secure browser, compile firefox by disabling JIT (which will reduce javascript performance) so that it is compatible with PAX_MPROTECT.
Can we deduce from this that your problem is due to your use/environment and that it is solved?
miroR
commented
6 years ago HacKurx wrote:
Can we deduce from this that your problem is due to your use/environment and that it is solved?
If you or @minipli feel like, you can close all my reports as solved, I won't object. But, if by my problem you mean this issue #20 , the 5 months old palemoon build of mine:
# apt-cache policy palemoon
palemoon:
Installed: 27.4.0~repack-2
Candidate: 27.4.0~repack-2
Version table:
*** 27.4.0~repack-2 100
100 /var/lib/dpkg/status
#is not something that can be the cause of it, I think. That's homebrew Pale Moon I built, hopelessly old, for lack of time to update it. But I don't see that it crashes the system though. [1]
But don't these issues indicate the possibility of something sinister --outside of the programming errors, instead above them in a way, or on the sides such as the now somewhat known out-of-band methods that Google the world's top commercial spy agency first introduced, or the ME/PSP of Intel and AMD respectively (the latter is my system's), being it that no one else has had any of them?
I bet there are people who could tell what these crashes really are, how they were instigated, but those won't speak from their shadows. But those are my suspicions only.
Speaking of which, I think I'll update this page of mine with the few links there are currently missing there: From SPDY to Hauppauge Card Firmware Issues. It may well be unproveable, but I do know those things that only people from that shadowy world can do --they're either too hard, or no such expensive resources are there, that just a lone hacker could do those -- [I do know those things] happened to me.
And the above I don't think is unrelated.
What I am sad about it that unsolved (well these are actually unsolved, but feel free to close them) bugs damage the perception of grsecunoff, which I continue to put my hopes in, given that spender and PaX Team left following the ripoff by Google, as spender wrote, grsecunoff.
I don't see any other complete solution for Linux security. And...
And I still think the management of these crashes in these issues #13, #17, #18, #19, #20, #21 --or in most of them-- are sooner protection by grsecunoff of my system, than grsecunoff being at fault. But it would take so much more than my insufficient knowledge to prove that...
...
[1] And to be to the point, this is current trace, as I'm posting this with my Pale Moon:
-rw-r--r-- 1 tcpdump tcpdump 9937788 2017-12-15 14:46 dump_171215_1404_gdO.pcap
It says that I've been 42 minutes online. I did start Palemoon a couple of minutes, 2-3 or so, after I connected. But it hasn't crashed this time... (However I'm online after I have Air-Gapped built my system and am useing this clone of it for online.
minipli
commented
6 years ago The instruction pointer in the initial kernel log looks odd -- it's 0xffffc9000c6ffb80 which is 16 bytes above the current stack pointer. This would imply there was some kind of jmp *16(%rsp) instruction, which is unlikely.
Do you have CONFIG_PAX_RAP enabled? And, if so, what's the version of your gcc and binutils? Can you provide the objdump of the failing function, likely ttm_bo_cleanup_memtype_use()?
To answer those questions you could do the following:
$ cd /path/to/your/kernel/tree/
$ grep PAX_RAP .config
$ gcc --version | head -1
$ objdump --version | head -1
$ dis-func.sh ttm_bo_cleanup_memtype_use vmlinuxThe dis-func.sh script can be found here. It's just a wrapper around objdump and a perl oneliner.
miroR
commented
6 years ago $ cd /path/to/your/kernel $ grep PAX_RAP .config
Well, the all-modules-any-system kernel that I will soon upload for anybody wishing to try and reproduce any of my issues, c'mon try somebody, I congratulate anybody who can (well maybe only the mencoder Call Trace is doable to reproduce, but it too I suspect may still have been in some of the traces I presented here triggered from the network)... [that I will soon upload] to:
https://www.croatiafidelis.hr/gnu/deb/linux-deb-grsec-current/
(I was saying) [the all-modules-any system]:
$ grep PAX_RAP /boot/config-4.9.72-unofficial+grsec171228-16
$
had no PAX_RAP option set.
But the all-in-kernel-compiled, with only what my system needs, that of course I can't upload for others:
$ grep PAX_RAP /boot/config-4.9.70-unofficial+grsec171220-17
CONFIG_PAX_RAP=y
CONFIG_PAX_RAP_VERBOSE=y
$And:
$ gcc --version | head -1
gcc (Debian 7.2.0-18) 7.2.0
$ objdump --version | head -1
GNU objdump (GNU Binutils for Debian) 2.29.1
$but:
root@gdOv:/path/to/linux-4.9.72# dis-func.sh ttm_bo_cleanup_memtype_use vmlinux
root@gdOv:/path/to/linux-4.9.72# ls -l vmlinux
-rwxr-xr-x 1 mr mr 173913488 2017-12-28 19:19 vmlinux
root@gdOv:/path/to/linux-4.9.72# Dec 29 04:36:51 gdOv kernel: [253415.157880] grsec: (admin:S:/) chdir to /Cmn/src/linux-4.9.72 by /bin/bash[bash:3627] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/sudo[sudo:3626] uid/euid:0/0 gid/egid:0/0
Dec 29 04:36:53 gdOv kernel: [253417.504541] grsec: (admin:S:/) exec of /usr/local/bin/dis-func.sh (dis-func.sh ttm_bo_cleanup_memtype_use vmlinux ) by /usr/local/bin/dis-func.sh[bash:22351] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3627] uid/euid:0/0 gid/egid:0/0
Dec 29 04:36:53 gdOv kernel: [253417.507819] grsec: (admin:S:/) exec of /usr/bin/x86_64-linux-gnu-objdump (objdump -d vmlinux ) by /usr/bin/x86_64-linux-gnu-objdump[dis-func.sh:22352] uid/euid:0/0 gid/egid:0/0, parent /usr/local/bin/dis-func.sh[dis-func.sh:22351] uid/euid:0/0 gid/egid:0/0
Dec 29 04:36:53 gdOv kernel: [253417.511644] grsec: (admin:S:/) exec of /usr/bin/perl (perl -e undef $/; $_=<>; /(^.*<$ENV{FUNC}>:\n(^[ \t].+\n)*)/m && print "$1" ) by /usr/bin/perl[dis-func.sh:22353] uid/euid:0/0 gid/egid:0/0, parent /usr/local/bin/dis-func.sh[dis-func.sh:22351] uid/euid:0/0 gid/egid:0/0Fri 29 Dec 06:56:07 UTC 2017It's still at:
top - 06:54:52 up 3 days, 41 min, 18 users, load average: 1.00, 1.01, 1.00
Tasks: 266 total, 2 running, 262 sleeping, 2 stopped, 0 zombie
%Cpu0 : 100.0/0.0 100[ ]
%Cpu1 : 0.0/0.0 0[ ]
%Cpu2 : 0.3/1.0 1[ ]
%Cpu3 : 3.7/1.7 5[ ]
KiB Mem : 12.3/16386252 [ ]
KiB Swap: 0.1/8997948 [ ]
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22353 root 20 0 491156 477856 3932 R 100.0 2.9 137:33.95 perl
30351 mr 20 0 955552 215284 44132 S 3.3 1.3 2:20.47 palemoon
3392 root 20 0 422452 63816 7768 S 2.6 0.4 15:04.11 Xorg
3651 root 20 0 25944 2512 1852 R 0.7 0.0 32:45.48 top and the prompt is not returning:
root@gdOv:/path/to/linux-4.9.72# dis-func.sh ttm_bo_cleanup_memtype_use vmlinux(that's the only-my-hardware-no-separate-modules kernel)
miroR
commented
6 years ago Dec 29 08:31:02 gdOv kernel: [267466.635713] grsec: exec of /sbin/grlearn (/sbin/grlearn -stop ) by /sbin/grlearn[gradm:23292] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0
Dec 29 08:31:06 gdOv kernel: [267471.017523] grsec: exec of /usr/local/bin/dis-func.sh (dis-func.sh ttm_bo_cleanup_memtype_use vmlinux ) by /usr/local/bin/dis-func.sh[bash:23293] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:3627] uid/euid:0/0 gid/egid:0/0
Dec 29 08:31:06 gdOv kernel: [267471.020644] grsec: exec of /usr/bin/x86_64-linux-gnu-objdump (objdump -d vmlinux ) by /usr/bin/x86_64-linux-gnu-objdump[dis-func.sh:23294] uid/euid:0/0 gid/egid:0/0, parent /usr/local/bin/dis-func.sh[dis-func.sh:23293] uid/euid:0/0 gid/egid:0/0
Dec 29 08:31:06 gdOv kernel: [267471.020921] grsec: exec of /usr/bin/perl (perl -e undef $/; $_=<>; /(^.*<$ENV{FUNC}>:\n(^[ \t].+\n)*)/m && print "$1" ) by /usr/bin/perl[dis-func.sh:23295] uid/euid:0/0 gid/egid:0/0, parent /usr/local/bin/dis-func.sh[dis-func.sh:23293] uid/euid:0/0 gid/egid:0/0
I waited for some 20 minutes on this one without command prompt having returned. Rebooted into vanilla kernel:
# uname -r
4.14.4171209-12
# Now:
# ps aux | grep dis-func.sh
root 3578 0.0 0.0 4296 744 pts/13 S+ 09:00 0:00 /bin/sh /usr/local/bin/dis-func.sh ttm_bo_cleanup_memtype_use vmlinux
root 3599 0.0 0.0 12804 968 pts/12 R+ 09:04 0:00 grep dis-func.sh
#Such long work this script got to do, or something wrong?
# date
Fri 29 Dec 09:10:49 UTC 2017Yeah, the script shouldn't take that long :/
Anyways, I assumed the panic was from a non-modular kernel, but now I'm not certain any more. You seem to change kernels frequently. Oh well, could you please try the following instead and post the output?:
objdump -wdr drivers/gpu/drm/ttm/ttm_bo.oYeah, the script shouldn't take that long :/
Oh, well, the verbosity or lack of it, which is better, I sometimes ask myself...
Anyways, I assumed the panic was from a non-modular kernel, but now I'm not certain any more. You seem to change kernels frequently.
No, I don't. I use only two sets of kernels, one is no-modules-loading my own hardware only, for my regular use, and the other is what I offer to others, which has all the modules as any general-purpose kernel, compiled separately, and I offer them at https://www.croatiafidelis.hr/gnu/deb/linux-deb-grsec-current/ and have dedicated topics at: https://dev1galaxy.org/viewtopic.php?id=596 and http://forums.debian.net/viewtopic.php?f=16&t=108616 along with script https://github.com/miroR/grsec-dev1-compile for newbies how to compile such kernels themselves, but surely for complete newbies only the packages are feasible to install, so I offer those in the link further above in this post... Both those sets are only sets because the version changes 4.9.72 being current --yet to upload, but already being tested as I write--, and all are based on @minipli's kernel, because you're some of us' last hope. Us who don't trust vanilla, not to say more...
Oh well, could you please try the following instead and post the output?:
objdump -wdr drivers/gpu/drm/ttm/ttm_bo.oSure!
miroR
commented
6 years ago Wow! That's 360k ... I think I'd better upload it. Temporarily (but no rush to remove it), but that takes me longer than posting here, because I'll upload the:
$ uname -r
4.9.72-unofficial+grsec171228-16
$that I compiled yesterday, in the same session, [temporarily] I'll post it in: where I upload the deb packages, it will keep the name:
$ ls -ABRgo /Cmn/mr/objdump-wdr_171229_103951_drivers_gpu_drm_ttm_ttm_bo_o
-rw-r--r-- 1 367786 2017-12-29 10:37 /Cmn/mr/objdump-wdr_171229_103951_drivers_gpu_drm_ttm_ttm_bo_oGive me a little time now to do it... (and I hope crashes won't make it longer and worse...)
miroR
commented
6 years ago minipli
commented
6 years ago The objdump looks good. However, I probably need the following files, too -- depending on which one you're using:
Have you been able to reproduce the panic with .72?
miroR
commented
6 years ago The objdump looks good. However, I probably need the following files, too -- depending on which one you're using:
drivers/gpu/drm/amd/amdgpu/amdgpu.o and/or
drivers/gpu/drm/nouveau/nouveau.oWill do it. A little time I need.
Have you been able to reproduce the panic with .72?
Hey, it's not in the world typical, what happens here, for programming errors, such as would be the case if your patch contained programming errors. It just wouldn't be this erratic, or at least it is not typical for programs with errors to so often and so much be so very erratic...
Namely I occasionally have no Call Traces whatsoever for even approx. 4-5 days (didn't count), and then I can't stop having them... But that was earlier, as I posted about it (or gave links, in the verbose reports of mine in the past weeks). It hasn't repeated such absolutely worse kind of condition lately... I'm not saying it won't, but that it, likely, depends on the attacker, in my theory at least.
I have had one rsyslog-recorded trace with 4.9.70 on Dec 27, and two or three not-recorded in the syslog on Dec 29, but none so far with 4.9.72 all-modules-any-system that I uploaded for the world, nor with 4.9.72 no-modules-loading only-my-hardware that I'm running now.
I can post the 4.9.70 trace and explain when at least one of the not recorded crashes happened, but in a few hours. And I'll take care to post it in the proper old or new that it should be, issue, as best I will know.
miroR
commented
6 years ago The objdump looks good. However, I probably need the following files, too [...cut...]: drivers/gpu/drm/amd/amdgpu/amdgpu.o
Uploaded: https://www.croatiafidelis.hr/gnu/deb/objdump-wdr_171229_200531_drivers_gpu_amd_amdgpu_amdgpu_o.gz https://www.croatiafidelis.hr/gnu/deb/objdump-wdr_171229_200531_drivers_gpu_amd_amdgpu_amdgpu_o.sig