Label flatpak installations appropriately

[matthiasclasen]

Flatpak installs applications in a few places:

• System-wide applications: below /var/lib/flatpak/app
• System-wide runtimes: below /var/lib/flatpak/runtime
• Per-user applications: below $HOME/.local/share/flatpak/app
• Per-user runtimes: below $HOME/.local/share/flatpak/runtime

E.g.

/var/lib/flatpak/app/org.gnome.PortalTest/current/active/files/

is the root of the tree that gets mounted readonly at /app inside the sandbox when running the org.gnome.PortalTest application, and

$HOME/.local/share/flatpak/runtime/org.freedesktop.Platform/x86_64/1.4/active/files

is the root of the tree that gets mounted readonly at /usr inside the sandbox of apps using version 1.4 of the org.freedesktop.Platform runtime.

These should get suitable selinux labels.

See https://github.com/flatpak/flatpak/pull/189 for proposed flatpak changes that will assign unique exec and file labels during sandbox setup.

[rhatdan]

We probably want to have one process type. Something like sandbox_net_t, or a new one container_net_t.

• process types
  • container_net_t
• File Types
  • usr_t
    We need to look at having a label for content on the host system that is read only. I think we should just stick to usr_t, and allow the container_net_t to RX all usr_t.
  • container_ro_t
    We need a similar label for content in the users home directory. We want to allow a confined user to write this content, so we need a type different then usr_t.
  • container_rwx_t
    This would be the type for all containers to be able to RWX. This would be the label that all containers can write;
• MCS Labels
  • We would use the same strategy for all container :s0 is RW for all containers, so containers can share content with container_rwx_t:s0 label.
  • s0:c1,c2 for private content.

[rhatdan]

@wrabcak @mgrepl PTAL

[ghost]

On 07/28/2016 04:58 PM, Daniel J Walsh wrote:

We probably want to have one process type. Something like sandbox_net_t, or a new one container_net_t.

• process types \ container_net_t
• File Types * usr_t
  We need to look at having a label for content on the host system that is read only. I think we should just stick to usr_t, and allow the container_net_t to RX all usr_t. _container_ro_t
  We need a similar label for content in the users home directory. We want to allow a confined user to write this content, so we need a type different then usr_t. *_container_rwx_t
  This would be the type for all containers to be able to RWX. This would be the label that all containers can write;
• MCS Labels * We would use the same strategy for all container :s0 is RW for all containers, so containers can share content with container_rwx_t:s0 label.
  * s0:c1,c2 for private content.

Consider making MCSSEP optional and tunable runtime or at least buildtime. MCS is an optional security model that provides optional functionality of separation. If you depend on that then that is less flexibility. MCS is compelling but just TE for integrity (not separation) is also compelling on its own.

Also consider making the portal an SELinux object manager

We need

---

You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/fedora-selinux/selinux-policy/issues/142#issuecomment-235920939

Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift

[matthiasclasen]

We would use the same strategy for all container :s0 is RW for all containers, so containers can share content with container_rwx_t:s0 label. s0:c1,c2 for private content.

Does this mean I need to skip c1,c2 when generating unique labels ? I didn't notice that in the docker code.

[rhatdan]

For shared labels like the read/only ones you should just install with s0 labels, probably do nothing at all, and let SELinux handle it. Only private content needs the c1,c2 stuff. When running an app for the first time, I would allocate the unique categories and label user content and record it for the next time.

This way a second user using the same application would be able to share the read/only content but have his data be private. If a user wanted to create a second instance of the app say an internal firefox and an external firefox, you would also generate a new unique mcs label.

[matthiasclasen]

Yes, I'm doing all that. But the code I have for generating unique mcs labels might well generate s0:c1,c2. I just want to know if I should skip this label because it has special meaning

[rhatdan]

No sorry s0:c1,c2 is an example it has no special meaning. s0 is special.

Let me explain.

MCS Policy is about dominance. The category s0:c1,c2 is allow full access (If type enforcement allows) to content with the MCS Labels

s0:c1,c2 s0:c1 s0:c2 s0

Now look at s0:c1,c3 it "dominates"

s0:c1,c3 s0:c1 s0:c3 s0

So s0:c1,c3 would not be allowed to access content labeled with s0:c1,c2.

There fore the algorithms we use always use 2 categories, and the categories can not be the same

s0:c1,c1 == s0:c1

Also order does not matter

s0:c1,c2 == s0:c2,c1

Since we never use single categories, all containers can write to their MCS label and to s0.

[wrabcak]

@matthiasclasen

I know, I'm asking two years after but, how it looks now, should I work on this?