KAISER Getting Ready To Better Protect The Linux Kernel

[tildearrow]

Typo:

From the new KAISER Kconfig switchm,

[starshipeleven]

For most of these formats there's no "really trustworthy" application. And, I've got to try many of them, to check whether they are doing what I need. But, one of them installed some exploit, and my data was encrypted/destroyed/stolen after some time,..

How does any of these tools would have protected me against such malware?

If configured correctly, they usually provide some level of sandboxing.

Sandboxing means that the application running in them can only access folders in a white list, can only call some other executables, and can only do some syscalls (calls to kernel, so it cannot try to exploit kernel vulnerabilities on subsystems it does not need to have access to).

But they need to be configured for each application, and to know what each application does/needs you must have the source available or you must waste a lot of time by trial and error.

They are mostly aimed at shipping and locking down known applications (so their bugs can't be exploited to take over the system), not at locking down random applications downloaded from the Internet.

Take in consideration, that I'm lame user in that scenario,

The "very lame user" solution is to have a secondary PC you use for these things (and whose disk is backed up on an external drive so you can recover from malware easily), while the data is on your main PC.

The less-lame solution for your use-case is virtual machines. Assuming your main PC has 4 GB of RAM or more and its from 2010 or newer, you install Virtialbox or VMWare player (both free), and then use them to create a virtual machine. It's simple enough, and there are plenty of tutorials online to do that.

A virtual machine is an application that disguises itself as a physical PC and lets you install a whole operating system like Windows or Linux in it.

By default it has no access to anything in the host, and you can make "snapshots" of it, so if you install some crap application that rapes your VM you just "shut down" the VM and reload an older snapshot.

You can pass-through to the virtual machine your network, usb devices (specific ones you pick), serial ports (again specific ones), and so on, so you can have the programs running in the virtual machine communicate with external hardware in the real world.

Now, a virtual machine does not give you 100% immunity from malware as they do find and fix vulnerabilities every now and then, but to infect the host you would need to have malware that knows how to bypass the virtual machine AND to infect the PC's host system. Which is pretty much unheard of afaik.

For example if you run a Windows Virtual Machine over a Linux system the chances anyone made a malware that can infect Windows, bypass the VM, and then infect also Linux is more or less nonexistent.

[starshipeleven]

and malware could corrupt already backed-up data, during process, while external HDD is connected to computer.

Nitpick, golden rule of backups is to store the backup separate/isolated from the machine it is the backup of.

The golden rule is one backup close (but isolated) and one backup in a remote location.

External drives are poor backups, as they require user interaction, and you know how bad a man can be, forgetful, lazy animals.

A NAS is a better local backup strategy, as a backup to a network device can be automated with any software, and most malware does not bother with scanning the local network, finding the NAS and trying to crack the passwords to infect the data there too.

[starshipeleven]

Flatpak isn't very secure. Though, it protects user from ransomware, it doesn't protect user from spyware. I did install Skype through flatpak (GNOME Software, Fedora 27). It didn't ask for any permission.

Skype installed though Flatpak has got access to my microphone, and full read access to my home folder. Without any warning, any information, that Skype can read all my data. And, gnome software labelled Skype as sandboxed, but I don't consider application, with full read access to home folder, as a sandboxed application.

Flatpack, just as Selinux, Apparmor and others are powerful tools, but at the end of the day they are only as good as the configuration shipped with the app tells them to be.

In your case the Skype package is poorly configured, which is.... way too common on desktop applications.

An example where these systems are taken seriously is Android. On most Android phones you have a pretty hardcore permission system, and you can deny applications access to something if you want. (and it's SELinux the backend of most stuff)

In newer Android versions (6 and later I think) the apps simply can't write outside of their own folder (be it in the internal or external storage) or inside well-known free-for-all folders (like "downloads", "documents", "music", and so on). And applications that don't state permissions for some subsystem in their configurations are automatically denied access to it.

With a phone running LineageOS (direct Cyanogenmod descendant, the most well-known alternative Android-based firmware) or a derivative you usually have access to the true full permission system thanks to a feature called Privacy Guard, and there you can give or revoke or have "always ask" on permissions.
With the "always ask" setting when an app needs to access some subsystem (microphone, camera, storage, show overlay popups, or anything else), you will see a popup asking you for permission for each particular subsystem any time the app requests it, so for example if you wanted to make a Whatsapp call you will enable access to the microphone, then when the call is ended the app will no more have access to it (and needs your approval again).
And this feature works also on Google services, in LineageOS. So you can stop them from snooping the shit out of your stuff.

Again it's not 100% safe as it can and does have vulnerabilities as everythingelse, so you need to keep it updated to some extent, but at least it is a serious attempt at security and privacy.

This is what a OS designed in the 21st century looks like. Applications never run as root even when installing, lockdowns everywhere, partial permissions system.

Linux distros are a joke by comparison, and Windows is even worse.

At least distros are slowly working towards that goal, while Windows land can't seriously try to enforce this or they will lose their ecosystem of poorly-maintained applications that still work somehow.

[kiffmet]

yeah, given that Kaiser is one of the worst beers in Austria

Still better than Ottakringer or Pittinger

[aht0]

I think that was kravemir means, at least what I think, is it would be great if there was a user-friendly solution to sandbox untrusted applications. At the moment there is none. I think that firejail is the closest to an easy way to sandbox programs, but unfortunately when a program tries to do something that firejail blocks, the result is the program crashes with no error message, so it’s not that helpful. Idealy we’d get a popup dialog asking if we want to allow the program to access that directory, or access internet… but we are far from that.

Capsicum, but it's in BSD and so might not be what you want.

[RelaxTrolls]

With a phone running LineageOS (direct Cyanogenmod descendant, the most well-known alternative Android-based firmware) or a derivative you usually have access to the true full permission system thanks to a feature called Privacy Guard, and there you can give or revoke or have "always ask" on permissions.
With the "always ask" setting when an app needs to access some subsystem (microphone, camera, storage, show overlay popups, or anything else), you will see a popup asking you for permission for each particular subsystem any time the app requests it, so for example if you wanted to make a Whatsapp call you will enable access to the microphone, then when the call is ended the app will no more have access to it (and needs your approval again).
And this feature works also on Google services, in LineageOS. So you can stop them from snooping the shit out of your stuff.

cm/lineageOS are less secure than AOSP and the majority of stock android ROMs;

they (cm/lineageOS) opted out of some of android 7+ security features. ex: hidepid=2 for procfs... they also forward ported the old exploit friendly single-process mediaserver for older devices, so any older device is inherently less secure (their mediaserver doesn't support seccomp/minijails, either)...

and idk if this has changed (but was true of cm14.1), but they used to suggest signing builds with a public key from the SDK in their build documentation and there was no implementation in 'platform_build' component to even make use of custom signiture keys.... by signing builds with the public testkeys - you've just broken android's security model...

last I checked, they don't odex; odexing gives a boot/performance boost and also makes tampering with APKs harder.... (and when I was chatting with cm devs on gerrit (I used to contribute), they couldn't even get it to work - which I DID have working until they broke it somehow on cm14...

this hopefully has changed; but they used insecure http for their bug reporting, tracking/analytics code (that code shouldn't even be there, I used to rip it all out of cm, when building it).

PrivacyGuard is interesting, but I think there are bigger security holes/exploitable code that it doesn't solve, plus it's not the 'true access to the permiision system', it some hacks on the upstream code... i think the CopperheadOS guys/also found many security holes in Cyanogenmod, which is why they ditched it as a base, for their security oriented spin of android.

plus, I would imagine if google or Facebook (WhatsApp) wants to spy on you, they probably have slicker ways of doing so...

[hoohoo]

I'd've thought the Austrians would have had enough of Kaisers!