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 -2 articles for you...
77
security advisorykernel securityUbuntuAppArmor “Enforcing” Doesn’t Mean What You Think: Verify What It’s Actually Enforcing
“Enabled” does not mean “Protected.” Recent kernel vulnerabilities, including cases like USN-8098-1 , show that a service can stay active while the policies it enforces are quietly swapped underneath it. . This isn’t a bypass in the traditional sense. It’s profile manipulation at the kernel level. In certain scenarios, an unprivileged user can alter loaded rules without triggering alerts. Monitoring still reports “Enforcing,” but the kernel is no longer running the policy you have on disk. That’s why checking status is no longer enough. You need to verify that what’s in memory still matches what you deployed. Beyond “Enabled”: How to Verify AppArmor Is Working (Not Just Running) Tools like aa-status or systemctl status apparmor report state, not integrity. They confirm the service is active, but they cannot tell you whether the active profile matches the one on disk. To actually verify AppArmor is working, you need to compare what’s on disk with what the kernel is enforcing in memory. That means checking the active profiles directly, validating them against a known baseline, and watching for live profile replacement events. Check What it tells you What you should be asking aa-status AppArmor is active Are these the original profiles? systemctl status apparmor Service is running Have profiles been altered? Kernel profile list Profiles are loaded Are the rules intact? If a profile is modified through a kernel flaw, these checks can still return a healthy status while the system applies a different ruleset than what’s on disk. When AppArmor Is Not Enforcing Rules: The In-Memory Mismatch AppArmor does not continuously re-validate /etc/apparmor.d/ against what the kernel is enforcing. Once a profile is loaded, the kernel treats it as the source of truth. If that in-memory version is altered,enforcement continues cleanly, just with different rules. The profile name stays the same and still shows as enforced, but the rules behind it no longer match what was deployed. What that looks like in practice: A profile reload is triggered by an unprivileged user The profile name remains unchanged to avoid detection Deny rules are relaxed or removed The modified profile is enforced immediately Where this tends to surface: Web services (nginx, apache, ssh): unexpected file access patterns Containers: profiles still attached, but isolation quietly weakened “Confined” processes: marked as restricted, but governed by altered rules If you’re stacking LSMs like SELinux or BPF-LSM, you may have partial coverage. Unless you’ve verified overlap at the rule level, assume the AppArmor layer is your primary control and treat compromise accordingly. Where Isolation Breaks Down: The Shared Kernel Problem Containers isolate processes, not enforcement. AppArmor still operates at the kernel level, and every container on a host depends on that same decision layer. If a profile is altered in memory, whether through a kernel flaw or misconfiguration, the change doesn’t stay contained. It applies everywhere that the profile is used. Think of the kernel as the landlord and AppArmor as the locks on each door. The locks can still be in place, but if the landlord has been compromised, the rules behind those locks no longer mean much. That shows up in places where isolation is assumed to hold: A CI runner pulls untrusted code, executes it under a known profile, but the rules have already been relaxed A multi-user system enforces confinement on paper, while certain processes quietly gain broader file access Containers appear restricted, yet share a policy that no longer matches what was deployed From the outside, processes still show as confined. The difference is in what those profiles now allow. The enforcement boundary has already shifted.The kernel is still making decisions, just not the ones you expect. How to Verify AppArmor Is Working: A 60-Second Integrity Audit Checking if AppArmor is running is just a heartbeat check. This is how you verify what it’s actually enforcing. How to Check for Unconfined Processes Start with processes that should never be unconfined: ps -Z | grep unconfined Focus on: nginx apache bind ssh If any of these show as unconfined, something is already out of alignment. Also, watch for profiles running in complain mode, since that’s how restrictions get relaxed without breaking execution. How to Check AppArmor Profiles Are Applied (Baseline Check) Compare what’s on disk versus what’s loaded: ls /etc/apparmor.d/ | wc -l aa-status These numbers won’t match exactly, and they’re not supposed to. Profiles can expand, load dynamically, or originate from different paths. What matters is consistency. Capture a baseline from a known-good system, then monitor for: missing profiles unexpected drops deviations from expected state How to Reload AppArmor Profiles and Verify State If something feels off, reload profiles directly: sudo apparmor_parser -r /etc/apparmor.d/* This replaces whatever is currently in memory with what’s on disk. To see what the kernel is enforcing right now: cat /sys/kernel/security/apparmor/profiles That’s your source of truth. Everything else is reporting around it. How to Verify AppArmor Profiles Haven’t Been Modified Profile manipulation doesn’t raise alerts. It leaves traces in audit logs. Focus on these events: sudo grep 'apparmor="STATUS"' /var/log/audit/audit.log sudo grep 'apparmor="REPLACED"' /var/log/audit/audit.log STATUS → Normal profile loads and enforcement events REPLACED → A profile was overridden on a live system That REPLACED event is the signal. It confirms that a profile changed without a restart, which lines up with howin-memory manipulation behaves. These entries won't stop the system; they just record what happened. This log acts like a black box you come back to when something doesn't line up. If you want to see how these events are handled and what AppArmor actually logs in practice, the AppArmor project documentation covers how profile loads, replacements, and enforcement changes show up. Why “Enabled” Doesn’t Mean Protected A green status is just a heartbeat. It says nothing about integrity. If you’re not: checking for drift auditing REPLACED events occasionally reloading from disk You’re relying on the assumption that memory and disk are still aligned. That assumption is exactly what these vulnerabilities exploit. Stop asking if AppArmor is running and start verifying what the kernel is actually enforcing. Because in the end, your security posture doesn’t depend on the service being active. It depends on whether the rules in memory still match the rules you trust. . Profile manipulation at the kernel level poses a real threat. Discover how to ensure AppArmor is functioning as expected.. AppArmor Security, Linux Kernel Threats, Application Protection, Process Isolation. . MaK Ulac
Mar 17, 2026
•
Server Security
72
network securityidentity managementapplication controlEvolving to Next-Gen Firewalls: Best Practices for Security and Control
What should enterprises expect if they want to make the transition from a traditional firewall to a next-generation firewall? It starts with a decidedly different way of thinking about security goals associated with a firewall, especially in terms of establishing application-aware controls over employees as they access the Internet, the Web and social networking sites. (See Unbatten the hatches.) . "There is a chasm to cross," acknowledges Patrick Sweeney, vice president of product management at SonicWall. The old way of talking about traditional port-based firewalls, with system administrators discussing the "language of protocols," is inadequate. Companies need to adopt a more business-focused vocabulary, related to application use, that's common to the CIO, CFO and CEO. "There has to be unification of the languages they speak," Sweeney says. That's because the new generation of fast, intelligent firewalls are application-aware, enabling enterprises to establish and enforce identity-based application usage policies for employees. So-called next-generation firewalls (NGFW) also incorporate VPN capabilities, perform intrusion prevention sweeps of traffic, have the brains to use technologies such as reputation filtering, and integrate with Active Directory for identity and policy management. The link for this article located at Network World is no longer available. . The transition from traditional firewalls to next-gen firewalls signifies a pivotal evolution in cybersecurity, enhancing threat detection and network control. Next-Generation Firewall, Application Control, Security Practices. . Alex
Jan 03, 2011
•
Firewalls
74
security advisoryCiscoweb servicesCisco: Reactivity Acquisition Strengthens Web Services Security
Cisco's acquisition of XML vendor Reactivity today could set the stage for a new approach in handling the Web services security problem, experts say. Cisco announced its intent to acquire privately held Reactivity, a maker of specialized XML processing hardware, for $135 million this morning. On the surface, the deal looks like a simple play for the networking giant to incorporate Web services capabilities into its hardware lines, but security experts inside and outside Cisco say there may be more to it than that. . The Reactivity technology will eventually be built into the Cisco security architecture, so that application-to-application controls can be implemented along with user-to-application controls, says George Kurian, vice president and general manager for Cisco's Application Delivery unit. The link for this article located at darkReading is no longer available. . With the purchase of Reactivity, Cisco seeks to bolster the security of web services through the incorporation of XML capabilities into its infrastructure.. Cisco Networking, Web Services Security, Reactivity Technology, Application Control. . Bill Locke
Feb 23, 2007
•
Network Security
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