Hi! I've recently decided how for my machines Ceres (instead of Ascii, which in its turn long ago supplanted Jessie) was the best choice, and I don't regret it.
Because I would believe that the lack of stability (mostly) isn't causing the very diversified Oopses that I've been getting in this recent period. In fact, of Oopses and Call Traces I have almost become a kind of collactionnaire for a while. Have a look at the recent issues at: https://github.com/minipli/linux-unofficial_grsec/issues/ where I have authored issues 19, 18, 17 and 13. Not the lack of stability might be the cause of issues like those. Instead, the knownness of the old packages by exploit users might be the cause. That claim I make because earlier I wouldn't be able to solve similar issues. Not in Ascii (nor probably would I be able to do so in Jessie). Rather, such collection of Oopses that I've been able to put together in the two passed weeks, I wouldn't have been able to be put together with Ascii. I had issues in Ascii, but almost never, unless the attack would be really noisy, and the story about one noisy attack is coming in the page that I promised in this topic on dev1galaxy: Fighting persistent intrusionals in Devuan (Devuan wins!) https://dev1galaxy.org/viewtopic.php?id=1703 And that promised page will be (inexistent at the time of this writing): [ the title might feature string like "noisy MiTM attack" ] http://localhost/foss/cap/cap-170929-strange-ssl-conv -- but I couldn't make good on that promise, because these Call Traces came in the meantime, sorry! -- But I was saying, I hardly ever got close to figuring out any sources, in Ascii, of my similar troubles to these that I have documented for Ceres, nor, I guess, would I be able to figure them out if I remained using Jessie. But please, that's my daring guess only. I may very well stand corrected again by people with knowledge certain, and not vague like mine. My feeling as careful, dedicated, unswerving observer of my system's behavior (up to my intellectual might and talent, which are far from unbound, and are indeed often lacking and vague; however, I've often made good guesses in the past on matters), [my feeling] is that Devuan controlled by unofficial+grsecurity or, as Corsac, the years long packager of grsec, proposes in the title of his package # apt-cache policy linux-image-4.9.0-4-grsec-amd64 linux-image-4.9.0-4-grsec-amd64: Installed: (none) Candidate: 4.9.51-1+grsecunoff2 Version table: 4.9.51-1+grsecunoff2 500 500 tor+http://pkgmaster.devuan.org/merged ceres/main amd64 Packages 4.9.51-1+grsecunoff2~bpo9+1 100 100 tor+http://pkgmaster.devuan.org/merged ascii-backports/main amd64 Packages 100 tor+http://pkgmaster.devuan.org/merged testing-backports/main amd64 Packages # --although I don't use, currently, Corsac's packages, I compile instead from the bleeding edge, from minipli's github--, [or as Corsac] suggests in the name of his packages: grsecunoff (which I'd modify to grsec-unoff for legibility), see: https://packages.debian.org/search?keywords=linux-image-4.9.0-4-grsec-amd64 4.9.51-1+grsecunoff2~bpo9+1: amd64 ( I'm sorry I'm not yet familiar enough for finding the same on Devuan web quickly, a quick tip welcome, somebody. ) Anyway, Devuan [Ceres] controled by grsec-unoff kernel feels to me to be pretty strong! Also have a look at: grsec-unoff (RAP) related Call Traces https://www.croatiafidelis.hr/foss/cap/cap-171117-grsec-RAP-Oops/ Lots of issues put into my system as I go online (that's my very strong guess, that the source of those issues is attacks, not programming failures unsolicited, nope!), you can see there on those pages how lots of those intended failures in my Ceres are fended off and solved by grsec-unoff. Yes, solved. Without grsec, those would have been successful attacks, and would (mostly) never have been even logged at all. Thanks, general of all your leutenants for allowing such stinking insecurity into your kernel, you who claim how security bugs are just bugs like any other... They're not... Of course, the former thanks note is cynical, and I don't want to name names. I have done so sufficienly in the past. I only want to enjoy my way more secure kernel, patched with grsec-unoff, than the stock kernel (even with KSPP, but prove to the contrary anybody, pls., prove it, say by making a collection of Call Traces that show attacks thwarted by your KSPP-enhanced kernel). Anyway, please, see in the minipli grsec-unoff issues if I will stand corrected by minipli or others who have real understanding, not vague like me :-) . But I'm (mainly) not writing to brag about my (hopeful) successful defences nor to only lode Ceres. I have one problem which is getting in my way very much. I use grsec features: exec_logging and audit_chdir ( see on: https://www.croatiafidelis.hr/foss/cap/cap-171117-grsec-RAP-Oops/grsec-oops-171118-1030.php about those, pls. ), which have shown to be very useful in many occasions during my years long use of grsec, but which litter the logs very heavily when, as in my case, rsyslog is not controled with proper configuration and filtering. E.g., with rkhunter running it is literally hundreds of lines per second, it's every single binary execution (the rkhunter binary) and chdir logged, which is unmanageable, and thwarts my analysis of my logs by shear sizo of logs that are hard to search. Similarly with updatedb, and with some other binaries. On top of it, those logging often go equally unnecessarily and unmanageably overabundantly, and in exact same fashion, to both /var/log/kern.log and /var/log/messages (and maybe even /var/log/syslog). I'm asking if anybody knows a quick fix for that? In the shape and form of a quick tutorial about rsyslog filtering somewhere, maybe? I learn slowly, and currently have network analysis on my hands to try and figure out the attacks that (likely) caused (at least some of) those Call Traces in the links above, which [network analysis] is also at occasional place close to insurmountable for my level of understanding, I couldn't at this time dedicate days to learning it. --- And a separate issue, I hope that one will be quick, so not making a separate thread on that (but see at end of this "---"-separated group of paragraphs): I've been using fsmithread's Refracta with Openrc and eudev for managing the cloning of my systems and chroot'ing and fixing them, and it's great! But, @fsmithred, is there a quick tip how to switch to eudev? And is this, broadly, a related matter to what I see on my page: https://www.CroatiaFidelis.hr/foss/cap/cap-171117-grsec-RAP-Oops/grsec-oops-171123-1530.php where in the bug you can find the string "systemd-udevd" I mean, if that part of systemd programming is not active in my system, how come it's in that Oops: # apt-cache policy libsystemd-dev libsystemd-dev: Installed: (none) Candidate: 235-3 Version table: 235-3 500 500 tor+http://pkgmaster.devuan.org/merged ceres/main amd64 Packages 234-3~bpo9+1 100 100 tor+http://pkgmaster.devuan.org/merged ascii-backports/main amd64 Packages 100 tor+http://pkgmaster.devuan.org/merged testing-backports/main amd64 Packages 232-25+deb9u1 500 500 tor+http://pkgmaster.devuan.org/merged ascii/main amd64 Packages 500 tor+http://pkgmaster.devuan.org/merged testing/main amd64 Packages # If this would not be a quick issue, pls. split this thread by renaming it to something with eudev in its subject line. --- Thanks for the fine OS, Devuan people! -- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr
signature.asc
Description: PGP signature
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
