All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Do lxc containers protect against malware to a similar level as vms?
user3028938
Member
In the past I have used a livecd vm if I want to watch a video where I didn't trust the source so then it is amnesiac and everything is gone for next boot.
I have also used a static vm with gpu passthrough before if I wanted the maximum hardware capability while still having the protection of the vm. This worked like a charm.
I have a very modest laptop now though so I can't do either of the above. Well I can do the first but the playback is so poor it just stutters terribly and the cpu shows near maxed out.
I tried setting gpu acceleration for the vm (opengl, not passthrough) which helped for lower resolution videos but when I tried a 720p one last night it was again unusable.
So would lxc containers allow me to take advantage of all of the meagre hardware capabilities of this laptop (it is a budget laptop even when it was released in 2013 era) while having effective isolation of whatever is being run?
I read that videos cannot contain malware or so rare as to be a none issue as they are not executables so one should not care about running any video, is this true?
What about the case for executables like bin or exe if using wine?
I also cannot do passthrough on this machine as the hardware doesn't support it.
So I guess I am asking for both cases, either/or/both, if an lxc container is sufficient for isolation to run either videos or executable one may not trust? As in, is it sufficient for videos but not executables or for both/neither?
Comments
It’s sufficient isolation from the host as long as there isn’t some container breakout zero-day. Those are extremely rare, and in real life Docker/LXC is used every day without issues. A full KVM VM is a stronger boundary, but for a normal use case the risk either way is basically negligible.
Thanks. Yea it is used every day without issues but not by all who are running suspect programs, so not exactly the same use case is it?
I mean someone can run linux only using their package manager trusted software for 20 years but it isn't the same as deliberately running a program that was from an untrusted source.
Suspect program or not, what I'm trying to say is that there is no known / public way to breakout of an LXC container. An exploit to breakout of LXC containerization would likely be worth hundreds of thousands of dollars. It is very unlikely that a random 'untrusted' executable you run would be bundled with something like that.
Ok, thanks.
LXC or incus can use qemu/kvm underneath the hood for better privacy and this would be the gold tier standard so I recommend you take a look into that if possible
Yea but the whole point I am not using kvm already is due to the performance hit of not being able to use baremetal hardware performance so that would defeat the purpose wouldn't it as then lxc would just be running through a vm again?
As I was thinking about it more I think it makes more sense because there must be thousands/tens of thousands or more lxc servers and some users must have suspect stuff they are hosting on some of them yet we haven't heard of breakouts from the admins, at least from what you say, as I am not an admin and don't follow that news but it makes sense from what you are saying.
Btw were you referring to privileged or unprivileged containers in those statements or the same case for either? I used to used privileged ones but recently learned the extra steps to make unprivileged containers work so that is what I use now.
Not totally true.
Video files being non executable on its own doesn't matter. The video file may contain certain byte sequences which when decoded through a particular media player say vlc may trigger memory corruption. In the best case, vlc just crashes, no damage done. But those byte sequences could also have been carefully crafted so instead of crashing vlc it executes certain code which then ultimately leads to host takeover.
So in that regard a video file is as safe as a random executable file as long as no one interacts with it. The moment something interacts with that be it directly executing or running through a video player that the possibility of malware infection emerges.
But yes the chances of being compromised through a malicious mp4 is much slimmer than an executable file because it is much tougher to create such a mp4 in the first place.
LXC is significantly less secure due to how common kernel vulnerabilities are. See https://security.stackexchange.com/q/169642/106285 which answers this question in detail (although it uses Docker as an example, but both Docker and LXC are namespace-based containers).
That's untrue. A Linux LPE is worth significantly less than that, especially on distro kernels.
Easy LPE: Look for a few CVEs and git blame to find out who was responsible. Then look through the subsystems that author develops and look for bugs of the same kind (e.g. refcount overflow if the author tends to introduce that type of bug) which are fixed in vanilla upstream but not backported to distro kernels because no CVE was requested. Chances are it won't just be a crash, it'll be exploitable. Sell for $5k, maybe $15k if it's particularly stable and doesn't require any infoleaks. $50k maaaaybe if it's very stable and works on a wide variety of kernels in a wide variety of configurations. Anything more than that and it'll have to be in a core subsystem, will have to bypass grsecurity, or will have to be remotely exploitable.
There's a reason gkh tells everyone to use the upstream kernel, but no one listens.
gkh: "Use upstream because we aren't gonna mark all security fixes as security-relevant!"
distro kernel maintainers: "We're not vulnerable because we backported everything marked as security-relevant!"
distro users: "My distro kernel doesn't have a single DSA/RHSA/GLSA because all the security fixes are backported!
But a kernel LPE worth hundreds of thousands of dollars? That thing had better be able to bypass grsec protections on a modern system with shadow stacks and kCFI/RAP without causing any WARNs and be exploitable through an interface that is commonly exposed in seccomp sandboxes (your favorite exploitable VT ioctls won't count). Then integrate it will into an existing exploit framework (they're all about modularity nowadays ever since red team ops fell in love with Core Impact) and then you can start talking about making six figures with it.
But some LPE that runs on a stock Debian stable kernel and can exploit a system from inside a container with "only" 99% reliability? That's the kind of 0day you burn at a security conference just to show off and use as an example because it wouldn't even be worth low five figures, and everyone loves seeing
[*] w00t w00ton stderr followed by a cute little#.(It is true, however, that a random executable is unlikely to exploit your kernel, but not because it's so secure)
I wouldn't say it's much tougher. If you're talking about an exploit in a vanilla H.264 bitstream with nothing particularly weird in it in a totally standard ISOBMFF container with no unusual extensions (like that one MP4 atom with a name I forget that lets you loop fragments or something), then it's not necessarily going to be trivial to exploit a decoder... But if you're talking about exploiting a video player like VLC or MPV with a file that ends in .mp4, it's a lot easier since you can choose from a myriad of different formats in a myriad of different configurations. Hell, just recently there was an exploitable libpng vulnerability, and PNG is, and I am not exaggerating even slightly, thousands of times simpler than even H.264 constrained baseline, and H.264 is hundreds of times simpler than AV1, and AV1 is thousands of times simpler than the sum of all obscure video, audio, subtitle, font, and thumbnail image formats that every major video player will happily try to decode for you.
Give the average gstreamer-based media player the right file and it will literally execute 6502 bytecode in an emulator, a la https://scarybeastsecurity.blogspot.com/2016/11/0day-exploit-compromising-linux-desktop.html.
Please don't pack your post with acronyms you expect everyone to understand. Not everyone has same knowledge as you. You can say 'do your research' but many acronyms are generic with many results I would imagine not related to the topics at hand.
EDIT: Ok, I did look up the abbreviations and got the general gist of it.
Anyway, on more reading I am seeing several recommendations to use firejail instead of lxc since it is made specifically from a security perspective, while lxc is not. So maybe firejail is more suited to my use case?
There are mixed replies in that thread.
One such one in support of containers over vms in some use cases:
Yeah that's true, but the same could be said with VMs if you use e.g. SELinux within it. It's just easier to tighten up a container. It depends on threat model and whether or not any effort is put into seccomp sandboxing, which makes a huge difference.
I expect most people in here to at least know CVE and LPE. As for DSA/RHSA/GLSA, those are just Debian's/Red Hat's/Gentoo's names for their security advisories. kCFI is kernel Control Flow Integrity, and RAP is a PaX/grsecurity-produced CFI implementation. VT is virtual terminal. Oh, and gkh is Greg Kroah-Hartman. He's a person.
A few years ago, there was a major release of severe firejail vulnerabilities that left a bad taste in my mouth. I have no idea if it has improved since then. I'm sure a quick search on oss-sec for firejail will be enlightening.
Honestly, in terms of security, you're in a tough spot. The impossible trinity in security is "performant, simple, secure". You can get something performant and secure with hardened Gentoo and a tight SELinux policy, but it's not gonna be simple. You can get something performant and simple with stock Debian, but it won't be particularly secure. You can get something simple and secure with Qubes OS, but it's gonna be heavy on resources. There's no one-size-fits-all.
I am not saying vms can't but they are not relevant to my OP since I am not able to use them anyway.
The question is how to gain a similar level of security that I was getting using a vanilla livcd OS vm in a container or other means while also having as close to baremetal hardware functionality as I can get.
Hey even my vanilla livecd vms might be seen as 'terrible' from security purists but they worked fine as far as I know for the couple of years I used them for this use case so a similar level would be fine - or better as a bonus.
Most importantly, what's your threat model?
I just wanna run videos or games from those certain sources which one does not pay.
So what threat model does that entail?
Then in that case, you'll want to protect yourself from opportunistic, for-profit malware authors. They are not the kind of adversary who will exploit 0days often (and when they do, it will just be to inject their malware EternalBlue-style, not to establish advanced persistence or move laterally), but there are a lot of them and they will punish mistakes and slip-ups severely (ransomware will happily overwrite your "offline" backups once they are mounted read/write on an infected system).
In your case, you'll probably want to look at an atomic distro like Fedora Silverblue, which is optimized for container-based workflows and prioritizes security. Being atomic, it makes it very easy to keep the system in a known-good state.
Thanks. With that said though I have been consuming from such sources, on and off, for over 25 years now and can recall only 2 instances to my mind where I could say anything has happened. In most of that time I had no security consciousness at all.
I have upped my game though in recent years hence the post as I realise that if it did happen it could be catastrophic for something I use only for minor entertainment now and then. That is why I started doing anything like that in vms, which, as per the OP, is no longer suitable for this modest machine.
The last one was recent though and happened within a passthrough vm. What I would usually do is disable the network before running the program but must have forgotten and got an unusual popup in a game in the same font as the game's on death stating 'click here to reroll your character' or somesuch. Then when I rebooted and turned off the network it went away again.
So you are recommending a container approach over firejail then?
Most attackers like that are opportunities who are spreading a large net, not going after you personally. They're like a bear: You don't have to run faster than the bear, you just have to run faster than the guy next to you. They go after low-hanging fruit because they are plentiful, and their sophistication (which, don't get me wrong, can be remarkably impressive) is all about optimizing their big net rather than trying to penetrate hard targets.
The best ransomware in the world can't attack your backups over an airgap, and no one is going to try to break your kernel, escape your hypervisor, and hide in your UEFI just to run a Peer2Profit-style malware proxy that earns them a few dollars a day per person.
Yea I get that, I did marketing for many years, so know how that goes.
Not ransomware of course but the wide net is just the same idea.
The question still is what is adequate for that, you say the fedora container one not firejail?
Yes, I'd recommend Fedora Silverblue. It uses Flatpak which is similar to Firejail but is better supported and has much less of a history of nasty vulnerabilities. Fedora also keeps its packages pretty up to date (unlike Debian-based distros) which is not only nice for security, but is nice for performance when you're gaming, too.
Oh, I have heard a lot of hate for flatpak as well though! Not along security lines but more bloatware and suchlike from the general linux space. Or perhaps I am thinking of another one of those ones. I know docker gets hate and I also hate it as I have used it a bit and couldn't stand all the spam mounts in
df -h. I think it was another one besides docker though that was also getting hate, but can't recall if it was flatpak now or not.Oh yeah, I personally hate flatpak (I hate Snap more though, since putting applications with bundled dependencies on SquashFS is insane!), but not for security reasons. It results in a lot of duplicate code since you might have 5 different versions of the same library spread over several flatpak applications all because no one wants to be the package manager who's job it is to make sure that all the applications in the distro's repo play nice with the same dependency versions.
But that's just an example of the impossible trinity I mentioned earlier. Flatpak hits "simple" (aka easy to use) and secure, but as a result, performance suffers. It's just in this case, performance refers to storage space and memory bloat rather than speed. For your use-case though, even on an older system, it's perfect.
Don't forget snap
Indeed, these are totally different use cases though eh? I mean I don't want to use any of them for my 'dailydriver' OS. I just want them for the purposes of security to roll an OS for this small use case. I am just reading up on Silverblue and seems like the same case - immutable OS sounds horrible to my minimalist, cli loving mind, but for simply running videos and the security aspect it might be fine. Sounds like it would even be a problem if wanting to run games or even videos for that matter as even these livecd OSes I use I will might do a couple of commands per session and repeat each time - not a problem since I don't do it that often. Can you not save anything on immutable? or you just can't install anything on it? I read you don't even have root access. It sounds like a phone android OS which requires quite a bit of tinkering to allow that kind of capability.
First time I am aware of immutable OS, why do you recommend this over just a 'normal' distro but using a snapshot which would be reloaded each time?
Yea that is the one I think, I knew it was another short catchy name. I think flatpak might have been described as the best of the three.
You can save files on an immutable OS and even upgrade it and change configuration files, but you can always roll back to a known-good state if you want. It's like a really, really polished live distro. The overall concept is the same: A read-only layer with a writable filesystem overlayed on top of it. With a typical live system, that'll be squashfs and tmpfs merged with overlayfs, where the downside is that every change you make to tmpfs gets wiped on boot. An atomic distro is similar, but the writable filesystem is non-volatile, so it persists across boot. Because it's "atomic", the base system is either fully updated all at once, or it's not updated at all. You never get into a half-updated broken state.
If you love lightweight and minimal, try Fedora Sway Atomic (https://fedoraproject.org/atomic-desktops/sway/), which uses the tiling window manager Sway (which is similar to i3, but for Wayland).
That's fine, but it's easier if you're using different machine. If raspberry pi is too expensive, android set-top box might be the best option if you don't want old hardware. It's usually $20-30 new, used $6-10.
Yes. I hate bloated binaries. Multi-gig docker image aren't rare these days
I don't think that there is so much of a performance hit using kvm as you are assuming.
It essentially depends on the type of workflow/how secure you want.
There are always tradeoffs and you have to work with those tradeoffs. I don't really know what might be the best use case as such for you personally then, but kvm is good imo fwiw (especially when you try with firecracker, you realize that the bottleneck doesn't feel to be kvm)