Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
On 24/04/01 08:40AM, orbea wrote: > On Mon, 1 Apr 2024 11:14:15 -0400 > Kenton Groombridge wrote: > > > On 24/03/31 12:13PM, Eddie Chapman wrote: > > > Eli Schwartz wrote: > > > > On 3/29/24 11:07 PM, Eddie Chapman wrote: > > > > > > > >> Given what we've learnt in the last 24hrs about xz utilities, > > > >> you could forgive a paranoid person for seriously considering > > > >> getting rid entirely of them from their systems, especially > > > >> since there are suitable alternatives available. Some might say > > > >> that's a bit extreme, xz-utils will get a thorough audit and it > > > >> will all be fine. But when a malicious actor has been a key > > > >> maintainer of something as complex as a decompression utility > > > >> for years, I'm not sure I could ever trust that codebase again. > > > >> Maybe a complete rewrite will emerge, but I'm personally > > > >> unwilling to continue using xz utils in the meantime for > > > >> uncompressing anything on my systems, even if it is done by an > > > >> unprivileged process. > > > > > > > > > > > > It suffices to downgrade to the version of xz before a social > > > > engineering attack by a malicious actor to gain maintainership of > > > > the xz project. > > > > > > > > Have you been linked to this yet? > > > > https://www.mail-archive.com/xz-devel@tukaani.org/msg00571.html > > > > > > > > -- > > > > Eli Schwartz > > > > > > > > > > Yes I saw that yesterday. It only increased my level of concern > > > about the project ten-fold rather than decreased it, particularly > > > because of "he has been helping a lot off-list and is practically a > > > co-maintainer already". > > > > > > > > > > I think it's important to realize that this could have potentially > > happened to any number of various open source projects, not just > > xz-utils. Simply ripping it out and replacing it is not enough to > > prevent these kinds of issues from happening in the future. > > > > There is a major shifting of perspectives as a result of this > > unfortunate compromise. Right now there are serious considerations > > about banning (or otherwise auditing) binary blobs in some projects. > > There are talks about banning the use of older build systems like > > autotools in favor of ones more easily readable and auditable. > > Talk about throwing the baby out with the bathwater... > Let's not shoot the messenger here. :) I cited this specific example to highlight the shared intent behind positive changes to auditing code not just in the program but also its build system. I didn't mean to imply that this was a great solution. > Its fully possible to write autotools build systems which are simple > and easy to audit. Depending on what blob does it may be far from > trivial or advisable to get rid of it. > > This attack as already has been clearly stated is social, not > technical. If xz-utils used meson or cmake instead it would of not > changed the situation. > > > Ultimately what is happening is a reflection on how we audit critical > > system components and contributions made to them. Change is not going > > to happen over night. > > > > We saw a similar shift with OpenSSL's heartbleed, which ultimately led > > to positive changes in code quality and improving their vulnerability > > reporting process. > > > > There is some good to come of this event, but it's important to > > recognize what went wrong and how open source can improve as a whole. > > > > -- Kenton Groombridge Gentoo Linux Developer, SELinux Project signature.asc Description: PGP signature
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
On 24/03/31 12:13PM, Eddie Chapman wrote: > Eli Schwartz wrote: > > On 3/29/24 11:07 PM, Eddie Chapman wrote: > > > >> Given what we've learnt in the last 24hrs about xz utilities, you could > >> forgive a paranoid person for seriously considering getting rid > >> entirely of them from their systems, especially since there are suitable > >> alternatives available. Some might say that's a bit extreme, xz-utils > >> will get a thorough audit and it will all be fine. But when a > >> malicious actor has been a key maintainer of something as complex as a > >> decompression utility for years, I'm not sure I could ever trust that > >> codebase again. Maybe a complete rewrite will emerge, but I'm personally > >> unwilling to continue using xz utils in the meantime for uncompressing > >> anything on my systems, even if it is done by an unprivileged process. > > > > > > It suffices to downgrade to the version of xz before a social > > engineering attack by a malicious actor to gain maintainership of the xz > > project. > > > > Have you been linked to this yet? > > https://www.mail-archive.com/xz-devel@tukaani.org/msg00571.html > > > > -- > > Eli Schwartz > > > > Yes I saw that yesterday. It only increased my level of concern about the > project ten-fold rather than decreased it, particularly because of "he has > been helping a lot off-list and is practically a co-maintainer already". > > I think it's important to realize that this could have potentially happened to any number of various open source projects, not just xz-utils. Simply ripping it out and replacing it is not enough to prevent these kinds of issues from happening in the future. There is a major shifting of perspectives as a result of this unfortunate compromise. Right now there are serious considerations about banning (or otherwise auditing) binary blobs in some projects. There are talks about banning the use of older build systems like autotools in favor of ones more easily readable and auditable. Ultimately what is happening is a reflection on how we audit critical system components and contributions made to them. Change is not going to happen over night. We saw a similar shift with OpenSSL's heartbleed, which ultimately led to positive changes in code quality and improving their vulnerability reporting process. There is some good to come of this event, but it's important to recognize what went wrong and how open source can improve as a whole. -- Kenton Groombridge Gentoo Linux Developer, SELinux Project signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo
On 24/02/27 07:07PM, Ulrich Mueller wrote: > >>>>> On Tue, 27 Feb 2024, Rich Freeman wrote: > > > On Tue, Feb 27, 2024 at 9:45 AM Michał Górny wrote: > >> > >> Given the recent spread of the "AI" bubble, I think we really need to > >> look into formally addressing the related concerns. > > First of all, I fully support mgorny's proposal. > > >> 1. Copyright concerns. > > > I do think it makes sense to consider some of this. > > > However, I feel like the proposal is redundant with the existing > > requirement to signoff on the DCO, which says: > > >>>> By making a contribution to this project, I certify that: > > >>>> 1. The contribution was created in whole or in part by me, and > >>>> I have the right to submit it under the free software license > >>>> indicated in the file; or > > >>>> 2. The contribution is based upon previous work that, to the best of > >>>> my knowledge, is covered under an appropriate free software license, > >>>> and I have the right under that license to submit that work with > >>>> modifications, whether created in whole or in part by me, under the > >>>> same free software license (unless I am permitted to submit under a > >>>> different license), as indicated in the file; or > > >>>> 3. The contribution is a license text (or a file of similar nature), > >>>> and verbatim distribution is allowed; or > > >>>> 4. The contribution was provided directly to me by some other person > >>>> who certified 1., 2., 3., or 4., and I have not modified it. > > I have been thinking about this aspect too. Certainly there is some > overlap with our GLEP 76 policy, but I don't think that it is redundant. > > I'd rather see it as a (much needed) clarification how to deal with AI > generated code. All the better if the proposal happens to agree with > policies that are already in place. > > Ulrich This is my interpretation of it as well, especially when it comes to para. 2: >>> 2. The contribution is based upon previous work that, to the best of >>> my knowledge, is covered under an appropriate free software license, >>> [...] It is extremely difficult (if not impossible) to verify this with some of these tools, and that's assuming that the user of these tools knows enough about how they work where this is a concern to them. I would argue it's best to stay away from these tools at least until there is more clear and concise legal interpretation of their usage in relation to copyright. -- Kenton Groombridge Gentoo Linux Developer, SELinux Project signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo
On 24/02/27 03:45PM, Michał Górny wrote: > Hello, > > Given the recent spread of the "AI" bubble, I think we really need to > look into formally addressing the related concerns. In my opinion, > at this point the only reasonable course of action would be to safely > ban "AI"-backed contribution entirely. In other words, explicitly > forbid people from using ChatGPT, Bard, GitHub Copilot, and so on, to > create ebuilds, code, documentation, messages, bug reports and so on for > use in Gentoo. > > Just to be clear, I'm talking about our "original" content. We can't do > much about upstream projects using it. > > > Rationale: > > 1. Copyright concerns. At this point, the copyright situation around > generated content is still unclear. What's pretty clear is that pretty > much all LLMs are trained on huge corpora of copyrighted material, and > all fancy "AI" companies don't give shit about copyright violations. > In particular, there's a good risk that these tools would yield stuff we > can't legally use. > > 2. Quality concerns. LLMs are really great at generating plausibly > looking bullshit. I suppose they can provide good assistance if you are > careful enough, but we can't really rely on all our contributors being > aware of the risks. > > 3. Ethical concerns. As pointed out above, the "AI" corporations don't > give shit about copyright, and don't give shit about people. The AI > bubble is causing huge energy waste. It is giving a great excuse for > layoffs and increasing exploitation of IT workers. It is driving > enshittification of the Internet, it is empowering all kinds of spam > and scam. > > > Gentoo has always stood out as something different, something that > worked for people for whom mainstream distros were lacking. I think > adding "made by real people" to the list of our advantages would be > a good thing — but we need to have policies in place, to make sure shit > doesn't flow in. > > Compare with the shitstorm at: > https://github.com/pkgxdev/pantry/issues/5358 > > -- > Best regards, > Michał Górny > I completely agree. Your rationale hits the most important concerns I have about these technologies in open source. There is a significant opportunity for Gentoo to set the example here. -- Kenton Groombridge Gentoo Linux Developer, SELinux Project signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 1/2] profiles/profiles.desc: add systemd/selinux/merged-usr subprofiles
On 22/10/12 01:50PM, Mike Gilbert wrote: > You should reverse the order of these commits: add the profile > directories first, and then add them to profiles.desc. > Fixed in my local tree, thanks! signature.asc Description: PGP signature
[gentoo-dev] [PATCH 2/2] profiles/default/linux: add systemd/selinux/merged-usr subprofiles
Signed-off-by: Kenton Groombridge --- .../amd64/17.1/no-multilib/systemd/selinux/merged-usr/eapi | 1 + .../amd64/17.1/no-multilib/systemd/selinux/merged-usr/parent| 2 ++ .../default/linux/amd64/17.1/systemd/selinux/merged-usr/eapi| 1 + .../default/linux/amd64/17.1/systemd/selinux/merged-usr/parent | 2 ++ .../default/linux/arm64/17.0/systemd/selinux/merged-usr/eapi| 1 + .../default/linux/arm64/17.0/systemd/selinux/merged-usr/parent | 2 ++ 6 files changed, 9 insertions(+) create mode 100644 profiles/default/linux/amd64/17.1/no-multilib/systemd/selinux/merged-usr/eapi create mode 100644 profiles/default/linux/amd64/17.1/no-multilib/systemd/selinux/merged-usr/parent create mode 100644 profiles/default/linux/amd64/17.1/systemd/selinux/merged-usr/eapi create mode 100644 profiles/default/linux/amd64/17.1/systemd/selinux/merged-usr/parent create mode 100644 profiles/default/linux/arm64/17.0/systemd/selinux/merged-usr/eapi create mode 100644 profiles/default/linux/arm64/17.0/systemd/selinux/merged-usr/parent diff --git a/profiles/default/linux/amd64/17.1/no-multilib/systemd/selinux/merged-usr/eapi b/profiles/default/linux/amd64/17.1/no-multilib/systemd/selinux/merged-usr/eapi new file mode 100644 index 000..7ed6ff82de6 --- /dev/null +++ b/profiles/default/linux/amd64/17.1/no-multilib/systemd/selinux/merged-usr/eapi @@ -0,0 +1 @@ +5 diff --git a/profiles/default/linux/amd64/17.1/no-multilib/systemd/selinux/merged-usr/parent b/profiles/default/linux/amd64/17.1/no-multilib/systemd/selinux/merged-usr/parent new file mode 100644 index 000..1b7f7eef0a7 --- /dev/null +++ b/profiles/default/linux/amd64/17.1/no-multilib/systemd/selinux/merged-usr/parent @@ -0,0 +1,2 @@ +.. +../../../../../../../../features/merged-usr diff --git a/profiles/default/linux/amd64/17.1/systemd/selinux/merged-usr/eapi b/profiles/default/linux/amd64/17.1/systemd/selinux/merged-usr/eapi new file mode 100644 index 000..7ed6ff82de6 --- /dev/null +++ b/profiles/default/linux/amd64/17.1/systemd/selinux/merged-usr/eapi @@ -0,0 +1 @@ +5 diff --git a/profiles/default/linux/amd64/17.1/systemd/selinux/merged-usr/parent b/profiles/default/linux/amd64/17.1/systemd/selinux/merged-usr/parent new file mode 100644 index 000..c8b1675247c --- /dev/null +++ b/profiles/default/linux/amd64/17.1/systemd/selinux/merged-usr/parent @@ -0,0 +1,2 @@ +.. +../../../../../../../features/merged-usr diff --git a/profiles/default/linux/arm64/17.0/systemd/selinux/merged-usr/eapi b/profiles/default/linux/arm64/17.0/systemd/selinux/merged-usr/eapi new file mode 100644 index 000..7ed6ff82de6 --- /dev/null +++ b/profiles/default/linux/arm64/17.0/systemd/selinux/merged-usr/eapi @@ -0,0 +1 @@ +5 diff --git a/profiles/default/linux/arm64/17.0/systemd/selinux/merged-usr/parent b/profiles/default/linux/arm64/17.0/systemd/selinux/merged-usr/parent new file mode 100644 index 000..c8b1675247c --- /dev/null +++ b/profiles/default/linux/arm64/17.0/systemd/selinux/merged-usr/parent @@ -0,0 +1,2 @@ +.. +../../../../../../../features/merged-usr -- 2.37.3
[gentoo-dev] [PATCH 1/2] profiles/profiles.desc: add systemd/selinux/merged-usr subprofiles
Signed-off-by: Kenton Groombridge --- profiles/profiles.desc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/profiles/profiles.desc b/profiles/profiles.desc index 5702a9dc7c4..b3efcf48c15 100644 --- a/profiles/profiles.desc +++ b/profiles/profiles.desc @@ -43,9 +43,11 @@ amd64 default/linux/amd64/17.1/no-multilib/hardened/selinux stable amd64 default/linux/amd64/17.1/no-multilib/systemd dev amd64 default/linux/amd64/17.1/no-multilib/systemd/merged-usr dev amd64 default/linux/amd64/17.1/no-multilib/systemd/selinux exp +amd64 default/linux/amd64/17.1/no-multilib/systemd/selinux/merged-usr exp amd64 default/linux/amd64/17.1/systemd stable amd64 default/linux/amd64/17.1/systemd/merged-usr dev amd64 default/linux/amd64/17.1/systemd/selinux exp +amd64 default/linux/amd64/17.1/systemd/selinux/merged-usr exp amd64 default/linux/amd64/17.1/clang exp amd64 default/linux/amd64/17.1/systemd/clang exp @@ -140,6 +142,7 @@ arm64 default/linux/arm64/17.0/developer exp arm64 default/linux/arm64/17.0/systemd stable arm64 default/linux/arm64/17.0/systemd/merged-usr dev arm64 default/linux/arm64/17.0/systemd/selinux exp +arm64 default/linux/arm64/17.0/systemd/selinux/merged-usr exp # ARM64 Profiles (big-endian) -- 2.37.3
Re: [gentoo-dev] [RFC] Encouraging using hardening options in systemd units
On 22/08/25 01:04PM, Mike Gilbert wrote:
> We could introduce a new function to install distro-specific overrides
> in [/usr]/lib/systemd/system.
>
I think that's a good idea. systemd_{new,do}serviceconf maybe?
As I understand it these should go to /usr/lib/[...].
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] Encouraging using hardening options in systemd units
On 22/08/25 04:06PM, Florian Schmaus wrote: > Wouldn't the proper place for overrides installed by a distributions package > manager be > > /usr/lib/systemd/system/miniflux.service.d/gentoo.conf > Yes... I was wondering that too. Currently systemd_install_serviced installs to /etc/systemd/system instead of /usr/lib/systemd/system appears to be wrong. systemd's own documentation says distributions should be installing contents to /usr/lib/systemd/system while /etc/systemd/system is intended for "System units created by the administrator" (users). signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Encouraging using hardening options in systemd units
On 22/08/22 03:42PM, Mike Gilbert wrote: > On Mon, Aug 22, 2022 at 2:10 PM Kenton Groombridge wrote: > > What do you think? > > I am concerned that people will start mass filing bugs with > suggestions without fully understanding them or without testing them > thoroughly. Please don't do that. > I had thought of this potentially being a problem as well. I think with this in mind perhaps it would be better to start with creating some documentation on these systemd service options on the wiki, with notes geared for both users and developers and when these options would/would not be a good idea to enable from both perspectives. That way we can at least have some solid reference material when addressing such bugs and providing guidance to developers to improve systemd units in their packages. > Also, ideally we would not need to provide systemd units at a distro > level, and they would instead be provided by upstream. I certainly > don't want to start installing distro-customized units where upstream > already provides unit files. > I agree! Unfortunately I know of a very small amount of packages where hardened systemd unit files are available but are not supported by upstream. One such upstream includes a hardened systemd unit in their contrib/, but nevertheless it is not installed by default for fear of breaking users' configurations. I think the best way to address this is to have packages ship unit override files instead of unit files themselves which enable these options. For example, instead of Gentoo shipping a modified miniflux.service unit file, we can instead install a file to /etc/system/miniflux.service.d/00gentoo.conf using the existing systemd_install_serviced helper in systemd.eclass which enables these options. Then, over time we can merge the modifications we make upstream if upstream wants them. If not, we can continue to ship this override file without changing how the original unit file gets installed. signature.asc Description: PGP signature
[gentoo-dev] [RFC] Encouraging using hardening options in systemd units
Hi everyone, I noticed that there are many systemd units which are shipped by various packages which could be hardened, some further than they are currently and some that could use some hardening in general. For those who are unaware, systemd units support many options which can be used to restrict privileges of the processes run by the service. Some of these options include things like making specified paths inaccessible or read-only, setting the no_new_privs flag, protecting kernel sysctls, preventing the loading of kernel modules, applying a seccomp filter to restrict syscalls, and more. I frequently reference systemd.exec(5)[1] and this page[2] for reference. Many of these options are fairly easy to apply from a user perspective - a user only needs to harden something like miniflux.service by overriding/settings via 'systemctl edit miniflux.service' (or manually editing /etc/systemd/system/miniflux.service.d/override.conf). But, I want to propose an initiative to set some of these options by default for systemd units shipped in ::gentoo. Care must be taken though, as some of these options may end up breaking some functionality that could be expected by users. An example of this may be if the package maintainer made the root filesystem read-only for a service except for its private /var/lib, but a user was using an entirely different directory for the service's read-writable data. Something like this may need to be communicated via post-installation messages or simply left out by default, depending on the circumstances. On the other hand, there are many options like restricting syscalls via SystemCallFilter=@system-service or restricting privilege escalation via NoNewPrivileges=true that I think are generally safe to apply, but each service is different and needs to be handled and tested accordingly. As for getting units updated, I think a good place to start would be to create a new tracker bug for identifying packages providing systemd units that could be improved in this regard, and each bug filed could include recommendations for some of the more common options like ProtectSystem=, ProtectHome=, ProtectDevices=, and others. What do you think? [1] https://www.freedesktop.org/software/systemd/man/systemd.exec.html [2] https://docs.arbitrary.ch/security/systemd.html signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing
On 22/07/05 12:02PM, Georgy Yakovlev wrote: > started playing with my old code and got blocked right away: > > looks like dostrip just creates a list of files/directories to strip > and processed at the very end of install phase. > > so skipping strip and doing manual one might be problematic. > internally portage uses estrip > https://github.com/gentoo/portage/blob/master/bin/estrip > which contains quite a lot of logic and code and I don't think > partially re-implementing this in eclass code is appropriate. > I agree I don't think it's appropriate. Would it make sense to be able to provide an extra argument to dostrip in order to strip an object *now* using the existing logic (and skip later stripping)? i.e.: dostrip --now my_module.ko
Re: [gentoo-dev] Packages up for grabs: x11-misc/lightdm, sys-apps/fwupd, net-im/pidgin, media-sound/mumble, app-emulation/virtualbox, app-editors/nano, app-shells/zsh and more
On 22/06/29 01:03PM, Conrad Kostecki wrote: > Hi! > > > Joonas Niilola hat am 29.06.2022 09:15 CEST > > geschrieben: > > Packages up for grabs: > > acct-group/murmur > > acct-user/murmur > > app-arch/pbzip2 > > media-sound/mumble > > media-sound/murmur > > If no one wants, I could take it, as I am using it. But help would be > appreciated. > I'd like to take these as I use them regularly: acct-group/murmur acct-user/murmur media-sound/mumble media-sound/murmur Any help would be appreciated as well.
Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing
> > Why can't we do both in pkg_preinst? I am thinking it would be best > > if > > we drop the current compression implementation and rework your old > > code > > to handle both compression and signing since the signing code is more > > or > > less already complete. > > i'm not sure if sign-file can sign compressed modules. sign-file will not error when signing a compressed module, but the kernel will not be able to load it. > if we let kernel build handle compression - we have to sign prior to > compression. > if we compress modules ourselves then yes, we could sign first indeed. > > but preinst has it's own issues, you've already seen floppym's remark. > signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing
On 22/06/27 02:56PM, Mike Gilbert wrote: > On Mon, Jun 27, 2022 at 2:35 PM Kenton Groombridge wrote: > > > so looks like we need to combine both methods and do the following: > > > - if signing requested without compression - sign in pkg_preinst. > > > - if signing requested with compression - sign in src_install > > > > > > > Why can't we do both in pkg_preinst? I am thinking it would be best if > > we drop the current compression implementation and rework your old code > > to handle both compression and signing since the signing code is more or > > less already complete. > > Signing modules in pkg_preinst seems like a bad idea to me. That means > you need to copy your private keys around to every host where the > package might be installed. > > If you sign in src_compile or src_install, you only need private keys > on the system building your binpkg. > Ah that makes sense. I think the question then is whether or not building binpkgs for kernel modules where the target system has its own signing keys is something we want to support. With that in mind I realize that doing compression in pkg_preinst means that target systems can use different compression methods (or no compression at all) if desired without much complication. signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing
On 22/06/26 04:15AM, Georgy Yakovlev wrote:
> On Sun, 2022-06-26 at 03:52 -0700, Georgy Yakovlev wrote:
> > On Tue, 2022-06-21 at 14:19 -0400, Kenton Groombridge wrote:
> > > eee74b9fca1 adds support for module compression, but this breaks
> > > loading
> > > out of tree modules when module signing is enforced because modules
> > > must
> > > be signed before they are compressed. Additionally, the recommended
> > > Portage hook[1] no longer works with this change.
> > >
> > > Add module signing support in linux-mod.eclass which more or less
> > > does
> > > exactly what the aforementioned Portage hook does. If the kernel
> > > configuration has CONFIG_MODULE_SIG_ALL=y, then read the hash and
> > > keys
> > > from the kernel configuration and call the sign_file tool to sign
> > > the
> > > module before it is compressed.
> > >
> > > Bug: https://bugs.gentoo.org/show_bug.cgi?id=447352
> > > Signed-off-by: Kenton Groombridge
> > > ---
> > > eclass/linux-mod.eclass | 16
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
> > > index b7c13cbf7e7..fd40f6d7c6c 100644
> > > --- a/eclass/linux-mod.eclass
> > > +++ b/eclass/linux-mod.eclass
> > > @@ -712,6 +712,22 @@ linux-mod_src_install() {
> > > cd "${objdir}" || die "${objdir} does not exist"
> > > insinto
> > > "${INSTALL_MOD_PATH}"/lib/modules/${KV_FULL}/${libdir}
> > >
> > > + # check here for CONFIG_MODULE_SIG_ALL and sign the
> > > module being built if enabled.
> > > + # modules must be signed before they are
> > > compressed.
> > > +
> > > + if linux_chkconfig_present MODULE_SIG_ALL; then
> > > + local
> > > module_sig_hash="$(linux_chkconfig_string MODULE_SIG_HASH)"
> > > + local
> > > module_sig_key="$(linux_chkconfig_string MODULE_SIG_KEY)"
> > > + module_sig_key="${module_sig_key:-
> > > certs/signing_key.pem}"
> > > + if [[ "${module_sig_key#pkcs11:}" ==
> > > "${module_sig_key}" && "${module_sig_key#/}" == "${module_sig_key}"
> > > ]]; then
> > > + local
> > > key_path="${KERNEL_DIR}/${module_sig_key}"
> > > + else
> > > + local key_path="${module_sig_key}"
> > > + fi
> > > + local
> > > cert_path="${KERNEL_DIR}/certs/signing_key.x509"
> > > + "${KERNEL_DIR}"/scripts/sign-file
> > > ${module_sig_hash//\"} ${key_path//\"} ${cert_path}
> > > ${modulename}.${KV_OBJ}
> > > + fi
> > > +
> > > # check here for
> > > CONFIG_MODULE_COMPRESS_ > > option> (NONE, GZIP, XZ, ZSTD)
> > > # and similarily compress the module being built if
> > > != NONE.
> > >
> >
> >
> > Hi,
> >
> > I've spent some time in the past ( circa 2018 ) to get this in, but
> > gave up due to various reasons, I was not a gentoo dev yet at the
> > time.
> >
> > I can't see how posted implementation will work tbh.
> > portage will strip signature out of the module, unless you prevent
> > stripping completely or package uses EAPI>=7, and omits stripping
> > modules via dostrip -x on the ko object.
> > kernel will NOT load module with stripped signature.
> >
> > so either you have to sign in pkg_postinst phase, or prevent
> > stripping.
> > signing in postinst is not ideal, because if breaks recorded file
> > checksums in vdb.
> >
> > here's old fork of eclass I made, maybe you can find some helpful
> > code
> > in there
> >
> > https://github.com/gyakovlev/linux-mod.eclass/blob/master/linux-mod.eclass
> >
> > old ML discussion we had:
> > https://archives.gentoo.org/gentoo-dev/message/4b15b1c851f379a1f802e2f2895cdfa8
> >
> > You will also need a dependency on openssl, since sign-file uses it.
> >
> > lmk if you need more info, I might remember more details, but for now
> > that's all I have. I'll try to help get
Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing
On 22/06/23 08:51AM, Mike Pagano wrote:
> On 6/21/22 14:21, Kenton Groombridge wrote:
> > On 22/06/21 02:19PM, Kenton Groombridge wrote:
> > > eee74b9fca1 adds support for module compression, but this breaks loading
> > > out of tree modules when module signing is enforced because modules must
> > > be signed before they are compressed. Additionally, the recommended
> > > Portage hook[1] no longer works with this change.
> > >
> >
> > Forgot to include this reference:
> >
> > [1]
> > https://wiki.gentoo.org/wiki/Signed_kernel_module_support#Automatically_signing_kernel_modules_.28Portage.29
> >
> > > Add module signing support in linux-mod.eclass which more or less does
> > > exactly what the aforementioned Portage hook does. If the kernel
> > > configuration has CONFIG_MODULE_SIG_ALL=y, then read the hash and keys
> > > from the kernel configuration and call the sign_file tool to sign the
> > > module before it is compressed.
> > >
> > > Bug: https://bugs.gentoo.org/show_bug.cgi?id=447352
> > > Signed-off-by: Kenton Groombridge
> > > ---
> > > eclass/linux-mod.eclass | 16
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
> > > index b7c13cbf7e7..fd40f6d7c6c 100644
> > > --- a/eclass/linux-mod.eclass
> > > +++ b/eclass/linux-mod.eclass
> > > @@ -712,6 +712,22 @@ linux-mod_src_install() {
> > > cd "${objdir}" || die "${objdir} does not exist"
> > > insinto
> > > "${INSTALL_MOD_PATH}"/lib/modules/${KV_FULL}/${libdir}
> > > + # check here for CONFIG_MODULE_SIG_ALL and sign the module
> > > being built if enabled.
> > > + # modules must be signed before they are compressed.
> > > +
> > > + if linux_chkconfig_present MODULE_SIG_ALL; then
> > > + local module_sig_hash="$(linux_chkconfig_string
> > > MODULE_SIG_HASH)"
> > > + local module_sig_key="$(linux_chkconfig_string
> > > MODULE_SIG_KEY)"
> > > +
> > > module_sig_key="${module_sig_key:-certs/signing_key.pem}"
> > > + if [[ "${module_sig_key#pkcs11:}" ==
> > > "${module_sig_key}" && "${module_sig_key#/}" == "${module_sig_key}" ]];
> > > then
> > > + local key_path="${KERNEL_DIR}/${module_sig_key}"
> > > + else
> > > + local key_path="${module_sig_key}"
> > > + fi
> > > + local cert_path="${KERNEL_DIR}/certs/signing_key.x509"
> > > + "${KERNEL_DIR}"/scripts/sign-file
> > > ${module_sig_hash//\"} ${key_path//\"} ${cert_path}
> > > ${modulename}.${KV_OBJ}
> > > + fi
> > > +
> > > # check here for CONFIG_MODULE_COMPRESS_ > > option> (NONE, GZIP, XZ, ZSTD)
> > > # and similarily compress the module being built if !=
> > > NONE.
> > > --
> > > 2.35.1
> > >
> > >
>
>
> First of all, thank-you for your work !
> I appreciate any assistance with enhancement or clean-up of these eclasses.
>
> I tested your patch, are you signing the files in 'work' after they are
> installed in 'image' ?
>
>
> /usr/src/linux/scripts/extract-module-sig.pl -s ./work/kernel/nvidia.ko >
> /tmp/sig
> Read 47802433 bytes from module file
> Found magic number at 47802433
> Found PKCS#7/CMS encapsulation
> Found 681 bytes of signature [308202a506092a864886f70d010702a0]
>
> /usr/src/linux/scripts/extract-module-sig.pl -s
> ./image/lib/modules/5.18.6-gentoo/video/nvidia.ko > /tmp/sig
> Read 47227784 bytes from module file
> Magic number not found at 47227784
>
Thanks for testing!
That's odd. In my environment they are signed in 'work' before
installing to 'image' as they should be.
# unzstd /lib/modules/5.15.48-gentoo/misc/p_lkrg.ko.zst
/lib/modules/5.15.48-gentoo/misc/p_lkrg.ko.zst: 436681 bytes
# /usr/src/linux/scripts/extract-module-sig.pl -s
/lib/modules/5.15.48-gentoo/misc/p_lkrg.ko >sig
Read 436681 bytes from module file
Found magic number at 436681
Found PKCS#7/CMS encapsulation
Found 681 bytes of signature [308202a506092a864886f70d010702a0]
The installation of modules in linux-mod_src_install happens after
signing and compression, so unless I am missing something that shouldn't
be happening.
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH] linux-mod.eclass: support module signing
eee74b9fca1 adds support for module compression, but this breaks loading
out of tree modules when module signing is enforced because modules must
be signed before they are compressed. Additionally, the recommended
Portage hook[1] no longer works with this change.
Add module signing support in linux-mod.eclass which more or less does
exactly what the aforementioned Portage hook does. If the kernel
configuration has CONFIG_MODULE_SIG_ALL=y, then read the hash and keys
from the kernel configuration and call the sign_file tool to sign the
module before it is compressed.
Bug: https://bugs.gentoo.org/show_bug.cgi?id=447352
Signed-off-by: Kenton Groombridge
---
eclass/linux-mod.eclass | 16
1 file changed, 16 insertions(+)
diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
index b7c13cbf7e7..fd40f6d7c6c 100644
--- a/eclass/linux-mod.eclass
+++ b/eclass/linux-mod.eclass
@@ -712,6 +712,22 @@ linux-mod_src_install() {
cd "${objdir}" || die "${objdir} does not exist"
insinto "${INSTALL_MOD_PATH}"/lib/modules/${KV_FULL}/${libdir}
+ # check here for CONFIG_MODULE_SIG_ALL and sign the module
being built if enabled.
+ # modules must be signed before they are compressed.
+
+ if linux_chkconfig_present MODULE_SIG_ALL; then
+ local module_sig_hash="$(linux_chkconfig_string
MODULE_SIG_HASH)"
+ local module_sig_key="$(linux_chkconfig_string
MODULE_SIG_KEY)"
+
module_sig_key="${module_sig_key:-certs/signing_key.pem}"
+ if [[ "${module_sig_key#pkcs11:}" ==
"${module_sig_key}" && "${module_sig_key#/}" == "${module_sig_key}" ]]; then
+ local key_path="${KERNEL_DIR}/${module_sig_key}"
+ else
+ local key_path="${module_sig_key}"
+ fi
+ local cert_path="${KERNEL_DIR}/certs/signing_key.x509"
+ "${KERNEL_DIR}"/scripts/sign-file
${module_sig_hash//\"} ${key_path//\"} ${cert_path} ${modulename}.${KV_OBJ}
+ fi
+
# check here for CONFIG_MODULE_COMPRESS_
(NONE, GZIP, XZ, ZSTD)
# and similarily compress the module being built if != NONE.
--
2.35.1
Re: [gentoo-dev] it's time for 22.0 profiles
On 22/05/28 10:28PM, Andreas K. Huettel wrote: > Hi all, > > it's time for introducing 22.0 profiles [1] - so if you have any things that > need to > be switched in an incompatible way tree-wide, or if you have any suggestions > on how > to change our default settings, please reply to this mail with details! > The currently existing systemd/selinux profiles need to be replaced with systemd/hardened and systemd/hardened/selinux profiles. So, instead of (for example): default/linux/amd64/20.0/no-multilib/systemd/selinux default/linux/amd64/20.0/systemd/selinux We would instead have: default/linux/amd64/20.0/no-multilib/systemd/hardened/selinux default/linux/amd64/20.0/no-multilib/systemd/hardened default/linux/amd64/20.0/systemd/hardened default/linux/amd64/20.0/systemd/hardened/selinux The takeaway is that the systemd/selinux profiles should have hardened as a parent for consistency with the other SELinux profiles. /* Kenton Groombridge */ signature.asc Description: PGP signature
