Network Security
system security Linux network
system security Linux network The romanticized image of the digital nomad – a laptop on a sun-drenched balcony – rarely accounts for the actual friction of maintaining a professional development environment on the move. . The friction is amplified with Linux. We are looking for a setup that respects our kernel configurations, handles volatile network handovers, and maintains a strict security posture without the hand-holding of a consumer-grade OS – so, put simply, more than just a laptop and a sunny deck. The hardware is...
May 26, 2026
Server Securityopen-source Linux administration
open-source Linux administration Cron has existed in Unix and Linux environments for decades, handling backups, cleanup scripts, patching jobs, log rotation, monitoring tasks, and other maintenance work that administrators do not want to run manually. Most Linux servers rely on it constantly, which is exactly why attackers continue abusing it for persistence after a system has already been compromised. . Persistence through cron is not complicated. Attackers do not need a rootkit or advanced malware framework to maintain...
May 25, 2026
Vendors/Productssecurity breach linux
security breach linux A major internal repository breach at GitHub has exposed a critical and overlooked blind spot in Linux supply chain security. Kernel exploits, exposed SSH services, weak firewall rules, and vulnerable daemons dominated the Linux threat model for years, and in many environments, they still matter. But recent supply-chain incidents involving GitHub ecosystems, npm packages, and malicious developer tooling point somewhere else entirely: the developer workstation. . The breach matters because...
May 21, 2026
Security Trends access control multi-tenant
access control multi-tenant Linux administrators often face an ugly choice in the cloud: prioritize convenience and cost-efficiency by sharing infrastructure, or sacrifice those benefits for the sake of total isolation. Most modern Linux workloads don't live on their own private servers anymore. They live in shared environments like Kubernetes clusters, where multiple teams and services run side-by-side. It sounds efficient, and it usually is. . But cloud isolation isn't as ironclad as it looks on the diagram. If you...
May 21, 2026
Vendors/Productsincident response cloud security
incident response cloud security Managed Extended Detection and Response (MXDR) has become one of the most sought-after security services in the enterprise market — and with good reason. It promises the holy grail: broad visibility across endpoints, network, cloud, email, and identity, combined with the 24/7 human expertise most organizations simply cannot build in-house. . However, the rapid growth of the market has produced a wide range of providers whose capabilities vary considerably beneath the surface. Choosing the...
May 19, 2026
Refine news
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Loading...
Explore Latest Linux Security news
We found 0 articles for you...
77
security advisoryencryptionUbuntuUbuntu’s GRUB Change: Fixing a Problem… or Creating One
At some point, it stopped being “load kernel and go” and turned into this thing that tries to understand every filesystem, every storage setup, encryption, all of it, before the system is even running. And that’s where it keeps biting people. If you’ve dealt with GRUB breaking, it’s almost never the basic path. It’s trying to read something slightly non-standard and just falling over. Btrfs layouts, LVM stacking, and encrypted setups, stuff that works fine once the kernel is up, but GRUB has to guess at it first. The more GRUB understands, the more it can get wrong. This isn’t about “GRUB is bad,” it’s that GRUB turned into something way bigger than a bootloader, and now it carries all the risk that comes with that. . What Actually Changed? GRUB is getting stripped down specifically for Secure Boot scenarios. It will stop understanding filesystems like Btrfs, ZFS, and XFS, along with LVM and LUKS. None of that capability disappears from Linux, but it disappears from the stage before the kernel starts. GRUB now expects a direct, unencumbered path to the kernel. If it can’t read where the kernel lives because it's buried under an encryption layer it no longer understands, hence, you don’t boot. They are essentially trying to make GRUB act like a Unified Kernel Image (UKI) without actually switching the backend for everyone. So if GRUB Is the Problem… Why Not Just Move Past It? What keeps coming up with Ubuntu 26.10 Secure Boot is simple. There are already modern tools like systemd-boot, EFI stub, and UKIs. These options are much simpler by design. They do not try to understand complex filesystems or encryption. They just find the kernel, hand off control, and let the Linux kernel do the heavy lifting. Moving to one of these would be a "clean break" from the old way of doing things. So why is Ubuntu 26.10 sticking with a stripped-down GRUB? It comes down to compatibility. Ubuntu is a "run everywhere" operating system. It still has to support: Old computers with legacy BIOS (which can't use systemd-boot). Massive server environments with mixed hardware. Edge-case setups that the more modern, "simple" bootloaders aren't ready for yet. Because Ubuntu refuses to drop support for those older systems, they are stuck with GRUB. But because they want the security of a simpler boot process, they are "gutting" GRUB instead of replacing it. The result is an awkward middle ground. Ubuntu is keeping the same old bootloader in the middle of the chain, but it's stripping away the "intelligence" people actually rely on. So, no, they aren't moving past the problem. They are just trying to patch the problem. And that works fine right up until you try to carry an existing system forward. The Real Risk Isn’t New Installs. It’s Upgrades! If you’ve got an existing system with /boot sitting inside LUKS or layered through LVM, GRUB today can read through that. After this change, it can’t. The "Upgrade Trap" is simple: the upgrader will check your layout, see that it’s "unsupported," and stop the process entirely. You are effectively stranded on an old release unless you’re willing to manually repartition a live system. Routine upgrades are being traded for high-stakes recovery scenarios. If someone ignores the block and pushes through, the outcome is predictable: a system that doesn't boot and a long night with a Live ISO. Impact on Snapshot-Based Workflows Take away GRUB's filesystem logic, and you take away its ability to list snapshots. For Btrfs users, recovery goes from “pick a snapshot and boot” to a manual nightmare. Encrypted disks, LVM, Btrfs. These aren't "niche" setups. They are how real servers and advanced desktops are built. Why This Change Raises Real Concerns for Linux Users GRUB used to act like a file explorer at boot. It could read Btrfs, ZFS, and LUKS, determine where the kernel was located, and hand off cleanly. Now, it expects the kernel to be in a simple, directly readable location likea plain /boot partition. The complexity doesn’t go away; it just shifts. GRUB does less, while the kernel and initramfs do more. The problem is, if that later stage fails to mount your encrypted or layered storage, you aren’t in a GRUB rescue shell anymore. You’re dropped straight into the dreaded BusyBox shell. Instead of a bootloader with some "intelligence," you’re left in a minimal environment with almost no tools to fix a broken mount. While GRUB was a "safety net" you could interact with, the new model leaves you with almost no tools if the handoff fails. This Isn’t Just a GRUB Change; It Touches the Boot Process The boot process is the most sensitive layer of the system. Small changes here don’t fail cleanly; they fail early. When that happens, you’re not troubleshooting an app. You’re in recovery, trying to fix why the system won’t boot. For users who value stability, this "streamlining" feels like removing the safety net. Existing Systems Aren’t Clean or Standard Real-world systems evolve. Encryption gets added years after an install, storage gets reworked, and layers build up over time. A lot of setups work today precisely because GRUB is smart enough to handle that complexity. This change assumes a "clean" layout that simply doesn't match the messy reality of long-running Linux machines. Upgrades Could Become Recovery Scenarios This stops being a simple “update and reboot” task. If your layout doesn’t match what this new version of GRUB can read, you’re looking at moving /boot, separating encryption layers, or restructuring partitions just to get the system back up. One mistake during this manual restructuring, and your upgrade is now a full-blown recovery mission. This Pulls Boot Design Back Toward Older Models Separate, unencrypted /boot partitions are becoming the mandatory "safe" default again. It feels like 2010 called and wants its partitioning scheme back. We spent the last decade moving away from theserigid, fragmented layouts for a reason—they add friction and waste space. But, this change effectively mandates them if you want a system that "just works" under Secure Boot. Simpler defaults might help the majority, but they come at the cost of the flexibility that made Linux powerful. GRUB does less, the kernel does more, and the gap in between is where admins and power users end up doing the heavy lifting. If GRUB Is Too Complex… What’s the Endgame? On one side, you’ve got the appliance model. Simple, predictable, fewer moving parts, easier to lock down. On the other, how a lot of systems actually look. Layered storage, encryption, and setups that evolve over time instead of staying clean. Ubuntu is trying to sit in the middle. Keep GRUB, but strip it down. Reduce what it has to deal with early, while still supporting everything later. If GRUB isn’t handling it anymore, then your layout has to be simpler, or you’re dealing with it during recovery. As 26.10 gets closer, the question isn’t whether boot is simpler. It’s who ends up dealing with what got pushed out of it. . Significant GRUB changes in Ubuntu 26.10 present risks during upgrades and impact complex setups.. GRUB updates Ubuntu Secure Boot Linux upgrades recovery. . Dave Wreski
Mar 26, 2026
•
Server Security
67
malware protectionsystem integritysecurity standardSecure Boot Explained: Enhancing Linux Security and System Integrity
Boot security has become an increasingly important topic in recent years as threats against system integrity continue to evolve. Secure Boot is a security standard developed to provide protection against such threats by validating the integrity of boot software. With Secure Boot, security is enforceable during the boot process rather than relying solely on the operating system. This helps prevent malicious software from embedding itself early in the boot process, providing an additional layer of defense against low-level attacks. . As computing environments become more complex, Secure Boot offers a proactive safeguard to strengthen system security from the ground up. Its approach aligns with the security principle of defense in depth by adding protective measures at multiple levels. For admins, infosec professionals, and others responsible for system security, understanding the mechanisms behind Secure Boot is key to evaluating its tradeoffs and effectiveness in practice. This article will provide a technical overview of Secure Boot's work and its implications for Linux-based systems. What is Secure Boot? Secure Boot is a security standard developed by members of the PC industry to help make sure that a device boots using only software that is trusted by the Original Equipment Manufacturer (OEM). It is part of the Unified Extensible Firmware Interface (UEFI) boot process. When enabled, Secure Boot ensures that an accepted digital certificate signs each piece of boot software. If any unauthorized change is detected during the boot process, Secure Boot will not allow the machine to finish booting. This prevents malicious software from modifying the bootloader or kernel and helps ensure that only trusted software approved by the OEM loads at boot time. The goal of Secure Boot is to protect the integrity of the boot process by preventing unsigned or unauthorized code from running before the operating system loads. It aims to harden device security and mitigate certain common attacks like rootkitsor bootkits that can be difficult to detect and remove if they are able to run during the machine's boot-up sequence. Overall, Secure Boot aims to make exploitation more difficult for attackers by restricting what can run before the OS is initialized. How Secure Boot Works Secure Boot utilizes the Unified Extensible Firmware Interface (UEFI) to check the digital signatures of operating system loaders before launching them. This verification process prevents unauthorized or modified operating systems from running. The Secure Boot process involves a hierarchy of cryptographic keys embedded in the system firmware. Microsoft requires all Windows 8-certified devices to ship with Microsoft keys pre-installed. There are several key types: Platform Keys (PK) - Root keys that represent the system/device manufacturer. Used to verify Key Exchange Keys. Key Exchange Keys (KEK) - Keys used to verify bootloaders and OS kernels. Signed by Platform Keys. Signature Database (DB) - Authorized signing keys stored in firmware. Used to authenticate boot binaries. Forbidden Signature Database (DBX) - Keys of unauthorized or revoked binaries that failed validation. When booting, the firmware checks the signature of the bootloader against its built-in keys in DB/DBX. If verified, it executes the bootloader, which then checks the OS kernel. This repeats for any layered binaries in the boot process. Keys and signatures form a Chain of Trust that confirms legitimacy. Benefits of Secure Boot Secure Boot aims to prevent boot malware and rootkits by only allowing verified bootloaders and OS kernels to load during the boot process. This protects the integrity of the boot process by blocking malicious software from modifying bootloaders or kernels. Some key benefits of Secure Boot include: Prevents bootkit attacks : Since only digitally signed bootloaders and kernels can execute, Secure Boot blocks bootkits and rootkits from infecting the boot process. This prevents attackersfrom gaining persistence on the machine. Built-in malware protection : By restricting unauthorized code execution during boot, Secure Boot is an effective first line of defense against malware seeking to establish footholds through boot persistence. Alerts users of tampering : If a malicious actor tampers with the boot process, Secure Boot will prevent startup and alert the user that unauthorized changes have occurred. This makes it harder for attackers to hide malicious code in boot components. Protects recovery partitions : Secure Boot requires that recovery partitions also have properly signed bootloaders, protecting these partitions from tampering. Facilitates trusted boot : Secure Boot verifies the integrity of each step in the boot process, enabling trusted boot. This ensures no rootkits or malware have compromised any part of the startup sequence. By leveraging cryptographic verification of boot components, Secure Boot makes it much harder for attackers to compromise systems at the earliest stages of operation. For security-conscious users, this safeguard against advanced boot attacks is a major benefit. Drawbacks of Secure Boot While Secure Boot offers increased security, it also comes with some notable drawbacks. First and foremost, Secure Boot can cause compatibility issues. Since Secure Boot restricts what can run on a device, operating systems or bootloaders that are not signed with an approved key will fail to start up when Secure Boot is enabled. This particularly impacts Linux distributions - many may not boot properly unless steps are taken to sign the bootloader with a trusted key. While solutions exist, such as adding your own keys or disabling Secure Boot entirely, it represents an extra complication that would not otherwise exist. Secure Boot also impacts user freedom and control over devices. With Secure Boot active, users cannot easily install alternate operating systems or modify critical boot components. Everything has to becryptographically signed with a key authorized by the hardware vendor. This gives hardware vendors more control over what can run on a device, reducing the level of user freedom. While power users can work around Secure Boot, it does make tinkering and modifications more difficult. So, in summary, the two major drawbacks are compatibility problems with unsigned operating systems like Linux and a reduction in user freedom due to restrictions enforced by Secure Boot. While Secure Boot heightens security, it can come at the cost of convenience, flexibility, and control. Secure Boot in Linux Most modern Linux distributions support Secure Boot without the need to disable it. This is accomplished by using a "Shim" bootloader, which acts as an intermediary between the UEFI firmware and the OS bootloader like GRUB. The Shim bootloader is signed by Microsoft so that it can boot on systems with Secure Boot enabled. It then verifies the signature of the Linux kernel and initrd image before booting into the Linux OS. This allows Linux distributions to work seamlessly with Secure Boot without requiring any modifications. In order to have its bootloader and kernel recognized by Shim, each Linux distro generates its own keys and includes them in its boot files. During installation, the distro adds its keys to the UEFI key database in a process called "enrollment." This allows the boot chain to be properly verified at each stage by Shim and UEFI. The enrollment keys are cryptographic certificates that establish a chain of trust from the distro's keys to Microsoft's keys to the OEM's keys baked into the hardware. As long as all the keys check out, the system will successfully boot. Overall, Shim, combined with proper key management, allows modern Linux distros to function on Secure Boot-enabled devices without users needing to disable this important security feature. This makes it much easier to run Linux on most PCs today safely. Disabling Secure Boot Secure Boot is enabled by default in Windows 11and most modern computers. Some Linux users may wish to disable Secure Boot for greater control and customization of their systems. However, there are risks in doing so. Disabling Secure Boot opens up the computer to potential bootloader attacks or malware. With Secure Boot off, an attacker could install a malicious bootloader and gain control of the system on boot up. For most users, the added security of Secure Boot likely outweighs the need for customization. However, power Linux users may still wish to disable Secure Boot to allow the installation of custom kernels, bootloaders, or drivers that are not part of the default Secure Boot key database. Advanced Linux users can take steps to secure their system through other means if they choose to disable Secure Boot. In general, Secure Boot only needs disabled if you want to boot an operating system or drivers that are not signed with keys already trusted by your firmware. The average user likely does not need to disable it. But Linux enthusiasts who want more control over their system may choose to take other precautions to lock down their boot process. Looking Ahead Secure Boot and technologies like TPMs (Trusted Platform Modules) are likely to continue advancing and playing pivotal roles in computer security. As threats evolve, secure boot implementations will need to keep pace. Microsoft and other vendors may continue refining their secure boot policies. Wider TPM adoption could provide hardware-based security enhancements like full-disk encryption and virtualization-based security. However, this trajectory also raises concerns about user freedom and control. The FOSS community may push back against restrictions while seeking open alternatives. Overall, technologies like secure boot aim to harden security, but feedback loops with users and developers will shape their future. Balancing security, usability, and openness remains an ongoing challenge. Final Thoughts on the Significance of Secure Boot Secure Boot offers valuable protectionagainst firmware attacks and rootkits in order to keep systems secure. However, it also introduces new challenges. Overall, Secure Boot aims to improve security but requires some thoughtful configuration, especially for Linux users who wish to retain control over their systems. With the right keys and signatures, Secure Boot can help block malware while still enabling users to run their preferred OS and software. While adjustments are still needed, Secure Boot represents an important step towards more trusted systems and supply chains. Looking ahead, solutions that combine security and flexibility will be key in the ongoing quest to balance protection and user freedom. Key takeaways from this article include: Despite previous concerns, secure boot works well with Linux distributions and is disabled by default on pre-installed Linux laptops. Secure boot does not prevent installation of other operating systems. Secure boot aims to block malware trying to modify the boot process. The tradeoff is reduced flexibility in controlling your boot process. Microsoft requires secure boot enabled for Windows 11 certification. This improves security but reduces user control. Most Linux distributions work with secure boot enabled after adding their keys. Some, like Gentoo, still face challenges. Secure boot validates bootloaders and kernels via cryptographic keys. Red Hat, Canonical, Microsoft, and others have their keys preloaded. Users can enroll their own keys and certificates to sign bootloaders and kernels for full control. This requires disabling secure boot first. Threat actors still find ways to bypass secure boot protections in sophisticated attacks. No security solution is perfect. Stay safe out there, fellow Linux users! Be sure to subscribe to our free weekly newsletters for the latest information, insights, and advisories impacting the security of your systems. . As computing environments become more complex, Secure Boot offers a proactive safeguard to strengthe. security,become, increasingly, important, topic, recent, years, threats, against, system. . LinuxSecurity.com Team
Jan 03, 2024
•
Cryptography
83
security advisorysystem protectionexploit mitigationProtecting Devices from UEFI Exploits: Mitigating LogoFAIL Issues
A collection of new security vulnerabilities called LogoFAIL has been discovered hiding with the Unified Extensible Firmware Interfaces (UEFI) that we use for booting almost all modern computing devices. Linux or Windows, ARM or x86, it doesn't matter -- they're all vulnerable to these flaws! . This threat has been lurking in systems for decades. What makes it particularly concerning is the wide range of impacted consumer and enterprise-grade computers. The core of LogoFAIL is its exploitation of logos displayed on the device screen during the early boot process while UEFI is still running. Exploits occur during the earliest stages of the boot process. Hence, the attacks bypass UEFI defenses, such as Microsoft Secure Boot and Intel Secure Boot, that are meant to block bootkit infections. If you are vulnerable, you must make sure no one can get into the device in the first place. This requires patching your operating system and programs against all known attacks. Firmware fixes are on the way, but in the meantime, lock down your systems as much as you can so a LogoFAIL attacker doesn't gain a foothold. I found the article linked below helpful in understanding the specifics of this exploit and how to secure my systems against it. Check it out! . Protect your devices against LogoFAIL attacks targeting UEFI vulnerabilities in boot processes and ensure robust security practices.. LogoFAIL attacks, UEFI vulnerabilities, boot sector security, system hardening. . LinuxSecurity.com Team
Dec 14, 2023
•
Hacks/Cracks
67
security featuredisk encryptionboot processSystemd 252: Improved Boot Security And Disk Encryption Features
The fall version of systemd is here, with support for increased boot security, including tightened full-disk encryption. . The 113th version has the usual long feature list of very specific, targeted elements outlined in the release announcement. However, as one might expect following recent events, several of the headline features relate to the new UKI fully signed boot process . UKI is short for "Unified Kernel Image" and combines the Linux kernel and initrd into a single file, along with some other smaller components, allowing the whole thing to be cryptographically signed. The purpose is to tighten up security on the Linux boot process. . Explore the major improvements in Systemd 252, focusing on boot security and enhanced disk encryption features.. systemd Features, Linux Disk Encryption, Boot Security Improvements. . LinuxSecurity.com Team
Nov 09, 2022
•
Cryptography
67
kernelsystem securityTPMLennart Poettering's Proposal on Trusted Boot with TPM 2.0
Building your own initial RAMdisk? That's insecure! . Lennart Poettering's latest blog post proposes moving the Linux boot process into a "Brave New Trusted Boot World" of cryptographically signed Unified Kernel Images. Agent Poettering offers a mechanism for tightening up the security of the system startup process on Linux machines, using TPM 2.0 hardware. In brief, what he sees as the problem is that on hardware with Secure Boot enabled, while the boot process up to and including the kernel is signed, the next step, loading the initrd , is not. That's what he wants to fix. . Lennart Poettering proposes moving the Linux boot process into a 'Brave New Trusted Boot World.'. Linux Boot, TPM Enhancements, Trusted Boot Process. . LinuxSecurity.com Team
Oct 29, 2022
•
Cryptography
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
What got you started with Linux?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Discover faster search, smarter navigation, and deeper Linux security insights. Read More