KSE Linux security-redux
In this post:
KSE is an excellent alternative for higher levels of Linux security. A number of considerations are presented for those who may not be aware of this user-friendly and cost effective SELinux equivalent.
In Linux security soap operas, I suggested it wasn’t necessary to wait for a consensus on Linux security leadership to be reached. KSE is the better option for securing Linux appliances and servers, right now. For many regular Linux users, the steep learning curve of complex SELinux is not an option. That also means there’s not much in it for non-Linux geeks. Consider KSE instead, which is a user-friendly SELinux equivalent. Last post discussed a comparative paper from about 8 years ago for more technical readers, here.
Infosec requires innovation in the form of better OS security engineering and design to achieve better outcomes. If you are just trying to learn about security, read on. Here are some advantages of KSE as a choice to consider.
Trusted over hardened
Many folks aren’t aware that trusted computing is a much higher level of security than merely hardened. To harden a box takes time and know-how. Now that KSE simplifies trusted computing for the first time, it’s the way to go, especially if you have hundreds, or thousands of systems to secure.
One thing we at Trustifier have to plead guilty to, is using the terms trusted and trustworthy computing interchangeably. But when we use either term, we are actually referring to “trustworthy computing” as it is applied to computing systems that are inherently secure, available, and reliable. Trusted systems may be granted and deemed trusted, but not necessarily verified as trustworthy. KSE protections are backed by algebraic modelling and mathematical proofs, and designed with formal methods.
“The National Security Agency (NSA) defines a trusted system or component as one “whose failure can break the security policy”, and a trustworthy system or component as one “that will not fail“.”
Unfortunately this term is most commonly associated with a Microsoft marketing campaign. Have you heard of any Windows system that has ever been verified as inherently secure?
More security for less effort
Most people assume the level of security provided by trustworthy computing, is overkill, not worth the trade-off that extra complexity, admin overhead and cost that surely comes with higher security and assurance offerings.
The original purpose of KSE was to design high security that greatly reduced those barriers, and make it suitable for the mainstream. The reason why it succeeds, is because KSE doesn’t work the same way as anything else. Isn’t that the purpose of innovation, to gain breakthroughs?
Reduced complexity = less admin overhead
Reducing complexity is an absolute requirement to make higher security possible for the mainstream. We estimate that KSE use of algebraic modelling reduces complexity and administrative overhead by two orders of magnitude over traditional high security implementations such as SELinux or Trusted Solaris.
That’s about 1% of the overhead of SELinux. For example, KSE eliminates ACLs, access control lists, and implicitly labels everything based on hierarchical user trust relationships using algebraic modelling. This is for the MLS, multilevel security that is enforced by KSE mandatory access controls.
Anything one can do with SELinux, one can do with KSE, and more, but with way less drudge work. Ramp up your defences to trustworthy system status but with less work than current efforts take for lesser protection.
Reduced overhead lowers cost of ownership
That big reduction in admin overhead translates into less time and staff to implement, maintain and manage your security at some point. When operational costs are reduced, your TCO, total cost of ownership, is as well.
Security is buggy, thinking
Linus Torvald’s “security is bugs” view symbolizes the major short-coming of infosec. I’m referring to perpetuating the “bug” hunting model rather than addressing root problems by building systems with proper security mechanisms. Because…
…the vulnerability-centric model is both the central pillar and Achilles Heel of infosec.
So would you say hunting for, and fixing vulnerabilities is working out? The all-consuming focus on vulnerabilities serves as a time and resource distraction sink and is either forgetting or ignoring, or maybe just not realizing, that the real path to security is excellent security engineering and design.
KSE is designed to protect vulnerable systems. KSE can protect vulnerable systems without patching.
Not many attacks actually use 0day weapons, but if the stakes are really high, how does one defend? Same with legacy applications or systems after end of vendor lifecycle support; KSE doesn’t depend on patches to protect.
Open source assumptions
Don’t assume that open source is automatically more secure just because of the touted “many eyes make bugs shallow” argument. A few major vulnerabilities revealed in the last year have challenged that assumption.
Just because MANY eyes can potentially check open source code, there’s no guarantee that ANY eyes will check the code.
Since KSE protects threats from exploiting vulnerabilities, it can be used to protect either proprietary or open source applications and systems you run, in any combination your business needs. That goes for customized in-house applications as well.
The purpose of bug hunting and remediation is…
…to prevent unauthorized privilege elevation leading to tampering with operational privileges on network systems. If KSE can protect without patching, it must to be able to do this another way. That other way is the ability to transform the trusted computing base of the system using algebraic models, as I explained here and here.
KSE prevents threats from exploiting vulnerabilities
KSE is able to envelop all processes in a “need-to-access” environment; it can control access to the IT vulnerability surface. The algebra backed security mechanisms of KSE provides a pre-emptive lockdown of the system so that the possibility of either external intrusion or insider threats intending to tamper with system privileges or rules for access becomes an extremely difficult exercise. For every system call, including root system calls, it boils down to control by a bit flip enforced by a kernel rule. When it’s flipped off, only authorized persons, and that may not automatically include system admins, are able to flip it on when required. You end up with just-in-time control over privilege elevation. It’s least privilege and conditional access control over individual root system calls.
Fewer opportunities for persistence
When unauthorized privilege elevation is denied, the opportunities for persistence in the network diminish. It’s hard to proceed, so the chances of intrusion are reduced by exceptional factors.
Indicators of attempted unauthorized behaviours
With KSE one can easily set limits or boundaries for access of all processes, users, files and data to exactly what is needed for a specific service to operate safely and securely. Opportunities to tamper with operational rules are very hard to come by. What’s more, since it becomes possible to whitelist end user behaviours, unauthorized execution attempts can flag a security officer in real-time, with KSE immutable, tamper-resistant logging removing the ability to use anti-forensics tools or evasion techniques. Layers of authorization controls can confine execution attempts so attempts by attackers to explore the network may backfire.
Security, more than software quality
The vulnerability issue neglects a key point; it’s only one aspect, or subset of what security is. Even if you had perfect code, does that make a system secure? How would perfect code on an XP box protect you against a rogue admin? Just like encryption is not a panacea for security in itself, systems require other security mechanisms which KSE provides.
KSE protects against the insider threat
Since KSE is a reference monitor, any system where it’s implemented will be able to take advantage of the security mechanism that has been most recognized to prevent the abuse of insider privileges. This includes authorization controls for fine grained per user protection against evil system administrators, privileged account holders and regular users.
Does Linux fragmentation make it hard to secure Linux across the board? FYI, KSE supports the major Linux distros and enables integration and inter-operability across all platforms and OSs in providing a scalable MLS and across-domain security offering. KSE isn’t one size fits all, but if you have multiple versions of Linux in your enterprise, there’s a version of KSE for each. Once KSE is loaded on them, the same ubiquitous security rules can be pushed out across the lot of them so they act in sync.
The KSE framework facilitates the management and delivery of all of its security across domains as well. KSE solves the scalability, usability, and network interoperability issues in traditional MLS solutions. KSE’s paradigm shift in trusted computing base design facilitates implementation of true cross-domain solutions that facilitate central security management across all zones or networks as required. KSE algebra based security primitives facilitate and ensure that protected nodes can communicate with each other in verifiable a trustworthy manner and act in sync.
One of the reasons for this is that by design, KSE goes out of its way to ensure no visible objects added to the kernel. A KSE security primitive may only use existing kernel parameters that can be calculated from existing kernel-proper objects. This ensures that KSE security primitives remain system-agnostic and predictable in order to be ubiquitous across heterogeneous systems (recognizable across platforms). (The MLS Capabilities Statement is here.)
KSE can be dropped on a supported OS, even a running production system. No need to rip and replace. At the 2010 SINET showcase, KSE was dropped on to a live Linux server and a rule immediately implemented to separate a suspected possible rogue sysadmin from sensitive directories, in a 6 minutes of our 9 minute allotted live presentation. Since KSE is designed to bring mathematically verifiable trustworthiness to COTS systems, this seems pretty good.
KSE can be ported to any OS of choice in order to protect devices and systems that require inherent security. It’s not one size fits all, but it is is OS agnostic. KSE is also real-time OS compatible due to its predictable latency. It can be embedded into an OS for development and the security protections activated for QA testing. For some things, like medical devices or interconnected devices, a higher level of inherent security might be a good thing.
Intuitive, simple language syntax
KSE features its own intuitive english-like syntax for its’ rule sets that is ubiquitous across platforms. In this way, even a windows admin can push out a security rule across zones to Linux, or Unix, etc., nodes protected by KSE without having to be a programming guru for other OS platforms.
On being KSE
Security is hard, but this post isn’t a discussion of the philosophical or existential views on the life choices of a security officer, despite the play on the title.
However, one no longer needs to shoulder all the weight and burden from being one who has been delegated the responsibility of security, or who has to be more aware and vigilant about it because those around him are not. KSE can lighten the load.
This series about KSE for Linux security has been simply to inform of a more user-friendly and manageable alternative to high level Linux security to give you control over the things you need to control in your environment. Preventing unauthorized tampering both at the system level and at the operational user privilege level is needed to take control your risk levels. Put KSE trusted computing where you need to know exactly what the risk is. The single greatest benefit of this level of security and control is, there are no nasty surprises. You won’t be continually having to put out fires!
Not Just for Linux Actually
You should know that KSE isn’t limited to Linux either. It’s not one size fits all, but KSE is OS agnostic. It’s just that this informal series has been driven by Linux security, and Trustifier Labs really knows Linux.
The other thing to know, is that the next evolution of KSE is about to roll with the release of the TUX (Trustifier User eXpectation) GUI. We’re bringing unprecedented levels of automation to the implementation of trusted computing. Trusted computing and simplicity are usually not mentioned together in a sentence, I know, but you will want to watch for it.
TUX is an evolution in both software and GUIs. It will be transcending.