7:27 a.m.
Wiadomość napisana przez Neal Gompa <ngompa13(a)gmail.com> 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