Hey folks,
Picking up where we left off in NYC working with @sergiusens to move .NET Core snaps to classic confinement. There are currently 4 which cover a key set of deployment scenarios. If it would be best, I can into separate requests.
(dotnet-core-runtime-20, dotnet-core-runtime-11 and dotnet-hosting-20 removed from request)
Regards,
Lee
I’m +1 on dotnet-core-sdk. You use .NET Core to develop your own apps. It needs access to arbitrary paths, and can call arbitrary commands.
Lee suggests that dotnet-core-runtime-20, dotnet-hosting-20, and dotnet-core-11 may be feasible as strictly confined snaps. He’ll look into that tomorrow.
Confirmed the runtime snaps (strict) function correctly when the app is in a user controlled location but fails otherwise. A typical scenario does include hosters (aws, google, go daddy, etc) where this may not always be true but I do confess to not knowing how an environment which runs shared services or applications would be configured.
I guess one question would be how the runtime snaps are intended to be used. Is the intention for them to be used by unpackaged applications stored in arbitrary parts of the file system?
Or is it something another strictly confined snap might gain access to via the content interface? If the runtime snap is really only there to support other snaps via the content interface, then any shared executables will be run with the receiving snap’s AppArmor policy. So for this use case, the runtime snap could use the default strict confinement policy.
The runtime has two functionalities:
dotnet plugin by means of a slot which the application would plug into and for which would drive the confinement level.The latter however might need some work to be achievable as interfaces are currently ignored for classic for which I’d like to surface the need for interfaces, at least for the content.
All in all, and given prior discussions in NYC with the snapd and snapcraft teams, I am +1 on the request for the SDK and the runtimes.
On the question of how we intend people to use the .NET Core snaps … Our starting position is how people use .debs today. Some people deploy apps as packages that depend on our packages, but that’s not the primary model. People mostly install the .NET Core SDK or the Runtime and then can use the “dotnet” command anywhere on the machine to create, build or run apps. This is how they use the product on Linux and on other OSes. This model is what we are hoping to recreate with snaps.
Thanks for the help!
Thanks @richlander, @sergiusens, and @leecow for the explanation. I believe your explanation sufficient to grant classic confinement. +1 from me.
We (@leecow, @sergiusens and myself) discussed this at the sprint and they’re working towards dotnet-sdk being classic, but dotnet-runtime* being strict. I’d like to hear back on how that plays out before granting classic to all.
In the interest of time, I’ve granted classic to dotnet-sdk. This is now live.
I’m not familiar with the .NET runtime itself, but considering how runtimes generally work, I don’t see how the runtime can be strict if it carries arbitrary logic that will be leveraged by unconfined applications. The strictness and permission dependencies of the runtime depend on what applications are doing. Do I misunderstand the case for .NET runtimes?
If that’s indeed how they work, they will need classic if they are running applications that are not themselves inside a snap. For applications inside a snap, we might expose a content interface that allows other applications to leverage the runtime in a confined fashion, and then the snap applications themselves can declare the exact permissions they need from the system, thus allowing proper confinement on both ends.
My preemptive +1 to allowing classic confinement if what’s described sounds correct, on the basis that one cannot confine a runtime without confining the application itself. It would be like confining libc.
Others can comment as needed, but the basic idea is that the sdk probes for what runtimes are available, and since it is classic, it can see find any installed runtimes and point itself to those paths for projects that need those runtimes.
I’m told the runtimes can themselves run in strict mode. I’m not sure of the use case here, but Lee (the requester) said they work fine.
The runtimes may(/will?) provide the slot side of the content interface for other strict mode snaps to consume. The plugging snap simply uses the content interface like normal and its commands run under the declared interface for the plugging snap.
That’s the working theory and has been initially validated. Will be pushing the idea a bit further tomorrow to validate the strict app -> runtime connection. I’m still getting my head around the Snap concepts so some thrashing will surely ensue.
We have confirmed that going ahead with the runtimes in strict confinement will likely be OK. A new snap has been added to the mix which provides just the runtime mulitplexer and binding policies which needs classic confinement.
Updating the Classic confinement request to the following:
Just to expand, this is inline with the architecture we discussed with @jdstrand where we’d have these two snaps as classic pulling in the individual required runtimes as strictly confined snaps.
This allows for the runtimes to maintain their strict nature which in turn allows us to provide slots in these runtimes which the snaps built with snapcraft’s dotnet plugin (or any other packaged snap) could plug into.
Additionally, the individual runtimes could be install on a pure snappy system.
Thanks @sergiusens.
Is any additional information needed before voting on classic confinement for the dotnet-host snap?
No, just needed to see the new request. 
Since this is following the agreed-to design for this collection of snaps, also granting classic to dotnet-host. This is now live. Since it and dotnet-sdk have been granted classic and the runtimes will use strict, marking this request as done.
Awesome. Thanks, Jamie!