Re: Debian LTS
Last week I switched another one of my computers from Debian to Hardened Gentoo.
808 publicly visible posts • joined 1 Aug 2008
Let me provide an analogy. You know, xpdf frequently had code execution vulnerabilities found in it and ultimately was removed from Gentoo in 2014 when another one resurfaced and became the last straw:
https://security.gentoo.org/glsa/201402-17
"Description: Multiple vulnerabilities have been discovered in Xpdf. Please review the CVE identifiers referenced below for details.
Resolution: Gentoo has discontinued support for Xpdf. We recommend that users unmerge Xpdf: # emerge --unmerge "app-text/xpdf"
After that, there's no more xpdf in Gentoo. They use mupfd instead. I hope systemd meets the same fate, the sooner the better. Flushing toilet water icon, please.
Partition table is usually restored by looking for 55 AA at end of sectors. In good old days you would only look at cylinder boundaries and cylinder boundaries + 63 sectors, that was damn fast. Now that fdisk et al operate in non-DOS-compatible mode by default, the process takes much longer.
Not necessarily. Guys who run performance benchmarks at Tom's Hardware Guide once noticed that newest Intel Pentium III 1333MHz (or was it 1133MHz?) consistently crashed at Linux kernel compilation test.
Found it on Wikipedia: "A 1.13 GHz version was released in mid-2000 but famously recalled after a collaboration between HardOCP and Tom's Hardware[3] discovered various instabilities with the operation of the new CPU speed grade."
http://www.tomshardware.com/reviews/intel-admits-problems-pentium-iii-1,235-3.html:
"When I was testing the Pentium III 1.13 GHz I was also using a GNU/Linux installation to run kernel compilation benchmarks. I had introduced this benchmark in our processor-benchmarking suite only recently and was therefore not too experienced with this operating system. What I knew for sure however was that my Pentium III 1.13 GHz hadn't been able to finish the compilation even once."
I've set pin 1001 for jessie versions and rolling back my partially upgraded system back to jessie. After the downgrade is finished, I'm switching to Devuan by following the https://devuan.org/os/documentation/dev1fanboy/Upgrade-to-Devuan guide.
I used to be a co-maintainer of some Debian packages in the past (won't disclose which ones in order to remain anonymous), but now I'm done with this distro even as a user, what a shame. It was a good time, though...
"Previous versions of the smartmontools package included a tool update-smart-drivedb which downloaded updated drive definitions from the smartmontools website and stored them at /var/lib/smartmontools/drivedb/drivedb.h"
"This tool did not download the definitions in a secure manner and so the feature has been removed in this version. Future drive DB updates will be propagated via normal Debian package updates, including backports."
Ha-ha-ha. The hot water pipe did not deliver hot water in a secure manner and has been disconnected. In the future water will be delivered pre-heated and packaged in 19 liter bottles via normal FedEx channels.
"Among the most significant, X.Org no longer needs root privileges to run the display server. That eliminates an entire class of attacks that work by going after privilege escalation via X.Org. However, to run X.Org as non-root you'll need to install logind and libpam-systemd and use GDM 3 for your login tool since only GDM 3 supports running it without root privileges."
This is interesting indeed and I'd like to see this in action. Unfortunately, all me Debian setups have systemd (and libpam-systemd and libsystemd0 and policykit* and libpolkit-* etc and so on) purged, so I doubt I'll ever witness this on real hardware, maybe on VM some other time.
BTW, running X without full root privileges should be possible if you remove suid/sgid from /usr/bin/X and use 'setcap' on it instead. Judging from my RBAC policy for /usr/bin/Xorg subject, CAP_IPC_OWNER, CAP_WAKE_ALARM and CAP_SYS_RAWIO should be sufficient for Xorg with "VESA" driver and CAP_IPC_OWNER, CAP_WAKE_ALARM and CAP_SYS_ADMIN should work for Xorg with "intel" one.
If you want to harden your appliances, you should use hardened Gentoo instead (but it will take a pair of months or more to properly set up grsecurity RBAC).
By the way, enabling RBAC early in the boot process is _not_ recommended. If you read default /etc/grsec/learn_config file, you'll notice this:
# the below lines are for catching the occasional use of init.d scripts at runtime
# comment them out if you are starting learning before services are started by init
# (a highly non-recommended choice)
inherit-learn /etc/init.d
inherit-learn /etc/rc.d/init.d
firefox should be run in separate chroot on separate FS IMO.
I run it on hardened Gentoo under strict RBAC policy subject with all .so and other files it uses written explicitly in the subject and everything else hidden. On the first run it requires stat() access to /home/username directory, but it can and must be hidden from firefox afterwards (because firefox installs inotify() watch on it and you'd be surprised by grsec alerts like "grsec: (username:U:/usr/lib/firefox/firefox) denied access to hidden file /home/username/.viminfz.tmp by /usr/lib/firefox/firefox[gmain:1234]" each time you edit something or modify files in your home directory). What I do in my home directory and names of files I work with are none of firefox'es fucking business.
The most valid statement comes on the 3rd page of comments... "Devs", they say. +2.4 years to experience. +8.6% to salary, blah blah blah. When you join a dev project, you accept an already established indentation style, and for Makefiles there are no alternatives to tabs at all. So what? If you can't set et/noet, sw, ts and tw or their analogues for your favourite editor on a per-file basis, you have no place in this industry at all IMNSHO. Modelines have been there for tens of years, FFS.
systemd
-free Devuan hits stable 1.0.0 status
Firewall is a separate task and it must be provided by a separate package thus. Tea at 5 o'clock is also part of standard routine, why don't you include it in systemd too? Take job from cron (and anacron) and reimplement their functions in a "more efficient way" with bells and whistles added? In an effort to standardize configuration, yeah?
I'm already running Debian without systemd BTW (approx. for a year or even more), but I'll switch all my computers to either a hardened Gentoo or to Devuan if Debian doesn't root the fucking systemd out soon. And I'm already running the said Gentoo on one notebook, and while it was a fucking hell to install I'm starting to like it.
Jeremy, are you one of SAMBA devs? Loading plugins must be
1. restricted to a known list of "trusted" plugins
2. list of trusted plugins must be configurable by server admin
3. list of trusted plugins must be empty by default
4. libraries must only be loaded from trusted paths /usr/lib and /lib
5. user input must never get into parameters of dlopen() or into "trusted" plugins or paths lists
6. user input should never get into parameters of execve(), too long to explain in details here