Base runtime freedesktop-sdk-runtime-19-08

I agree with this sentiment. We used to do something similar to this with the ‘frameworks’ concept in snappy 15.04 (which is long gone now) where SDKs, runtimes, etc could explicitly declare security policies for using the framework which would need human oversight for design and approval. It was actively decided for the redesign that we would not bring this concept forward in any capacity and out of that came the interfaces system.

IME, runtimes are different from interfaces but share some important characteristics. We often talk about how interfaces form contracts between the slot and the plug. I would argue that base snaps form a contract between the runtime and the consumer of the runtime. As such and for the same reasons we do this for interfaces, snapd should encode the runtime’s security policies (whether they are lenient or not is an implementation detail). snapd is implicitly doing this today, but assuming core policies are correct, so we just need a mechanism in snapd to define the base runtime policies and when to use them. In this manner, the base runtime developer doesn’t need to do anything special in the snap, but does need to work with the snapd team on the security policies. This is analogous to adding and maintaining a new interface (but keying off the value of 'base: ’ instead of adding new plugs/slots).

Possibly but that depends on my points above. If we use fine-grained policy, there is a maintenance burden, but it importantly provides an opportunity to curate and declare that the exposed binaries are always expected to work cross-distro.

Let’s say that a base did include a binary that didn’t work cross distro? Does that mean that the base snap would have to provide different policy for each host system it runs on top of? That’s starting to sound like either (a) something that shouldn’t be in the base snap, or (b) out of the scope for the security policy.

I guess my feeling is that we should treat these third party bases the same way we treat application snaps: that we should try to control what those executables could do rather than control access to the libraries/executables themselves. As far as automated review of third part base snaps goes, I think it would be reasonable to require the following:

  1. consists of only regular files, directories, and symlinks
    • Rationale: while snaps are mounted nodev, it is probably worth ensuring the base doesn’t include any device files anyway: we don’t want device files at unexpected paths to be used for privilege escalation should the mount security fail. It’s also possible that fifos in the file system could be used for communication between snaps in unexpected ways too.
  2. all files in the snap satisfy st_mode & ~0777 == 0
    • Rationale: the base snap should not enable setuid/setgid privilege changes. As the snap is not intended to be bootable, there is no rationale for including utilities like su, sudo, pkexec, etc.
    • There’s a good argument for mounting such base snaps with nosuid too.
1 Like

This is what we want for Freedesktop SDK. We do not need anything special. We only provide files, some are executable, and there is no suid or sgid. I believe most of 3rd party base runtimes will want the same.

1 Like

FYI, we met this week at the sprint and discussed this topic; thank you for being patient while we work through the processes and implementation for enabling base snaps like the freedesktop-sdk-runtime snap. We’ve agreed to take the approach that we will have a single base policy that is separate from the default template, that is mostly open, except for the areas where we overlay portions of the host fs onto the runtime (eg, when overlaying /etc, continue to not allow /etc/shadow). We will also refine our Process for reviewing base snaps a bit and make updates to the review-tools for base snap checks.

This requires a fair amount of unplanned engineering work, but we’ll work towards getting that into 2.42 or so.

1 Like

This won’t be in 2.42, but is now scheduled to start in November. Sorry for the delay on this, but once the work is completed, this will make everything straightforward in terms of reviews, processes and new base snaps.

@jdstrand, any news about it? Will there be some progress any time soon?

Yes, the work is scheduled, roadmapped for this cycle and assigned to me. I plan to start on it most likely next week. It will not make it for 2.43, but should for 2.44.

1 Like

@jdstrand any more updates on this?

I know this keeps get pushed back but it is literally at the top of the queue now and I hope to start work on it this week.

This feature also requires changes to the review-tools to expand the checks for base snaps. I did that a little while ago and this is in production in the store.

I’ve just now submitted which, when it lands, will (finally) allow freedesktop-sdk-runtime to be usable by other snaps in the store.

cc @kenvandine


FYI, this was just now merged and will be in 2.45. The changes should be in tonight’s edge snap. Please test freedesktop-sdk-runtime-19-08 with core/snapd from edge and let us know if you have any issues.


@jdstrand, I have just tested quickly and the new apparmor profile with edge snapd seems to fix our issues.

Through I will have to do some cleanup and little fixes before I submit it to the store. But now the ball is on my side.

Thank you!

FYI, all the prerequisites are in snapd 2.45 now and I updated Process for reviewing base snaps with some additional details so this request can move forward whenever you’ve confirmed that your snap is ready.

I have reuploaded a newer version. It is freedesktop-sdk-runtime-2008. I also uploaded freedesktop-sdk-sdk-2008. This is the full SDK which is needed for development applications (e.g. GNOME Builder). Those are beta uploads (they are in edge track). We are going to have the first release of 20.08 in few weeks.

  • Base snaps shall not use tracks"

Does that mean I can only upload stable?

And I will upload other architectures when x86_64 has been vetted.

Ping @jdstrand ,

Will there be a new review?

I missed this question when it appeared. No, you can upload to latest/edge latest/beta etc.

But snapd will always only auto install the base from latest/stable. For testing you can pre-install the base alone with snap install --channel and then install snaps that require it for testing. They will use the base as installed from the risk you chose.

Yikes, sorry for the delay on this! Since this is our first community base snap of this nature, I’m going to follow Process for reviewing base snaps rigorously so other @reviewers can more easily participate.

The snap’s name is freedesktop-sdk-runtime-2008 which is compliant with the ABI naming convention we are looking for. The snap does not currently use assumes: [ snapd2.45 ].

  • @valentind - can you update the snap to use assumes?

@valentind - there is a strong preference for base snaps to be maintained by a community or project. You are currently listed as the publisher with no collaborators. Would it make sense to create a ‘’ username, adding yourself and others as collaborators? If you are amenable to this, perhaps @popey or @roadmr can assist with the process?

The base contains all the necessary empty directories for snap-confine (this is verified by the review-tools).

All the files in the base are root/root with no unusual permissions (this is verified by the review-tools).

I used unsquashfs -lls /path/to/snap |grep -E 'squashfs-root/(dev|etc|home|lib/modules|lib/firmware|mnt|media|run|proc|root|snap|var/snap|sys|usr/lib/firmware|usr/lib/modules|usr/lib/snapd|usr/src|var/lib/dhcp|var/lib/extrausers|var/lib/jenkins|var/lib/snapd|var/log|var/tmp)' and found the following:

  • there are files in squashfs-root/etc
  • there are files in squashfs-root/proc

@valentind - can you use stage in your snapcraft.yaml or otherwise remove the files in these directories (but not the directories themselves)?

I then noticed it is shipping:

  • squashfs-root/app
  • squashfs-root/snap

These are not going to be available to the snap at runtime because the default base template policy does not allow them.

@valentind - can you remove these?

@valentind - can you comment on each of these:

  • Will you not request using tracks for this snap?
  • Do you commit to not intentionally break consumers of this snap? (Eg, by removing files, changing ABIs, etc)
  • Do you commit to be responsive to bugs and regressions caused by updates to the snap?

Assuming the that @valentind answers in the affirmative to these questions, cleans up the snap in the requested ways and ideally creates a community/project username with collaborators, I think this snap can undergo publisher vetting.


@valentind - as an aside, the snap is shipping quite a lot, which is fine, but I want to mention that once approved and you’re on your way, future uploads will be automatically checked to verify if files are dropped from the snap or ABIs are dropped and if that happens, the revision will fail review. For the smoothest experience going forward, I highly suggest that you prune the snap to just what you want. It is fine if you choose to only make the minimal changes I requested, but I wanted you to know how the process works for base snaps.

Thanks for your work on this!

1 Like