Base runtime freedesktop-sdk-runtime-19-08

store-requests
34

Could we just a provide with the base a list of paths that need to have execution rights?

35

So how do we move forward on this?

Does the rationale for allowing fairly permissive AppArmor file access to non-bootable base snaps make sense? It seems like an option that would remove most of the need for most base snap specific policy in both the base template and interface implementations.

36

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).

37

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.

38

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
39

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
40

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
41

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.

42

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

43

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
44

@jdstrand any more updates on this?

45

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.

46

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 https://github.com/snapcore/snapd/pull/8496 which, when it lands, will (finally) allow freedesktop-sdk-runtime to be usable by other snaps in the store.

cc @kenvandine

3 Likes
47

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.

2 Likes
48

@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!

49

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.

50

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?

51

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

52

Ping @jdstrand ,

Will there be a new review?

53

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.