SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I see your point, but default Slackware user = root, and to configure another user one must be root first.
With all respect, I do not believe that as a (privileged or not) user of my own computer is my business to cover the security holes in the operating system, but to use it as it is and to apply regularly the security patches published by its author(s).
Last edited by ZhaoLin1457; 11-14-2021 at 04:55 AM.
With all respect, I do not believe that as a (privileged or not) user of my own computer is my business to cover the security holes in the operating system, but to use it as it is and to apply regularly the security patches published by its author(s).
Yes, this is why I said arguably, because certain systems decide all things for the user and companies shipping those systems have a huge infrastructure to support their decisions.
They've got call centers, remote support, automated migrations etc, etc. Slackware has no such thing, you're either root and take care of it yourself, or pay someone to be root.
I don't think there's any other way, Slackware is not a huge corporation which can afford free customer support for everyone, or a closed system like windows which can afford to enforce rules upon their users.
So if you expect things like that from such a small team that is already overworked, I think you're not being realistic.
IPv6 support in cacaserver
fixed a bug from 2004 that caused PDF documentation generation to fail
memory allocation functions are now more robust
numerous fixes for memory leaks and invalid memory accesses:
CVE-2021-30498
CVE-2021-30499
CVE-2021-3410
CVE-2018-20546
CVE-2018-20547
CVE-2018-20545
CVE-2018-20548
CVE-2018-20549
Loving the idea, just hope that it won't take another five+ years until Slackware 16 is released...
Chances are that GRUB will have proper support for recent versions of LUKS and LVM, by then. Currently some distros are stuck with GRUB 1, because of long-standing issues in GRUB 2 regarding LUKS, AFAIK.
gargamel
Actually LUKS is well supported by GRUB2, even LUKS2 with the limitation that in the current version (2.06), only the PBKDF2 key derival function is supported, not yet Argon2i or Argon2id, as per this commit. No need for a separated boot partition or LVM if you put a decryption LUKS key in the initramfs as we do in Slint (re-included in the new iniramfs upon kernel upgrade as we also store it in /etc). In this case only the Bios Boot partition and the ESP are not encrypted, the root partition and an optional additional partition are encrypted (both keys stored in /etc). The BIOS Boot partition is only used by GRUB itself (needed in case of a DOS partition table) and the ESP only contains the GRUB OS loader/manager itself, no kernel and no initramfs so I think that this configuration is safe enough for our use case (machine or drive stolen while the machine is powered off). Indeed all this won't protect a user who keep a running system unattended...
Excuse my ignorance, but in other words, you say that Slackware expects the user to be competent enough to figure out how to close its own huge security hole which is this lack of a firewall?
Yes, including turning off services that they don't need and are enabled at default!
Quote:
I apologize, but then I am incompetent to cover the security holes on a Linux operating system.
I'm not certain that any of these CVEs would be something anyone would run into without trying very hard. But in any case the new libcaca doesn't compile.
I'm not certain that any of these CVEs would be something anyone would run into without trying very hard. But in any case the new libcaca doesn't compile.
I'm not certain that any of these CVEs would be something anyone would run into without trying very hard. But in any case the new libcaca doesn't compile.
Actually LUKS is well supported by GRUB2, even LUKS2 with the limitation that in the current version (2.06), only the PBKDF2 key derival function is supported, not yet Argon2i or Argon2id, as per this commit. No need for a separated boot partition or LVM if you put a decryption LUKS key in the initramfs as we do in Slint (re-included in the new iniramfs upon kernel upgrade as we also store it in /etc). In this case only the Bios Boot partition and the ESP are not encrypted, the root partition and an optional additional partition are encrypted (both keys stored in /etc). The BIOS Boot partition is only used by GRUB itself (needed in case of a DOS partition table) and the ESP only contains the GRUB OS loader/manager itself, no kernel and no initramfs so I think that this configuration is safe enough for our use case (machine or drive stolen while the machine is powered off). Indeed all this won't protect a user who keep a running system unattended...
Thanks for the clarification!
As I understand it, with GRUB (version 1 or 2 or both, I am not sure) it is possible to fully encrypt the whole disk, including /boot. However, the price that I have to pay for doing so in my OpenSUSE system is that I now have to enter the LUKS passphrase twice to boot the system: Once for /boot, and another time for the system partition. Probably it would be possible to put both partitions under LVM control or use a key chain to have the system partition opened automatically after entering the passphrase just once, as soon /boot is unlocked, but so far I wasn't bothered enough to do the necessary research to figure out, how this could be done.
(BTW: As the issue is solved, it's not longer a request for 15.0, and we are a bit off-topic regarding the original thread, now. Therefore this is my last post on this topic, here. If it turns out that there is more to be discussed regarding LUKS and LVM that is not related to Slackware 14.2-->15.0 I suggest we pick it up on a dedicated thread.)
(BTW: As the issue is solved, it's not longer a request for 15.0, and we are a bit off-topic regarding the original thread, now. Therefore this is my last post on this topic, here. If it turns out that there is more to be discussed regarding LUKS and LVM that is not related to Slackware 14.2-->15.0 I suggest we pick it up on a dedicated thread.)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
