search

AppImage / AppImageKit

Package desktop applications as AppImages that run on common Linux-based operating systems, such as RHEL, CentOS, openSUSE, SLED, Ubuntu, Fedora, debian and derivatives. Join #AppImage on irc.libera.chat
http://appimage.org
Other
8.58k stars 547 forks source link

Investigate AppArmor #452

Open probonopd opened 6 years ago

probonopd commented 6 years ago

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

So, here is our plan:

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

zyga commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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. https://github.com/AppImage/AppImageKit/issues/452#issuecomment-322594059

komachi commented 4 years ago

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 commented 4 years ago

Nice work. Could serve as a starting point for proper per-AppImage profiles. IMO only application specific profiles will provide a good experience. See https://github.com/TheAssassin/AppImageLauncher/issues/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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.