> Wiadomość napisana przez Neal Gompa <ngompa13@xxxxxxxxx> w dniu 23.07.2016, o godz. 02:46: > > Hello all, > > Over the course of this week, I've been involved in the first Snap > sprint focused on making the Snap system broadly useful and workable > across a wide variety of Linux distributions. While I obviously did > not represent Fedora in any official capacity (and I'm not even really > sure it's possible for a person to represent such a diverse community > such as ours), I ensured that Fedora was part of the conversation when > it came to evolving the Snap system. I was at the spring with Neal. I will add some notes on my perspective. > > There are some interesting highlights from the event that I think are > quite relevant to Fedora: > > * Snaps are intended to evolve beyond Ubuntu. While snaps have their > origins in Click for Ubuntu Touch user apps, the Snap system is > clearly designed to support a broader array of capabilities and > systems. Snaps can be used to handle OS components, services, CLI > tools, desktop applications, build environments, web services, and so > on. I very much share this view. Snaps are just glorified zip files (squashfs images) that have just enough meta-data to make themselves useful. Because snaps just declare the integration the particular implementation can figure out how to actually do things that are meaningful in a given context. This can include command line tools, graphical applications and the security interaction are just not hardcoded in the actual snap but are only declared in a very high-level form and language that can be implemented correctly in various ways, depending on the environment in which the snap is being used. > * SELinux-based confinement is a _very_ high priority. As most know, > snapd currently only works on systems using AppArmor and seccomp, and > only those using AppArmor patches developed by Ubuntu that are in the > process of being upstreamed. For SELinux support, we aren't exactly > sure how this will be pulled off. I proposed something along the lines > of how confinement works for Docker containers and virtual machines > (sVirt), but I'm not sure if that's the right approach for enabling > proper confinement while allowing the sandboxes to support the > interconnection capabilities of snaps. The way that the Snap system > enforces confinement using AppArmor and seccomp is by generating a > profile for the snap on the fly that defines what it can and cannot do > and access for the mounted snap filesystem (from the squashfs image). > This policy is applied, locking down the snap's environment. I'm > curious to hear from others on how the approach should be for > providing confinement using SELinux. I’ve started some initial work on SELinux support, I could really use some help on this to at least bootstrap support for the basic confinement features. I’d like to invite developers interested in SELinux and security technologies in general to help me out. I will address this separately after I push some initial patches (probably next week but I’m currently traveling so I cannot be sure). The snapd codebase has a concept of a security backend. It is perhaps a misnomer as each actual installation uses many „backend” at the same time. Since snaps (applications) don’t actually contain their apparmor profiles it is possible to offer both a SELinxu and apparmor implementation of each concept that snaps operate on. Obviously the devil is in the details but I have a few initial pointers to explore (as Neal said above) > > * Detection and auto-configuration of confinement is coming. > Snap-confine currently relies on build time configuration to figure > out whether it should support confinement. However, this will change. > Snap-confine will be merged into snapd and snapd will be set up to > query and set up whatever confinement is possible, given the > information returned from the kernel and systemd about what > confinement mechanisms are supported. This is pretty simple, I just have to stop moving around so that I can actually implement it. Snapd already does dynamic identification, it just has to be a little bit smarter. As for snap-confine it currently uses build-time configuration to ensure it cannot be used as a source of attack. What I want to do instead is so that snapd does all the detection and puts a file that snap-confine can read (but creating or changing that snap requires root access) and snap-confine can trust the decisions there to control the type of confinement or any other choices that currently have to be in sync across the two processes. > * The snap format is simple and lends itself to being able to be > generated by many kinds of tools. While the current main tool used to > make snaps is Snapcraft, there's no reason someone couldn't build a > "snapbuild" (like rpmbuild, debbuild[1], and pkgbuild[2]) that could > theoretically use RPM spec format (or a derivative of it) to build > snaps. Yes! My first snaps were built with just make compiling my code and writing the meta-data file. While snapcraft is a kind of a meta build system that just taps into existing build systems, you can always just build your snap with a totally custom way, as long as in the end you get the meta-data in place (one file) and put your application inside in a way that makes it run. It’s just a blessed zip file with some > > * Snapcraft is currently Ubuntu specific, but will be reworked to > remove that. Snapcraft and the snapcraft.yaml format will change to > enable easily and reproducibly building snaps using Debian and RPM > based distro bases in addition to Ubuntu[3]. The goal is to make it > possible for a distribution like Fedora to be able to easily add > support for building snaps and snap parts from Fedora infrastructure > using Fedora packages/software, along the lines of what we do now for > Docker images, so that people can use them in their own snaps or > solutions. As soon as snapcradt upstream makes that part configurable I will work on packaging a pure RPM-based snapcraft. > * Fedora packaging of the snap system is under active development. > Zygmunt Krynicki (zyga) is extremely enthused to get the system in > Fedora fully functional, and I'm mentoring him on various aspects of > Fedora packaging, including maintenance and policies. Yes! And I’d like to thank you for all the time you’ve spent teaching me and reviewing the packages (the more people reviewing the better so do please look at my code and correct me if I’m doing something wrong). The packaging is close to done, there will be a few things I will defer (like getting the permission to use preset to start snapd socket, etc) but overall it feels close to being available in F25 without major problems. > * Snap development is rather fast, with releases expected to occur > every two weeks. There's no intention to break the API between snapd > and the rest of the system, so interaction points should be fine. The > pace is well-suited for being able to push updates to Fedora in a > timely fashion so that users can get the best experience possible for > using applications and services under the system. One thing I could use some help with is to have snapd integration tests (that run on all merges) also support Fedora properly. There are a few things that will be ubuntu specific for now (those can be easily fixed or just disabled for now) and some things will be known-broken before the selinux support is in place but this should give us much better confidence when the actual upstream release is done and when downstream distributors will ensure it can be released. Currently the way this works is that a throwaway VM is created, the whole source tree is copied there, packaging is applied and the package is built and installed. This is something that just needs love so that it is 1) easy for everyone to reproduce 2) extended to support particular distributions. Spread [1] (the testing tool used by snappy upstream) supports LXD, Linode and (almost finished) QEmu. You can have a look at the snap-confine [2] and snapd [3] tests. Please keep in mind that they are actually spread out into various task.yaml files. What I’d like to do is that a developer can [1] https://github.com/snapcore/spread [2] https://github.com/snapcore/snap-confine/blob/master/spread.yaml [3] https://github.com/snapcore/snapd/blob/master/spread.yaml > I know that the Workstation WG is very much behind Flatpak right now, > but I see no reason that we cannot offer both. In fact, it is in the > best interests of our users to fully enable both systems to the best > extent we can, so that they have the freedom to develop and use > applications as they see fit. Obviously my view is biased but I obviously agree. Unlike past differences between distributions (e.g. deb and rpm) all bundle packaging systems can co-exist peacefully on one machine without conflicts. Now for a small bit of additional information. I’m currently quite busy with an ongoing sprint but I will be at the Fedora flock conference next week in Krakow. I will be there just for a day or two but if anyone wants to chat about SELinux or snappy in particular I’m glad to do that. After I’m done sprinting and traveling I plan to actually make good on my claims by writing some code :-) Best regards ZK -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
