Replies: 8 comments 21 replies
-
|
Additional suggestion for the project:
Note that the configure script can be generated with: autoreconf [-i] # execute at least once before autoconf
autoconfDeleting the configure script would also make maintenance and reviews of Though note that if the configure script is removed from the repository, then A configure script could still be provided in a tarball to keep it working Maybe the configure script and tarball could be generated in CI for the release |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Very hot, interesting and complicated topic. Not that I have strong opinions yet on what build tooling to favor at this moment in time. It might take a while for the dust of the xz-utils backdoor debacle to settle. In this context I stumbled upon the de-autoconfiscation HOWTO from autodafe - not to be mistaken with a fuzzer framework bearing the same name. Might help informed decision-taking on such a vital subject. |
Beta Was this translation helpful? Give feedback.
-
|
Interesting option. If the opposition for Meson is too strong, pure Makefile approach (throwing out just auto****) could be also good enough. For Firejail we don't need a lot of fancy options (like support for Windows, BSD, shared libraries, ancient compilers etc.). |
Beta Was this translation helpful? Give feedback.
-
Thanks for the link, it was an interesting read. I agree that going full autotools makes the build process much more complex Though note that our usage is already quite minimal: There is only autoconf;
Do you mean building without needing to run a configure script (by setting the |
Beta Was this translation helpful? Give feedback.
-
|
Building without configure would be nice. Though then the methods specifying any options would be uncommon. |
Beta Was this translation helpful? Give feedback.
-
Well... If you don't mind specifying them in a file instead of the CLI and you |
Beta Was this translation helpful? Give feedback.
-
|
That could be the default. Then if an optional component is missing, the builder would use something like |
Beta Was this translation helpful? Give feedback.
-
@kmk3 prepare() {
cd "${srcdir}/${pkgname}"
NOCONFIGURE=1 autoreconf -vfi
}Maybe we should try to contact package maintainers and invite them to share their input on this? |
Beta Was this translation helpful? Give feedback.
-
|
@reinerh ? |
Beta Was this translation helpful? Give feedback.
-
|
Debian is autoreconf'ing by default (an opt-out (or using older packaging helpers) is required to skip that). firejail is also autoreconf'ed before the build. |
Beta Was this translation helpful? Give feedback.
-
|
What about switching to meson, would that be a problem? |
Beta Was this translation helpful? Give feedback.
-
|
I don't think so, meson is supported. (maybe don't use bleeding-edge meson features, so that it can still be backported) |
Beta Was this translation helpful? Give feedback.
-
For signing, the release tags could be improved by creating them as signed tags But even without any signing, if an archive is provided by GitHub directly Distributions could (and some probably do) also use the same file hashes for If there are multiple hosting providers involved and they all use
I'll reply to this separately. Offtopic: Could you write "autotools", "autoconf" or something else directly Adding non-formatting asterisks in the middle of the text messes with markdown
Ideally running the tests would not depend on having a system-wide Interesting, running the compiled binary directly now seems to work. The last
Indeed, maybe using qemu to run a minimal image and then install/run the tests. But even without it, the tests could probably be split into ones that are safe
Yes, tests should still be executed when packaging for distribution, but What I meant by "Do not run tests by default" is that instead of a normal build If we assume that tests face less thorough review (at least outside of the That is, for users just building from the AUR (for example), tests would not be And when packaging for distribution, run the normal build without the tests and This could both be done by the projects themselves (such as by
Even if the source code itself is read-only, malicious code in the tests could Maybe there is a simple way to make the build tree read-only between the build
There are a few committed binary files: $ git ls-files --eol | grep '^i/-text'
i/-text w/-text attr/-text etc-fixes/seccomp-join-bug/eecf35c-backports.zip
i/-text w/-text attr/-text test/appimage/hello-x86_64.AppImage
i/-text w/-text attr/text=auto eol=lf test/filters/memwrexe-32
i/-text w/-text attr/text=auto eol=lf test/filters/namespaces
i/-text w/-text attr/text=auto eol=lf test/filters/namespaces-32
i/-text w/-text attr/text=auto eol=lf test/seccomp-extra/memwrexeI'm not sure if the zip and etc-fixes are still used; maybe they can be The filters could probably be generated at build-time. Creating AppImages requires specialized tooling which is generally not packaged Though maybe they could be generated in CI to at least increase
Yes, but other than generated files, it would likely require more effort to to |
Beta Was this translation helpful? Give feedback.
-
What a coincidence, we have a tool which can make parts of the file system read-only: Firejail! Some features may be missing somewhere... |
Beta Was this translation helpful? Give feedback.
-
Does not seem too hard according to this using AppImage/appimagetool. I'd remove the image with the other binary files. |
Beta Was this translation helpful? Give feedback.
-
Haha that's indeed one way to do it, though distributions might not be too keen |
Beta Was this translation helpful? Give feedback.
-
It seems that not even the AUR has packages that build it from source (the ones See also a previous comment about this issue: We could however keep the AppImage and add a target to remake it. It could |
Beta Was this translation helpful? Give feedback.
-
We could use bwrap (assuming unprivileged namespaces are available) but then we wouldn't eat our own dog food. With Firejail, we could ship the build profiles (for example firejail-build, firejail-install, firejail-test). |
Beta Was this translation helpful? Give feedback.
-
|
Could you clarify what exactly are your concerns security-wise with the build |
Beta Was this translation helpful? Give feedback.
-
|
If we decide to keep the Make system, I'd like to get rid of at least generated Preferably all |
Beta Was this translation helpful? Give feedback.
-
For reference, removing
As for the This seems to be a common practice for projects using autoconf, as usually the A CI check could be added to verify that all vendored files match upstream
What exactly is the threat model? Is it just a maintainer adding malicious code to a new/existing file in a
Is there a way to state that our release tarballs won't ever contain malicious Even without considering generated/vendored files, were the other files in the If they are not being verified, then the problem exists regardless of the If they are being verified, then the configure script could be re-generated and |
Beta Was this translation helpful? Give feedback.
-
That was the method used for xz-utils. A very advanced MITM attack could also replace the tarball and it's signature during download (or redirect the download page) for a distro packager. Possibly doable when the country is behind a great firewall.
I don't think the distros are verifying if the tarballs match the git repository. But for that they need a copy of the repository and then the tarball is pretty much useless. We can't solve this problem, except perhaps by never releasing any tarballs and directing distros to use the signed release commits directly. |
Beta Was this translation helpful? Give feedback.
-
|
Sources:
|
Beta Was this translation helpful? Give feedback.
-
|
Interesting coverage on how the malicious payload could defeat RELRO etc. protections with ld.so audit hook and GNU IFUNC. Plugging those holes (for example, disable audit feature of ld.so and replace IFUNC with something less dangerous) should be the responsibility of glibc and other users of IFUNC feature. If someone (or something like a state actor) wanted to use Firejail to backdoor systems, the methods probably wouldn't be same at all. Running as root, a backdoored Firejail could listen to sockets, insert kernel modules, attach to other running processes, tweak the firejailed executable, configuration or the libraries when copying etc. There are probably much stealthier options. The non-technical side of the xz attack was that the actions of a malicious developer were trusted and the review (when possible) didn't catch the changes to backdoor the system. "Given enough eyeballs, all bugs are shallow" didn't happen this time. I think this part is a harder to solve. |
Beta Was this translation helpful? Give feedback.
-
Sounds very reasonable. Still, running as root remains a pain-point topic. Both as potential attack vector from a purely |
Beta Was this translation helpful? Give feedback.
-
|
Adding one more interesting resource. To be clear, I'm not against going for Thanks to both @kmk3 and @topimiettinen for taking the time and efforts to look into this important topic. Quite promising for Firejail's future to see such level of dedication, expertise and consideration. Here's the reference and its accompanying discussion on HN: |
Beta Was this translation helpful? Give feedback.
-
|
LWN coverage of EOSS and OSSNA: one of the topics is xz-utils attack, autotools and M4. Comments are also interesting. |
Beta Was this translation helpful? Give feedback.
-
Background
It has recently been reported that the upstream xz project contained malicious
code targeting sshd in its official source code tarballs (versions 5.6.0 and
5.6.1), affecting distribution packages created from them.
It was able to target the sshd service directly because on certain
systemd-based distributions openssh was patched to link libsystemd, which in
turn linked liblzma (provided by xz). This allowed it to directly override
certain functions in the sshd process through the use of GNU indirect functions
(ifuncs).
Most of the malicious code was hidden inside a corrupted xz archive that was
added to the tests in the git repository and a small portion was added to the
configure script (to uncorrupt the archive and run the code within), but only
in the distributed source code tarballs (not in the git repository).
On certain distributions the package has been reverted to an earlier version
and further analysis may still be ongoing.
There is also prior criticism about the safety of the xz file format itself and
of its suitability as a long-term archival format.
Sources:
Issues
Each of the following items is linked to something that makes it less likely to
be reviewed (compared to common parts of the code in the repository):
may contain changes not present in the git repository (and despite that, the
files present in both would usually be assumed to be equivalent)
files and checks for obscure corner cases (which are harder to tell the
legitimacy of and how relevant they still are)
Suggestions
Note: These are not necessarily new; some of them were already done or
suggested elsewhere.
Considering the above, if I had to come up with suggestions to mitigate the
issues they would be the following:
For distributions:
core system programs and libraries
For packagers/users:
host, such as GitHub) at a specific tag/commit as the primary package source
instead of a user-uploaded tarball
checkout (such as in a separate job in CI)
For the project:
.tar.xz archives)
Beta Was this translation helpful? Give feedback.
All reactions