sandboxing linux programs

How do you sandbox your programs in Linux OSes? I have been personally been using intgr's alter ego to run things as a different user. I do share the X session with other users, but I only trust in Wayland windows and run all potentially sensitive programs via Wayland since theoretically it doesn't allow for snooping in the same way that X does. I also followed madaidan's hardening guide in order to hide processes from other users, and to restrict dangerous syscalls like ptrace.

If you don't trust a program don't run it. If you absolutely need to run it, run it in a VM or on a seperate, airgapped machine.

firejail + AppArmor is an OK set-and-forget default. Prevents a lot of the more basic exploits like modifying bashrc files. I use it for any program that may have a vulnerability and interacts with the internet in any way. For example, I always use firejail with MPV because of mp4 exploits. As the above lainon said, don't run a program you think might be malicious. But it's pretty much impossible to not run a program that could have security vulnerabilities.

qubes is the only reasonably usable way

>>22607 I generally don't run possibly sensitive or sketchy programs on my base system. For that you'd wanna be using VMs. For stuff I trust but just don't want to give excessive permissions, Flatpak is honestly fine when combined with flatseal disabling all access to stuff it doesn't need to function. "BuT flAtkiLl.orG!!!" Flatpak is fine for what it is. It's not gonna save you from being a dumbass any more than Windows Defender can stop grandma from running invoice.pdf.exe that exploits some 0day. As long as you pay basic attention, everything will be fine. For more sensitive threat models yeah theres Qubes like >>22621 mentioned, but I don't think it's worth the effort and limited support for most people. (key word being "most")

>>22607 just use qubes. I create a disp VM with no network, run the program, close the disp when I'm done, plain and simple. each qube has its own X session, so X snooping is only relevant within a single domU, not between domU's. Hardware is also isolated as well, a VM that has access to your GPU can snoop the entire screen outside of the GPU, not a problem on qubes. >Flatpak is honestly fine when combined with flatseal disabling all access to stuff it doesn't need to function. not really, containerized solutions massively increase your attack surface, youre executing many more libraries on the same kernel

>>22761 It's not some hardcore security layer for preventing applications from affecting your whole system and it doesn't pretend to be, but i do see your point about the libraries. For me, it works fine for just being an easy way to get many different packages that may not be available via package manager and generally limiting file and device permissions for them. I wouldn't be so sure about relying heavily on it, which is why I'm not too fond of Silverblue and similar immutable distros. Qubes has really good security systems and improvements, but its limited hardware support and generally worse performance can make it somewhat inaccessible to people making it less viable of an option. Some people benefit from it for sure. But people who need to ask whether they need it probably won't benefit that much.

>>22771 Everyone would benefit greatly from having a qubes machine. We live in a dark era where nothing else is reasonably secure. Everyone has to do things that are security sensitive from time to time. The only issue is whether you can get the hardware and basic tech capabilties to use it. OP does since he is writing about syscalls and hardening guides etc

>>22607 Best sandbox is air-gap sandbox. Otherwise there are just systems that have been broken and systems that are not yet broken. If you are willing to trust, why would you need a sandbox in the first place?

>>22797 >best sandbox is air-gap sandbox arguably worse than VM in some cases, because physical machines have physical components that can be abused. >If you are willing to trust, why would you need a sandbox in the first place? Because sometimes security isn't a top priority.

>>22798 Which components on RPi even are abusable? No audio hardware, except line out without physical devices and just a cheap SD card to be overwritten destroyed if need be. You could perhaps read some kind of serial number and otherwise fingerprint the system. Other than that? Please, enlighten us if you know more.

>>22798 >arguably worse than VM in some cases, because physical machines have physical components that can be abused. This doesn't even make any sense. What's better? Digital machines that can be exploited by anyone anywhere in the world or physical machines that can be exploited only by people in your vicinity. Physical isolation is the most secure model available for computer systems, pair it with virtualization and sandboxing of applications running off virtualized machines and you're offering yourself as many layers of security as possible pretty much.

>>22801 >This doesn't even make any sense. What's better? Digital machines that can be exploited by anyone anywhere in the world or physical machines that can be exploited only by people in your vicinity Again, it depends a lot on your specific case. An actual airgap is pretty hard to manage. If your machine has any kind of wireless device then backdoors in the modem have already compromised you, as long as the modem is getting electricity. Practically every peripheral you connect to the system becomes a potential information leak, as well. A virtual machine with a strict firewall can't be exploited by anyone in the world anyway, it can only be exploited by people that exploit the host machine and/or get past the firewall. >pair it with virtualization and sandboxing of applications running off virtualized machines and you're offering yourself as many layers of security as possible pretty much. True. >>22800 presumably you have your RPi connected to some peripherals, yes? It's not just a board sitting there?

>>22801 They're probably talking about that one case where a SATA cable could transmit data wirelessly at a few bytes per second to someone listening from like 5 feet away. Besides, airgapping has nothing to do with preventing physical access and conflating the two problems is just absurd.

>>22806 Obviously any exploitable devices should be removed from a computer. WiFi, Bluetooth, webcams, microphones, speakers, and LEDs (LEDs can just be covered if necessary) are all exploitable. Anything I will mention assumes they have been removed. WiFi, Bluetooth and webcams' threat is obvious. A microphone is essentially a reversed speaker. Speakers can function as microphones and vice versa. They can and have been used to exfiltrate data out of airgapped networks, namely by BADBIOS. LEDs can also be used to exfiltrate some information to an attacker with sight of a targeted computer, but that is a sillier attack to mention since attackers would be close enough to view a computer. It doesn't make any difference for the security of a system if you're considering side channel attacks or physical exploitation. Some practices would still leave you less vulnerable to some side channel attacks, not having WiFi and Bluetooth modules as they'll boost the range of emitted EMF, but from a general standpoint the measures you've taken to ensure the physical security of a computer system would be nullified by side channel attacks. I might as well just mention TEMPEST attacks. They're the most threatening attack there is. An attacker can gather information about any process their target computer is running. They can remotely view a computer's display, grab encryption keys, decrypt messages relayed over the internet in real time. These attacks can bypass any kind of security model, airgapping, physical isolation, whatever. TEMPEST attacks exploit the very nature of electronic devices. All electronic devices emit their own electromagnetic field and emanate electromagnetic frequencies. In the case of computers, the emanated frequencies will contain information about the processes the computer is conducting. The SATA cable attack is basically just a TEMPEST attack. You can still remove wireless modules from a computer and shield a computer, but you as an individual cannot legally protect yourself effectively against TEMPEST attacks. You cannot secure the power lines and internet cable running to your domicile. Only if you're a private firm or an agency of a nation state can "you" effectively protect "yourself". Even still, shielding will not provide absolute protection, it only serves to bring EMF levels down to a level that _should_ not be recordable by an adversary, really just to a level that would prove extremely resource intensive to record. In terms of the security of a system, airgapping is the best practice, but it's completely impractical since you can't connect to the internet. A device isn't truly airgapped if it has wireless modules connected to the motherboard. Aside airgapping, if one had to compare physical isolation against virtualization, specifically the isolation of virtual machines on one single computer, physical isolation would be the next most secure model. In reality the physical isolation of computers running their own virtual machines would be the next best thing, but that's an inbetween. If you've only connected computers together with some ethernet cables for the sole purpose of distributing internet, there's no conceivable risk to anything other than their network adapter. That risk remains for virtual machines, an infected virtual machine can still discover peers on a virtual network and work to compromise them. However, malware is capable of escaping virtual machine hypervisors to compromise their host operating system. Malware on one computer is not capable of infecting another computer that is physically isolated from it. From a standpoint of suitability, obviously nothing can be best. That is subjective. But I hate seeing people say "depends on your security model." I swear that's all people say they never elaborate or even try to offer advice ever.

Everything said about Flatpak+flatseal+wayland and VMs is relevant, but I want to add that learning to script around bubblewrap for small CLI utilities (you don't want to launch something like flatpak for curl/wget) is worth it. And compared to firejail, you have much less jank (e.g. https://github.com/netblue30/firejail/issues/3001) and SUID code. Personally, I'm simply doing so with bash scripting and tedious strace debugging: https://git.sr.ht/~q3cpma/scripts/tree/master/item/bwrap_easy https://git.sr.ht/~q3cpma/scripts/tree/master/item/bwrap_auto

NSA SELinux works pretty well although it is not technically a sandbox and you're effectively stuck with Red Hat distributions. You'll also have to write your own policies for anything to work, in my experience.

>>22826 I have been meaning to get in to bubblewrap, but I just don't have time these days. Maybe I can write some scripts during my week off this December.

Would using docker containers have the same effect as Qubes? Docker seem very lightweight containers, so it's easy to run a different one for each app. But is it secure? The containers do have access to the kernel. Are there better alternatives?

>>22607 qubes or subgraphOS if/once it gets it's iso released. subgraph apperently has it's own xmpp client too.

>>22826 >is worth it they may have all my data for free for all i care i'm not spending a week stracing soykaf trying to figure out how the fuarrrk the BEST KERNEL OUT THERE YEEAAAHH YEAR OF LINUX DESKTOOOOP LIIIINUUUUUUUUUUUUX works. this is fuarrrking ridiculous. sandboxing should be as easy as invoking `ls` otherwise it may burn in hell together with flatpack, redhat and other evils of this world. i'm seething.

>>23078 Use firejail and apparmor then. They're simple to use.

>>23090 apparmor is not simple to use just look at the fuarrrking syntax god we deserve a better solution what the actual fuarrrk happens to linux i can't

>>23026 is subgraph os still in development? the last update on their blog was in 2017.

>>23097 firejail has apparmor support built in and does all the hard stuff for you. That's why it's easy to use.

I've been trying out firejail - am I just stupid or does "read-only" mean something different in Linux security land? I have "read-only ${HOME}" in my mpv.profile but every time I run mpv through firejail, it creates an .inputrc file and a .config/ directory.The .config/ directory is empty and inside the .inputrc file it says "set disable completion on". It does block me from writing screenshots though.

I tried again with "read-only *" and it didn't create .config/ or .inputrc but it created mpv/ instead.

>>23177 firejail has much more pitfalls than you can imagine, better check their github for clues. i spent hours stracing the other day to figure out why soykaf breaks

>>23176 >>23177 read-onlyness can be overwritten by later inputs in the profile, and (maybe?) by noblacklist/whitelist directives. If you're >>23078 : you are now learning that "ease of use" and "good interface" are not the same.

>>22826 >>22960 Any good guides for learning bubblewrap?

>>23210 >Any good guides for learning bubblewrap? As far as bubblewrap goes there's not much to learn, because most of your time developing bwrap scripts will be spent with other tools like strace or audit. Just quickly glance over the man page to see what options are available to you, and don't be afraid to experiment! ...but if I had to break down my workflow it'd be something like this: 1) log all files and directories the application attempts to access: `strace -e trace=file -o irssi.log /usr/bin/irssi` 2) search the strace logfile for each root subdirectory, e.g: `grep '"/home' irssi.log | grep -vE 'ENOENT|EINVAL'` 3) apply this to your script 4) cleanse and repeat until the sandboxed application works as desired Not the best or most in-depth explanation, nor did I get to explain how to integrate seccomp-bpf (these filter syscalls) into your bubblewrap script as I'm in a bit of a hurry now, but if you're interested in learning more I could do a bigger writeup sometime

>>22607 If is not need fancy graphics a VM is fine. If not , I disable by user the internet using iptables, and run away, with the proper chmod use in my root and home system already. For run programs like another user in your desktop simply add them to your xhost ( tested in debian relatives) : " xhost +SI:localuser:$user " #give rights to the user to use your desktop " sudo -S su $user " # login like that user and run the program " xhost -SI:localuser:$user " #quit rights when finished but not necessary, is not permanent

>>23526 >I could do a bigger writeup That would be pretty cool of you Lain. I'll check back in another 3 months.

Bubblejail is pretty cool. And Apparmor has good syntax. SELinux is the 'incomprehensible' one. I like to bubblejail things for a basic, quick and easy to setup sandbox, and further impose restrictions on the program through apparmor when I have time to write profiles, thus following the principle of least privilege to the degree that it's possible and without wasting hours in singular profiles.

>>24595 Is SELinux incomprehensible in sense it is difficult to use? I heard of Apparmor but not Bubblejail.

>>24596 Yeah. You should 100% run a MAC at least btw, very powerful.

>>23526 >>23771 What's the hold up, Lainon?

>>23165 Yeah wtf happened to that OS did they just take the government backed money and run or what?

>>22607 I've been trying to figure out how to securely containerize applications using LXC like steam for gaming (I know) and a kali container for fooling around with since I'm running linux on my base system anyway, but it all seems insanely complex to setup and there's not many guides for these sorts of things. I know that most people use docker nowadays for containers, but simply put I don't trust the docker engine to not be phoning home or doing other shady stuff on my system, anyone able to comment on this?

>>25555 Is Docker actually meant to be secure? I thought it was just a way to ensure similar state on different machines.

>>25559 I'm meaning secure as in doesn't phone home to some rando servers or do 'analytics', similar to LXC is

One thing that might help a little with "phoning home" is closing all outgoing firewall ports except the ones you actually need. A few of the outgoing ports you might or might not need to be open are: 9001/tcp (tor service) 9053 (tor dns) 443/tcp (https, tor browser) 123/udp (ntp) 53 (dns) 80/tcp (http) 993/tcp (imap) 465/tcp (smtp) 143/tcp (imap, ai) 587/tcp (smtp, ai/sonic) 22/tcp (ssh client) 25565/tcp (minecraft) 27015/tcp (steam) 51413 (transmission) 9091/tcp (transmission daemon) 6697/tcp (irc ssl)

>>22607 I use flatpaks duh duh

>>25562 >22/tcp (ssh client) imagine using the default ssh port lol n00b

>>25606 >imagine using the default ssh port lol n00b In the real world, script kiddies scan all of your ports and find the SSH port in a fraction of a second. Changing it to something else is useless advice repeated endlessly by clueless morons.

>>25614 I had a phase of reporting all those break-in attempts to AbuseIPDB and bruteforcers almost never went to a non-standard port. I've even set up "honeypot" client to port 2022 to see what password they are entering and there was like three bored retards doing it.

>>25614 youre forgetting that most script kitties use premade scanners, which really only target 22, 222 and 2222. move to a random port, and the amount of scanners drops by a soykaf ton.

>>25630 not that lain but i think the idea is that whether you have it on the default port or not, you still have to set it up securely to mitigate semi-motivated semi-intelligent attackers, and if you've set it up securely, there's no benefit to having it on a separate port since nobody's getting into it anyway. there's also single packet authorization or port knocking if you really want to hide that the server is open to ssh connections at all

>>25633 i get your point, but changing port takes less than a fraction of a second, and you will stop your logs from clogging up a lot. not saying moving port eliminates spam, but it does severely reduce it. but yeah, other than that, no actual bonus, especially if you've configured public key authentication, which no bruteforcer actually seems to support (yet)

>>22824 TEMPEST protection is real and should be considered, but some of what you wrote is pure schizophrenia tier nonsense. If you gap a network and follow precautions to minimize EMF as well as the precautions you outlined then the attacker would literally have to break in to your home to record those signals, and at that point he has access to the physical machine anyway.