I reviewed flatpak 1.10.2-1ubuntu1 as checked into hirsute. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.
flatpak is an application packaging and sandbox tool.
- CVE History:
we have six cves in our database, they appear to have been handled well,
quickly, and even proactively when a snapd issue was found they went
looking for the same flaw family.
The coverity discoveries I reported to them were handled pretty well
considering it was a bit of a firehose; they said they were going to set
up the free coverity scan instance to keep a handle on issues going
forward.
- Build-Depends?
enough that listing them all feels useless; uses gnupg, fuse, dbus,
bubblewrap, malcontent, polkit, libxml2, ostree -- complicated code with
tendrils.
- pre/post inst/rm scripts?
mostly automatically added contents; creates _flatpak user; populates
the catalog during install; seems safe
- init scripts?
none
- systemd units?
system flatpak-system-helper.service
user flatpak-oci-authenticator.service
user flatpak-portal.service
user flatpak-session-helper.service
- dbus services?
several, start the system helper service, portal service, oci
authenticator service, session helper service
- setuid binaries?
none
- binaries in PATH?
in flatpak, flatpak
in libflatpak-dev flatpak-bisect, flatpak-coredumpctl
- sudo fragments?
only in documentation
- polkit files?
extensive polkit rules, someone else giving them a double-check would be
wonderful. I'm not sure I like this:
- Normal users need admin authentication to install software
system-wide.
- Note that we install polkit rules that allow local users
in the wheel group to install without authenticating.
- udev rules?
none
- unit tests / autopkgtests?
A huge and uncertain number of tests are run during the build. There's a
flatpak-tests binary package, I have no idea what it does, but it might
also come in handy.
- cron jobs?
none
- Build logs:
A fair number of things, but for the size of the project a pretty
reasonable ratio.
- Processes spawned?
Significant spawning other processes; I'm concerned about parsing the
.desktop files but didn't find any issues in my simple tests.
Historically glib-based programs have done a decent job in this area.
- Memory management?
Significant use of autofree tooling. Coverity reported some memory
leaks, but they were all small and temporary, and upstream fixed them
the 'right' way very quickly and enthusiastically.
- File IO?
skipped
- Logging?
spot checks look fine
- Environment variable usage?
OSTREE_DEBUG_HTTP environment variable asks soup to log http bodies
FLATPAK_GL_DRIVERS looks like it can give alternative paths to drivers
FLATPAK_BWRAP looks like it can replace bubblewrap
FLATPAK_SYSTEM_CACHE_DIR is used to create mode 755 directory
FLATPAK_SYSTEM_HELPER_ON_SESSION switches between system and session dbus
FLATPAK_TRIGGERSDIR indicates a directory of 'triggers' to run
FLATPAK_REVOKEFS_FUSE selects an executable to use when revoking a fuse mount
SSH_AUTH_SOCK appears to be copied to applications
PCSCLITE_CSOCK_NAME appears to be copied to applications
CUPS_SERVER causes local cups servers to be used
PULSE_SERVER and PULSE_CLIENTCONFIG and PULSE_RUNTIME_PATHmodify pulse in the
applications
DBUS_SYSTEM_BUS_ADDRESS selects a dbus system bus
DBUS_SESSION_BUS_ADDRESS selects a dbus session bus
FLATPAK_DBUSPROXY executes a program to serve as a dbus proxy
LD_LIBRARY_PATH appears to pass through to applications
XDG_DESKTOP_PORTAL_DIR selects a directory of portal applications
BROWSER selects a web browser to use
FLATPAK_VALIDATE_ICON selects a tool to validate icons
... it goes on. A huge number of things can be configured via
environment variables.
- Use of privileged functions?
Yes, most looked good, questions sent to flatpak team
- Use of cryptography / random number sources etc?
Uses SoupSession
- Use of temp files?
Seemed fine
- Use of networking?
Yes, a lot, spot checks looked fine
- Use of WebKit?
None
- Use of PolicyKit?
yes polkit_unix_process_new_for_owner() is used (should be safe)
- Any significant cppcheck results?
One small issue
- Any significant Coverity results?
I can't recall now just how significant they were, but many of them were
handled very quickly when reported, and upstream expressed an interest
in using the free coverity service, which is promising.
- Any significant shellcheck results?
only in tests and autotools
- Any significant bandit results?
only in tests, ignored
Security team gives a provisional ACK for libflatpak0 to be promoted
to main -- though I think we need a discussion about the 'allow wheel
users to install software without authentication'. That's unusual and
unexpected. We may ask for these to be tightened.
It's large, and complicated, and intricate, but upstream has been
responsive to my questions and comments. I don't believe we can
realistically offer the full support for the full flatpak experience
for the full lifetime of a release plus ESM offering. However, a more
limited goal of libflatpak0 only, and for ease of integration, is a
significant reduction of scope that makes this feel approachable.
Assorted links:
https://gitlab.gnome.org/GNOME/libglnx/-/issues/2
https://github.com/flatpak/flatpak/issues/4223
https://github.com/flatpak/flatpak/issues/4224
fixed by https://github.com/flatpak/flatpak/pull/4225
https://github.com/flatpak/flatpak/issues/4233
** Changed in: flatpak (Ubuntu)
Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1812456
Title:
[MIR] libflatpak0
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/1812456/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
