Investigate AppArmor

[probonopd]

In this GUADEC talk @sysrich describes the "crazy insecure lunacy of AppImage".

So, here is our plan:

• By default, AppImages lack the executable bit
• With the optional appimaged daemon installed (which distributions could opt to do in their default installation), check for embedded signatures
• Depending on the trust level of the signature, three things could happen a) the AppImage gets integrated into the system and is made fully executable without a sandbox (e.g., this could be configured for AppImages signed with the distribution's key), b) the AppImage gets integrated into the system and is sandboxed with a moderately conservative profile (this could be done for other signed AppImages) c) the user sees a warning that the AppImage is not signed (similar to what macOS does in the default configuration) and that this app wants to do a b c d e f g (depending on what its Firejail/AppArmor profile defines)
• Establish a crowd-sourced GPG-based "web of trust"
• AppImageHub will display information about signatures and the level of trust

We could do this by

1. Integrating firejail and signature checking into appimaged, or
2. as @sysrich suggests, use AppArmor

1 has the advantage that it works today, 2 has possibly other advantages that need to be investigated.

2 is apparently dependent on some patches that need to be upstreamed by Canonical.

Any thoughts, insights, discussions, contributions welcome!

[zyga]

Hey

I think that @sysrich is right and you should use apparmor simply because it is far, far more intuitive. The apparmor and selinux (apart from scope recently, where apparmor is growing tons of features) mainly differ in how it matches human perceptions.

Having said that apparmor is just a wrench. You need a screwdriver and a hammer too: seccomp and IPC (dbus) confinement support IMO. Having all the tools you need to build a policy that is actually meaningfully secure and allows developers to understand what is going on, what is allowed and what is not.

My 0.02zł, if can, is to consider how to take advantage of the snapd policy. The policy exists, it maintained and it has existing developer adoption.You will be building on something that's been used for a few years across phone, server and recently desktop projects. It remains to be seen how to integrate this into appimage itself (we should have a call about that) but I think this is far more sensible and doable than coming up with a brand new policy by yourself.

As for integrity checks, this is, I think, much more understood but I wonder what apart from integrity do you want to check. I bet if eventual appimage malware shows up it will be well-signed. What is the root of trust? What is the revocation process. I'm curious to hear your ideas.

[probonopd]

Hi @zyga thanks for your thoughts.

This is my curent (superficial!) understanding of the situation, let's fill in the blanks. I'd be very happy if we could collaborate on this, even though I am not sure a "sandbox monoculture" would benefit actual security. I don't claim by any means that I am an expert in this subject, so I'd welcome discussion.

	Firejail	Bubblewrap	AppArmor	SELinux
Used by	appimaged (rudimentary)	Flatpak	Snappy (with patches), openSUSE	Red Hat
Needs special kernel support	No	No	Yes	?
Known to work on most distributions today	Yes	?	?	?
Level of security	?	?	?	?
Known to work on most distributions today	Yes	?	?	?
Can ship profiles in AppImage	Yes	?	Yes	?
Pros	Straightforward, has native AppImage support already	Known to work with AppImage relatively easily, might benefit from ongoing Portals work	2 out of 3 large distributions use it
Cons	Needs suid	Needs suid	Needs kernel support, "complicated"?	NSA pedigree, "complicated", many users disable it

[zyga]

Level of security is asking the wrong question. It is like asking if sudo is secure without asking for the configuration file.

[zyga]

The first step towards figuring out what you want to do is to define the threat model. What are you going to use $TOOL to defend against? Firejail and Bubblewrap are layers on-top of kernel features. You can largely ignore those and just ask which kernel features are you going to use.

[probonopd]

Firejail apparently now supports running AppImages using AppArmor:

Also, we have full AppArmor support for AppImages:
$ firejail --apparmor --appimage ~/bin/Kdenlive-17.12.0d-x86_64.AppImage

What does everyone think about this?

[TheAssassin]

Big words, but not very meaningful. Firejail has native AppImage support, but the profile it uses is so generous it doesn't really prevent that many problems. Without knowing what exactly the sandboxing does, it shouldn't be advertised as "security feature".

Level of security is asking the wrong question. It is like asking if sudo is secure without asking for the configuration file.
#452 (comment)

[komachi]

I tried to confine AppImages with AppArmor, and here is abstraction I came up with https://github.com/komachi/apparmor-even-more-profiles/blob/master/profiles/abstractions/appimage

This is not perfect due how AppImage works (well, it loads files from /tmp where anyone can write), but it works at least.

Also https://github.com/AppImage/AppImageKit/wiki/Similar-projects should probably be edited: you can't count firejail as apparmor support, and even with my abstraction it's not very "sandboxed" because of /tmp).

[TheAssassin]

Nice work. Could serve as a starting point for proper per-AppImage profiles. IMO only application specific profiles will provide a good experience. See TheAssassin/AppImageLauncher#99 for more information.

The type 3 we've started to work on will no longer rely on /tmp but use some per-user tempdir (e.g., /run). That'll fix that problem then.

[komachi]

Without application-specific profiles nothing gonna work, as AppArmor is MAC (whitelist-based model) and enforced profile means app wouldn't get access to anything that is not allowed in profile.

So that abstraction is not enough for specific AppImage to run, that's just an abstraction that allows you to create profile like your can for any non-appimage app. Here is profile I use for specific application packed as AppImage using appimage abstraction https://github.com/komachi/apparmor-even-more-profiles/blob/master/profiles/usr.local.bin.mycrypto

For proper sandboxing there is need not just for per-user tempdir, but a per-application tempdir which path is predictable (e.g. could be specified in specific AppArmor profile for an application), otherwise any appimage-packed app can get access to other appimage-packed apps data. It doesn't clear from README how type 3 would work in that case and I didn't look into sources yet, but you can't get proper sandbox with AppArmor without this implemented.

Firejail is nice, but sandboxing capabilities of firejail is limited by it's design, so it would be better to support something that works as LSM (such as AppArmor).

[probonopd]

I'd rather like to have a model where the app can say "I need Internet access" and then the user can say "grant Internet access to this app".

Would this be doable with AppArmor?
Probably the AppArmor profile would need to be shipped inside the AppImage, and whenever the AppImage is executed then some wrapper would need to read the AppArmor whitelist and check (e.g., by asking the user) if the permission the app wants to have are OK.

[komachi]

Limiting internet access is generally possible by AppArmor, although it doesn't work on Debian for now. As man page says:

Some features are not supported on Debian yet:
Network Rules
DBus rules
Unix socket rules

As for deep integration with AppArmor, it's possible with libapparmor, but lacking proper docs.

[probonopd]

OK, then AppArmor and I seem to have different concepts of "security". Disabling network access, disabling DBus access would be some of the first things I would want from a sandbox...

[komachi]

That not because AppArmor doesn't want to support it, userspace utils support network rules, but it require kernel patches (available here) to work. It was available as out-of-tree patches on Ubuntu. Since kernel 4.17, socket mediation available mainline, but it will work only in upcoming AppArmor 3. See also this debian bug.

Sadly there is nothing we can do without kernel patches.