You are not logged in.
Hi Chris,
Thank you for your suggestions. My plan is to move those directories immediately after installation, while the system is offline, so the risk of malware ever being able to write to those directories should be very, very small.
I was just digging around in my home directory and noticed that some software puts executable files in there, which is something that I'm not a fan of. I like to put home on a separate partition that is marked "nosuid, noexec" in the fstab file. Obviously, this will cause problems for executable files that are in my home directory.
So far, these are the places where I've found executable files:
~/bin
~/.local/bin
~/.wineDoes anyone know if there are any others? My original plan was to move these to a directory on the root (system) partition and replace the originals with symbolic links. I'll probably do that if I can depend on executable files to only be present in a few, predictable locations in my home directory.
By the way, the reason for doing this is that I have a personal security policy, and part of that policy is that "threat gate" applications like web browsers, email clients, etc., should not have write access to any file system where files can be executed. That way, if any malicious code (e.g., a malware "dropper") is written to disk, that code will not be allowed to execute.
PS: One tips, reboot on oldier kernel…
(if available)
This works. I had the same problem on Beowulf because I use a kernel from backports. After spending a lot of time trying to repair Windows 8.1, I began to suspect that the problem is not in the guest but on the host. I decided to try rebooting with the previous kernel, and when I did the problem was gone.
I don't really understand the essence of this distribution. After all, you can always install a minimal system and then install what you need.
Although that is technically true, many people are not willing or able to do that. They may lack the necessary experience required, or they may be lazy, impatient, etc.
I could put the fix in a postinstall script in the next version, but I think the user should be warned and asked to OK it.
I don't think that's really necessary. On a live system it doesn't make sense to have anacron running. However, once the system has been installed, having anacron running is the normal and expected behavior. IMO, asking the user to OK the fix is asking for trouble since some users will likely be confused by this.
I recently started looking for guides on how to harden GNU/Linux systems. This is the best one that I've found so far:
I recommend giving FireHOL a try. It uses a simple, human-readable configuration file.
Package name: firehol
More info:
https://firehol.org/
https://packages.debian.org/stable/firehol
For most desktop and laptop computers, the default configuration should be sufficient. For a server you would need to configure the firewall according to the services that are running on it.
non-free: propriatary stuff - you want to enable this when you need firmware for your hardware to work
Most people probably will need to enable non-free in order to install one of these packages:
amd64-microcode
intel-microcode
I have LibreOffice installed and a search for "log4j" found nothing. However, I am selective about what I install and don't allow software to install recommended packages by default. It looks like I installed LibreOffice Writer and then later installed LibreOffice Math. Those are the only parts of LibreOffice that I installed because I really don't have a need for the rest of it. Because of LibreOffice's bloat, I've long preferred to use AbiWord and Gnumeric instead.
My result:
$ apt list | grep installed | grep java
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
javascript-common/oldstable,now 11 all [installed,automatic]
libjavascriptcoregtk-4.0-18/oldstable-security,now 2.34.6-1~deb10u1 amd64 [installed,automatic]Here's another option worth considering:
https://portableapps.com/apps/office/li … legacy-5.4
I sometimes use that in a Windows XP VM.
@OP: can we see the full output of
# apt update
From yesterday (I still had the terminal window open):
# apt update
Hit:1 http://iweb.dl.sourceforge.net/project/ubuntuzilla/mozilla/apt all InRelease
Hit:2 http://deb.devuan.org/merged beowulf InRelease
Hit:3 http://deb.devuan.org/merged beowulf-updates InRelease
Get:4 http://deb.devuan.org/merged beowulf-security InRelease [26.5 kB]
Hit:5 http://deb.devuan.org/merged beowulf-backports InRelease
Fetched 26.5 kB in 4s (7,067 B/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.From just a few minutes ago:
# apt update
Hit:1 http://versaweb.dl.sourceforge.net/project/ubuntuzilla/mozilla/apt all InRelease
Get:2 http://deb.devuan.org/merged beowulf InRelease [33.8 kB]
Get:3 http://deb.devuan.org/merged beowulf-updates InRelease [26.7 kB]
Get:4 http://deb.devuan.org/merged beowulf-security InRelease [26.5 kB]
Get:5 http://deb.devuan.org/merged beowulf-backports InRelease [26.9 kB]
Get:6 http://deb.devuan.org/merged beowulf-backports/main amd64 Packages [491 kB]
Fetched 605 kB in 4s (151 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
2 packages can be upgraded. Run 'apt list --upgradable' to see them.# apt list --upgradable
Listing... Done
linux-headers-amd64/oldstable-backports 5.10.92-1~bpo10+1 amd64 [upgradable from: 5.10.70-1~bpo10+1]
linux-image-amd64/oldstable-backports 5.10.92-1~bpo10+1 amd64 [upgradable from: 5.10.70-1~bpo10+1]So, the upgrade was NOT available yesterday, but now it is.
I am using a kernel from backports on Beowulf and just noticed something strange.
$ apt policy linux-image-amd64
linux-image-amd64:
Installed: 5.10.70-1~bpo10+1
Candidate: 5.10.70-1~bpo10+1
Version table:
*** 5.10.70-1~bpo10+1 100
100 http://deb.devuan.org/merged beowulf-backports/main amd64 Packages
100 /var/lib/dpkg/status
4.19+105+deb10u13 500
500 http://deb.devuan.org/merged beowulf/main amd64 Packages
4.19+105+deb10u9 500
500 http://deb.devuan.org/merged beowulf-security/main amd64 PackagesSearching my apt package cache shows that the latest kernel I have is dated 30-October-2021:
$ ls -l /var/cache/apt/archives |grep linux-image-
-rw-r--r-- 1 root root 48399932 Jul 19 2021 linux-image-4.19.0-17-amd64_4.19.194-3_amd64.deb
-rw-r--r-- 1 root root 53423672 Aug 19 2021 linux-image-5.10.0-0.bpo.8-amd64_5.10.46-4~bpo10+1_amd64.deb
-rw-r--r-- 1 root root 53505900 Oct 30 16:58 linux-image-5.10.0-0.bpo.9-amd64_5.10.70-1~bpo10+1_amd64.deb
-rw-r--r-- 1 root root 1504 Aug 19 2021 linux-image-amd64_5.10.46-4~bpo10+1_amd64.debA little research shows that the version I have is the latest version available for download:
Package: linux-image-5.10.0-0.bpo.9-amd64 (5.10.70-1~bpo10+1)
https://packages.debian.org/buster-back … po.9-amd64
However, if you click on the Debian Changelog link on the right-hand side of that page, you'll see this at the top of the page:
linux-signed-amd64 (5.10.92+1~bpo10+1) buster-backports; urgency=medium
* Sign kernel from linux 5.10.92-1~bpo10+1
* Rebuild for buster-backports:
- Change ABI number to 0.bpo.11
-- Ben Hutchings <benh@debian.org> Thu, 03 Feb 2022 19:49:50 +0100February 3, 2022 was over a month ago. What's going on?
This is the approach that I use:
df -hThat shows me my mounted drives. If I see (for example) that /dev/sdb is my "highest" drive, then I'll guess that the USB stick will be /dev/sdc.
Although my guess has usually been correct, I always verify it like this:
# fdisk -l /dev/sdcI then look at the output of fdisk to see if the size of /dev/sdc (and other drive info) matches what I expect. It usually does, but if were to ever see something I wasn't expecting, then I would know to be extra careful before proceeding.
Yeah, it really is impossible to tell what Chrome is doing. It even adds Google's repositories in an install script, which freaks me out.
Speaking of Google Chrome, I just saw this article today:
Google makes the perfect case for why you shouldn't use Chrome
But hey, the big G offers a Chrome .deb that should be compatible with Devuan. The telemetry for that makes FF looks like a paragon of privacy but you know that, right?
If I used it at all, I would only use Google Chrome in a VM. I installed it once on my main system, and noticed some odd behavior after doing so. It might have been a coincidence, but the strange behavior went away after I became suspicious and uninstalled Google Chrome, so I am inclined to believe that Google Chrome was somehow responsible.
I would boot from a live CD/DVD/USB system and use partclone to clone the partitions. I would use Refracta or the Devuan live DVD and install partclone using apt. Alternatively, you could use the GParted live CD, which comes with partclone. However, the GParted live CD seems a little rough around the edges, and is based on Debian Sid, so I'd recommend that you not use it.
Download links for Devuan:
https://www.devuan.org/get-devuan
Download links for Refracta:
https://get.refracta.org/
Info about the GParted live CD:
https://gparted.org/livecd.php
Download links for the GParted live CD:
https://sourceforge.net/projects/gparte … ve-stable/
That worked. Thanks for the prompt reply!
Unless I did something wrong, it looks like your key has expired.
$ gpg --verify SHA256SUMS.txt.asc SHA256SUMS.txt
gpg: Signature made Tue 16 Nov 2021 09:35:28 AM EST
gpg: using RSA key 67F5013216271E85C251E480A73823D3094C5620
gpg: Good signature from "fsmithred (aka fsr) <fsmithred@g***l.com>" [expired]
gpg: Note: This key has expired!
Primary key fingerprint: 67F5 0132 1627 1E85 C251 E480 A738 23D3 094C 5620https://www.gnu.org/software/grub/manua … figuration
It is disabled by default since automatic and silent execution of os-prober, and creating boot entries based on that data, is a potential attack vector.
It seems to me that there's a simple solution that will solve this problem -- ask the user to confirm that the information obtained from os-prober is correct. Or write the info to the appropriate config file, but commented out, along with a comment above it explaining why it's commented out and the importance of verifying that the information is correct before uncommenting it.
The only systems that are using version 2.06 are Devuan Ceres and Debian Sid. Everything else is using a lower version number (for now). So, it shouldn't affect you as far as I can tell.
Thank-you. I need to upgrade that system soon, and having the multi-boot menu break is a problem that I don't need.
My experience is that os-prober never worked on efi systems. Valid for Stretch/ASCII, Buster/Beowulf, Bullseye/Chimaera.
What about a Jessie system that was upgraded to Stretch? Would the upgrade remove the working multi-boot menu?
Have you tried the latest one from the virtual box repository or was that the one that locked up?
No, not yet. I am reluctant to do so since I don't have much hope that it will work, and since what I have now is working, I really don't want to mess with it. I probably won't try it until after I upgrade to Chimaera.
My experience has been that VirtualBox 6.1 is messed up and doesn't work right on Beowulf. I had VMs completely lock up, multiple times. The latest version that has been working reliably for me is 6.1.22 r144080 (Qt5.6.1). And in case it matters, I am also using a kernel (and headers) from backports (on the host system). Hopefully this problem will disappear when I upgrade to Chimaera.
Just thought I'd pass along this information in case it's helpful.
Debian does not supply Chrome, and they never will. But I do agree that the chomium package in the repositories is in a pretty poor state. Google don't provide an LTS version (unlike Mozilla) and Debian just can't keep up with the steady stream of vulnerabilities:
https://security-tracker.debian.org/tra … e/chromium
So the chromium package is outdated and riddled with potential security holes. Not good.
When I want a Chromium-based web browser, I install Vivaldi:
The first time I installed it, the UI was kind of weird, and it wasn't long before I uninstalled it. However, I gave Vivaldi a second chance later on, and they had clearly improved it a lot.
I believe that MX Linux has Iridium (package name: iridium-browser). I no longer have any packages from MX Linux installed, but I did in the past. The tricky part was setting up the apt-pinning so that only the packages I wanted from MX Linux were installed, and nothing else.
If a package is marked obsolete then it has already been removed from the repositories[1].
That's a pity, because I have run into cases where GRUB did not work, or refused to install, but LILO installed and worked just fine. I'd rather use GRUB, but it's nice to have an alternative to fall back on when needed.
Note: It appears that LILO is still in Sid.