[Rpm-maint] [rpm-software-management/rpm] package level sandboxing and isolation (Discussion #3030)
Jan Zerebecki
notifications at github.com
Wed Apr 10 11:36:50 UTC 2024
I'd like to collect ideas for isolation of packages from each other and sandboxing or restriction of their capabilities on the system.
Currently many install time actions for rpms require scripts and there are many directories where placing files can indirectly trigger running code as root.
The xz compromise did not use this route, but it was a case of malicious build scripts not being caught during the software distributions process. While library sandboxing would have prevented it, there would still then be one other way open for a package with a malicious build script that provides this library. It could influence the package build so that the resulting package runs malicious code as root on installation. There are many packages with too few people to review all of them in sufficient detail. But most packages luckily do not need to run code as root.
Previously a plugin to restrict scripts somewhat was added to rpm: https://github.com/rpm-software-management/rpm/pull/2666
A somewhat related discussion is preventing artifact modification after %build: https://github.com/rpm-software-management/rpm/discussions/3009
I have described ideas how to prevent this: https://github.com/affording-open/package-sandboxing
Can rpm implement package level isolation? How? Should it? Alternatives?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3030
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/repo-discussions/3030 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20240410/b9da60d3/attachment.html>
More information about the Rpm-maint
mailing list