1/5

I've been thinking about what should be the security boundary between the vendor and user part in a mobile Linux and enterprise environment. Most real-world attacks I have seen don't really use kernel exploits, they rely on running untrusted executables, or tricking users or services into executing script payloads (like curl | sh) or inline commands (bash -c "./certified-malware"). The attacker's primary goal is persistence or data exfiltration through arbitrary code execution.

2/5

With usr-merge in modern distros, distro-provided executables and shared libraries now live under /usr, which can be seen as a reasonable security boundary for the vendor-managed part. The idea is simple: on image-based distros (GNOME OS, KDE Linux, etc.), dm-verity can be used. On traditional package-based distros (Fedora, AlmaLinux, etc.), fs-verity can be used. See https://fedoraproject.org/wiki/Changes/FsVerityRPM

3/5

The interesting part is combining this with IPE. A default-deny policy could allow EXECUTE only for files backed by a trusted dm-verity volume or a valid fs-verity signature.

4/5

Package-based distros might also need an additional SELinux policy to ensure that /usr cannot be modified by anything other than the package manager, as fs-verity does not prevent deletion attempts on a writable filesystem.

With all that, system executables and shared libraries cannot be modified, and IPE prevents executables from being run even if an attacker can write elsewhere. Yay, we almost solved the problem ;)

5/5

The final piece of the puzzle is: how do we stop interpreters like Bash, Python, and Perl from executing untrusted files or commands? This is also the hardest part. From what I gather in https://docs.kernel.org/userspace-api/check_exec.html, it seems that this can also be done. Obviously, you also need kernel lockdown, secure boot, and measured boot, etc., for further defense in depth. But more or less, with all this, it seems to solve the problem, so I would say it is good enough. :D

cc: @etbe @jmorris @roddhjav @mjg59 @kpcyrd @jvoisin @l0kod @grimmauld @securepaul @alexhaydock @cas

Sounds sane? :P

@tris the most sustainable approach for package-based distros is probably something similar to the flatpack-sandbox, but mounting /usr from the host into the sandbox, together with a stub /etc. Capability bounding sets can be used to prevent uid changes necessary for deletions/modifications on the mounted /usr. Access to pictures, downloads, documents from $HOME only possible when asking the user for access through a file picker first. This kind of model is also used by macOS and phones.

@kpcyrd That's a good idea, I think there is plan to move sandboxing part to systemd-appd, so even package based distros can use it. I'm not sure how it works. My over-complicated idea from earlier on network inspection: https://chaos.social/@tris/116885133726716538 xD

@tris @etbe @jmorris @roddhjav @mjg59 @kpcyrd @jvoisin @l0kod @grimmauld @securepaul @alexhaydock @cas Sounds like what we want to build with GNOME OS :)

Not with IPE though. Instead, systemd will be able to have an IPE-like feature implemented via bpf-lsm, where things are more flexible. For instance: we could allow unsigned code to execute if it's sandboxed.

This way: the security profile changes to "only signed or sandboxed code can run on the host"

@AdrianVovk @tris @etbe @jmorris @roddhjav @mjg59 @kpcyrd @jvoisin @l0kod @grimmauld @securepaul @alexhaydock

probably @craftyguy has done a bit of thinking about this for Duranium, but i imagine we'd wanna go with a similar if not the same approach as GNOME OS here. Allowing untrusted code to run in a sandbox definitely feels like something we'd want although I'd be wary to make that the de-facto mechanism for running software and lean on a trust mechanism through flathub for most user software.

I am increasingly leaning towards the use of "pet containers" for developers and enthusiasts, but it's very easy to wind up in a situation where exploiting a pet container gives an attacker largely the same access to user data as a host exploit would (like if your home directory is mounted in for example)

i don't really have any bright ideas for this off the dome, the situation i really want to avoid is the one where users effectively become their own adversaries, if security mechanisms get too in the way then folks will just disable them -- so a sliding scale might make sense.

to put it another way, it's clear that there are various approaches to implementation, personally i don't care much for those details as i'm more concerned about providing solid UX. Keeping users informed about how the security on their device works and trying to ensure that if they take steps to limit or bypass security mechanisms that we can follow an informed consent model and only poke holes where it really makes sense to.

on a related note there, it would be really interesting to experiment with a peer to peer trust model for code signing and be able to extend that into non-flatpak sandboxes and more generally as a first-class mechanism in the distro to help you analyse the risk of running some particular code (ok yeah im getting super into the weeds here but i think the gpg circle of trust had some potential!). This could be done for binaries but could totally be extended for source code as well through commit signing

aaaanyway, yeah relying purely on trusting large entities like flathub is fine, but there are clearly unsolved problems to enable developers to do their thing without them having to jump through hoops to maintain security or forego protections.

@cas @AdrianVovk @tris @etbe @jmorris @roddhjav @mjg59 @kpcyrd @jvoisin @l0kod @grimmauld @securepaul @alexhaydock @craftyguy it depends what your threat model is - if you want to protect the host that can work, but if you want to protect your electricity bill or network, then that won't be enough. Also beware that the bpf-lsm solution requires building a kernel without kexec to be effective, or it can be trivially defeated

@bluca @cas @tris @etbe @jmorris @roddhjav @mjg59 @kpcyrd @jvoisin @l0kod @grimmauld @securepaul @alexhaydock @craftyguy Sure. Nothing is quite so black and white. You can protect your electricity use and network use via cgroup limits as well. Of course the ultimate protection would be "only known code can execute period", but that's probably too rigid for general purpose desktop operating systems

@AdrianVovk you could do this with IPE if desired, it is intended to be extensible (I would use an SELinux label associated with the sandbox), but it does need static kernel code modification vs BPF JIT.

RE: https://fosstodon.org/@AdrianVovk/117043284020566593

@AdrianVovk and btw, a related problem needs to be solved for confidential computing payloads, where IPE is not the source of trust but is needed to authorize execution of code which is runtime-installed in a confidential domain. i.e. enforce delegated trust.

@tris running "bash /tmp/foo" doesn't require executable checks on /tmp/foo so a lot of the access controls are skipped. From a MAC system perspective reading a data file and executing a script are the same. You could modify bash but that would require changing lots of system scripts. Then there's the issue of pasting shell scripts into an interactive bash session.

@tris It would be a good experiment to patch a system with all interpreters using such checks and see how much breaks. I expect that there's more than a few accidental omissions of the X bit on files to deal with.

@kpcyrd @tris I think it would be really good to have Flatpak/Snap type controls over packaged programs. So you get all the security updates to libraries and verification that the distribution provides (last time I checked some snaps the ones I could determine appeared to lack library seurity patches and for most of them I couldn't easily determine which version was used for some critical libraries) and the lockdown of Snap/Flatpak containers.

@tris @kpcyrd For a single user development system having a different UID for certain tools is an option.

When running SE Linux you could user user_t:s0-s0:c0.c1023 for your login and then drop some of those categories to run certain programs and add some categories to files in your home directory etc which limits the damage that can be done.

I run all my builds in bubblewrap which is working well for me.

Sandboxing cat etc wouldn't really work, but sandbox a development shell session does

@AdrianVovk @bluca @cas @tris @jmorris @roddhjav @mjg59 @kpcyrd @jvoisin @l0kod @grimmauld @securepaul @alexhaydock @craftyguy currently in FOSS OSs we are barely at the level of "personal firewall" being viable. Protecting network use would be a good thing, but there's lots to solve first.

@etbe That's a fair point

@etbe @kpcyrd > Sandboxing cat etc wouldn't really work, but sandbox a development shell session does

Reminded me of https://archive.is/sG4FX :P

@etbe @AdrianVovk @bluca @cas @tris @jmorris @roddhjav @mjg59 @kpcyrd @jvoisin @l0kod @securepaul @alexhaydock @craftyguy I think personal firewall is a solved issue actually. Look into https://github.com/evilsocket/opensnitch. It does its monitoring by one of ebpf/audit/proc fs/strace, and supports nft/ipt as enforcement layer. Works quite well.

@etbe @kpcyrd Android gets this largely right. As I understand it, SELinux on Android mainly enforces policy based on process domains rather than confining individual executables. Bringing an Android-like SELinux model to desktop Linux would require an enormous effort. I think that's why @AdrianVovk has been reluctant to use MAC as the primary security mechanism in GNOME OS, he sees it as more of defense-in-depth measure

@grimmauld @AdrianVovk @bluca @cas @tris @jmorris @roddhjav @mjg59 @kpcyrd @jvoisin @l0kod @securepaul @alexhaydock @craftyguy I've tried opensnitch and it basically does the job. But there's lots of fiddly stuff between basically doing the job and being something that a newbie could reasonably use. It's moderately easy to allow stuff but really hard to remove or edit things that you allowed. Not impossible to solve just a bunch of coding and testing.