Re: [gentoo-user] Kernel modules and security
On 3/22/19 10:46 AM, Peter Humphrey wrote: > Hello list, > > Years ago, in the days of Yggdrasil I think, the received wisdom was that > enabling kernel module loading was a bad idea because an attacker might be > able to load malicious software directly into the kernel. No modules --> one > more attack route closed. > > What is the current thinking on this topic? I'm not trolling; I'd like to > know > which way to go with a new box. > The only way a non-root user can load a module into the kernel is if the kernel itself has a critical security flaw in the module-loading code. I would hope that said code is bullet-proof by now, but the risk is non-zero I guess. On the other hand, kernel drivers go ape-shit on me all the time, and having the ability to force-unload and reload them (without a reboot) is a life saver. Being able to build and load one module at a time also speeds up the kernel build -> oops I forgot something -> build loop.
Re: [gentoo-user] Kernel modules and security
On Fri, 22 Mar 2019 14:46:20 + Peter Humphrey wrote: > Hello list, > > Years ago, in the days of Yggdrasil I think, the received wisdom was that > enabling kernel module loading was a bad idea because an attacker might be > able to load malicious software directly into the kernel. No modules --> one > more attack route closed. > > What is the current thinking on this topic? I'm not trolling; I'd like to > know > which way to go with a new box. These days one can configure kernel to load only signed modules (with public key compiled into kernel) and refuse to load all unsigned modules [CONFIG_MODULE_SIG_FORCE]. During normal kernel build process all legitimate modules will be signed [CONFIG_MODULE_SIG_ALL]. All out-of-tree modules may be signed manually as well [scripts/sign-file]. Afterwards signing key [certs/signing_key.pem] may be removed from the system (e.g. encrypted or deleted). The benefit of this approach compared to kernel without modules is: 1) out of the tree kernel modules can be used (e.g. I use openafs) 2) kernel can be made smaller and faster by removing rarely needed functionality into modules (e.g. support for various USB devices, network protocols or filters and other subsystems which are not used on daily basis, but may be needed occasionally). Best regards, Andrew Savchenko pgpf7bCg7yH0S.pgp Description: PGP signature
Re: [gentoo-user] Kernel modules and security
On Fri, Mar 22, 2019 at 10:46 AM Peter Humphrey wrote: > > Years ago, in the days of Yggdrasil I think, the received wisdom was that > enabling kernel module loading was a bad idea because an attacker might be > able to load malicious software directly into the kernel. No modules --> one > more attack route closed. > > What is the current thinking on this topic? I'm not trolling; I'd like to know > which way to go with a new box. > IMO unless you're already using SELinux/etc this seems like a minor concern to focus on. You can't load kernel modules unless you're root, and if you have root then everything is wide open anyway. Now, if you're using a more hardened configuration where somebody who has root access is contained, but they might still be able to load modules, then this might be a meaningful protection. However, I suspect that most approaches to hardening that limit the capabilities of root are going to also limit the ability to load modules. In linux you need the CAP_SYS_MODULE capability to load a kernel module. I have to imagine that this is one of the first things you'd drop in any kind of hardened design since the need to load modules is very niche but very powerful. Now, if you want to make the argument that every system call is one more attack vector, then, sure, I guess this applies, but imo the odds that there is some exploit in the kernel where a process lacking CAP_SYS_MODULE could call init_module anyway seems pretty low. If you're going to be worried about this sort of vector then you should be selectively removing just about any system call that your application doesn't need, or just looking at microkernels or whatever. -- Rich
Re: [gentoo-user] Kernel modules: initramfs vs. /lib/modules
2017-02-15 16:19 GMT+01:00, Rich Freeman : >> >>> Anytime you see something like root=UUID=* that is being handled by an >>> initramfs. >> >> I understand that this parameter is passed by the kernel to the init >> script inside the initramfs which then uses "busybox findfs" to >> translate the UUID into a device name. Is this correct? >> > > I suppose that is one way it could be done, but of course it could be > implemented in other ways. As far as I can tell Dracut does not use > busybox findfs. OK, yes. Indeed I was looking at the init used by genkernel. Marco
Re: [gentoo-user] Kernel modules: initramfs vs. /lib/modules
On Wed, Feb 15, 2017 at 5:58 AM, marco restelli wrote: > >> The short version is that the kernel is very limited in what it can >> take in the root= option on the command line, and grub and other >> bootloaders don't do anything to ID the root filesystem other than >> passing whatever root= parameter you specify (I'd be interested in any >> info to the contrary). > > I have always generated grub.cfg files with grub-mkconfig. In some > cases I see here > > search --no-floppy --fs-uuid --set=root > linux /kernel-XYZ root=/dev/sda4 ro > > As far as I understand it, the first line searches the partition where > the kernel is located identifying it through the UUID. Then the second > line loads the kernel passing /dev/sda4 as the system root. > > On the bootable USB stick, with an initramfs, however I have > > search --no-floppy --fs-uuid --set=root > linux /kernel-XYZ root=UUID= ro > > so now also the root filesystem is identified by its UUID. Correct. Just note that "root" in GRUB lingo is the filesystem that contains all the grub binaries, the kernels, and so on. That is typically /boot on a linux system. Unless they happen to be the same filesystem it isn't the same root you pass to the kernel. If it were then you would have the same UUID in the second example. > >> Anytime you see something like root=UUID=* that is being handled by an >> initramfs. > > I understand that this parameter is passed by the kernel to the init > script inside the initramfs which then uses "busybox findfs" to > translate the UUID into a device name. Is this correct? > I suppose that is one way it could be done, but of course it could be implemented in other ways. As far as I can tell Dracut does not use busybox findfs. I didn't do a careful read but a quick look at the source suggests that it is actually using udev and referencing /dev/disk/by-uuid and so on. I suspect the logic is that if udev could find the root device on the host when the initramfs was being built, then it should be able to find it in the initramfs if the same software is used to do it. -- Rich
Re: [gentoo-user] Kernel modules: initramfs vs. /lib/modules
2017-02-13 12:47 GMT+01:00, Johannes Rosenberger : > On 13.02.2017 12:34, Rich Freeman wrote: >> On Mon, Feb 13, 2017 at 5:53 AM, marco restelli >> wrote: >>> Could you suggest any reference about how an initramfs can help making >>> it easier to identify the correct root filesystem? Does this >>> functionality overlap with what grub can do, or is something >>> different? >>> >> The dracut references are fairly extensive, but they probably assume >> that you already know about something like this. >> >> [...] > > There is some very good documentation about crafting your own initramfs > it the Gentoo wiki: > https://wiki.gentoo.org/wiki/Custom_Initramfs > https://wiki.gentoo.org/wiki/Early_Userspace_Mounting Johannes, these documents are indeed very informative, thank you for pointing them out. Marco
Re: [gentoo-user] Kernel modules: initramfs vs. /lib/modules
2017-02-13 12:34 GMT+01:00, Rich Freeman : > On Mon, Feb 13, 2017 at 5:53 AM, marco restelli > wrote: >> >> Could you suggest any reference about how an initramfs can help making >> it easier to identify the correct root filesystem? Does this >> functionality overlap with what grub can do, or is something >> different? >> > > The dracut references are fairly extensive, but they probably assume > that you already know about something like this. Keep in mind that on > virtually all other distros end-users aren't expected to set up their > own kernels or initramfs so there isn't a lot of general documentation > out there. And even within Gentoo a lot of people seem to avoid an > initramfs, so our own docs may not be as extensive as they could be. Yes, indeed I have always used gentoo without an initramfs and I am now looking into it because I want to make a bootable USB. > The short version is that the kernel is very limited in what it can > take in the root= option on the command line, and grub and other > bootloaders don't do anything to ID the root filesystem other than > passing whatever root= parameter you specify (I'd be interested in any > info to the contrary). I have always generated grub.cfg files with grub-mkconfig. In some cases I see here search --no-floppy --fs-uuid --set=root linux /kernel-XYZ root=/dev/sda4 ro As far as I understand it, the first line searches the partition where the kernel is located identifying it through the UUID. Then the second line loads the kernel passing /dev/sda4 as the system root. On the bootable USB stick, with an initramfs, however I have search --no-floppy --fs-uuid --set=root linux /kernel-XYZ root=UUID= ro so now also the root filesystem is identified by its UUID. Based on your comment that: > Anytime you see something like root=UUID=* that is being handled by an > initramfs. I understand that this parameter is passed by the kernel to the init script inside the initramfs which then uses "busybox findfs" to translate the UUID into a device name. Is this correct? > Basically an initramfs should be viewed as an extended bootloader. > For more exotic setups they're essentially required (such as > network-based root filesystems). The trend has also been to not add > new root-finding capabilities to the kernel as the initramfs is the > preferred way of doing things. If lvm+mdadm were being built today, > I'm not sure they would make the kernel capable of directly mounting > them as root. OK. Thank you again, Marco
Re: [gentoo-user] Kernel modules: initramfs vs. /lib/modules
On 02/13/2017 03:34 AM, Rich Freeman wrote: > Anytime you see something like root=UUID=* that is being handled by an > initramfs. And of course a UUID is more reliable than a device name, > since the latter can change if you add/remove a device, or maybe even > if your firmware is having a bad day. Identifying devices by UUID > ensures the right one gets found, assuming it is available. If you're > using something like mdadm/lvm there are alternatives to UUID, but the > point is the same, you're using a logical identifier that is based on > what is stored on the disks and not just what port it is connected to. > Are you sure? When I set up my EFI stub kernel on my Surface tablet, I did not use an initramfs and I use PARTUUID= in the kernel built in init line and it boots. I thought I was going to have to use an initramfs but I tried without it and it boots with no issues. Dan
Re: [gentoo-user] Kernel modules: initramfs vs. /lib/modules
On 13.02.2017 12:34, Rich Freeman wrote: > On Mon, Feb 13, 2017 at 5:53 AM, marco restelli wrote: >> Could you suggest any reference about how an initramfs can help making >> it easier to identify the correct root filesystem? Does this >> functionality overlap with what grub can do, or is something >> different? >> > The dracut references are fairly extensive, but they probably assume > that you already know about something like this. Keep in mind that on > virtually all other distros end-users aren't expected to set up their > own kernels or initramfs so there isn't a lot of general documentation > out there. And even within Gentoo a lot of people seem to avoid an > initramfs, so our own docs may not be as extensive as they could be. > > [...] There is some very good documentation about crafting your own initramfs it the Gentoo wiki: https://wiki.gentoo.org/wiki/Custom_Initramfs https://wiki.gentoo.org/wiki/Early_Userspace_Mounting
Re: [gentoo-user] Kernel modules: initramfs vs. /lib/modules
On Mon, Feb 13, 2017 at 5:53 AM, marco restelli wrote: > > Could you suggest any reference about how an initramfs can help making > it easier to identify the correct root filesystem? Does this > functionality overlap with what grub can do, or is something > different? > The dracut references are fairly extensive, but they probably assume that you already know about something like this. Keep in mind that on virtually all other distros end-users aren't expected to set up their own kernels or initramfs so there isn't a lot of general documentation out there. And even within Gentoo a lot of people seem to avoid an initramfs, so our own docs may not be as extensive as they could be. The short version is that the kernel is very limited in what it can take in the root= option on the command line, and grub and other bootloaders don't do anything to ID the root filesystem other than passing whatever root= parameter you specify (I'd be interested in any info to the contrary). The kernel itself can't handle UUIDs or filesystem labels. It actually can handle some situations like lvm on top of mdadm, but that is about as complex as it gets as far as I'm aware, and even in that situation there are some limitations. An initramfs is typically implemented in a bunch of shell scripts (though it is really a full userspace so in theory you can really have it do anything). That gives it a lot more flexibility. Typically they run udev which gives you all the /dev/disk/by-id symlinks and so on. They can also do things like fsck root before mounting it (though mounting it read-only and having it fsck itself isn't a terrible alternative, which is how things work without an initramfs). Basically an initramfs should be viewed as an extended bootloader. For more exotic setups they're essentially required (such as network-based root filesystems). The trend has also been to not add new root-finding capabilities to the kernel as the initramfs is the preferred way of doing things. If lvm+mdadm were being built today, I'm not sure they would make the kernel capable of directly mounting them as root. Anytime you see something like root=UUID=* that is being handled by an initramfs. And of course a UUID is more reliable than a device name, since the latter can change if you add/remove a device, or maybe even if your firmware is having a bad day. Identifying devices by UUID ensures the right one gets found, assuming it is available. If you're using something like mdadm/lvm there are alternatives to UUID, but the point is the same, you're using a logical identifier that is based on what is stored on the disks and not just what port it is connected to. -- Rich
Re: [gentoo-user] Kernel modules: initramfs vs. /lib/modules
2017-02-10 13:35 GMT+01:00, Rich Freeman : > On Fri, Feb 10, 2017 at 6:58 AM, marco restelli > wrote: >> Hi all, >>I am trying to understand a bit initramfs and genkernel and I have >> few (basic) questions. > >> - how does genkernel decide which modules to put in the initramfs ? > > I can't speak to genkernel specifically, but most initramfs generators > include all modules. Other than space and miniscule load time there > isn't much reason not to. After checking, genkernel copies only some modules into the initramfs, unless the --all-ramdisk-modules flag is used. Concerning the rest of your reply: thank you so much, it really helped me a lot! Could you suggest any reference about how an initramfs can help making it easier to identify the correct root filesystem? Does this functionality overlap with what grub can do, or is something different? Thank you, Marco
Re: [gentoo-user] Kernel modules: initramfs vs. /lib/modules
On Fri, Feb 10, 2017 at 6:58 AM, marco restelli wrote: > Hi all, >I am trying to understand a bit initramfs and genkernel and I have > few (basic) questions. > > I understand that one must have in the initramfs those modules which > are required to boot the system, for instance to access /dev . Now: Sort-of. You need an initramfs if the kernel cannot otherwise mount /, and /usr (if it isn't on the same filesystem as /). Being able to mount / is an absolute requirement, there are other ways to go about mounting /usr. An initramfs has some benefits even if the kernel could mount /, such as making it easier or more reliable to identify the correct root filesystem. > > - can a module be present both in the initramfs and as kernel module > in /lib/modules ? > Yes, and typically all of the initramfs modules are present in both. > - how does genkernel decide which modules to put in the initramfs ? I can't speak to genkernel specifically, but most initramfs generators include all modules. Other than space and miniscule load time there isn't much reason not to. > > - can modules included in the initramfs be unloaded once the system is > running, as modprobe -r Yes, assuming it isn't in use. Most of the stuff loaded by the initramfs is probably going to be in use until you shut down (such as the module for the root filesystem). > > - can modprobe load modules from the initramfs ? > Only if it is run from within the initramfs. Otherwise this is like asking whether a binary in a chroot can run something outside the chroot. Of course, typically all the initramfs modules are also present in /lib so modprobe will just load the module from there. > > Well, clearly I am a bit confused about the topic - I hope somebody > can help me a bit! > An initramfs is really just a chroot in some sense. Though, it would be more accurate to say that the system you're using after you've booted is the chroot, and the initramfs was the original host. The initramfs is the root filesystem when the kernel boots, and it basically does whatever it needs to to find the real root filesystem, mount it, and then it deletes its stuff to free up ram, chroots to the real root, and execs the real init. At that point very little of the initramfs is left, other than any kernel modules it might have loaded (which are no different from kernel modules loaded at a later point in time). It is just a way to do userspace bootstrapping. Coreboot/libreboot take this to yet another level. Rather than try to build the smarts into the kernel to handle every conceivable system configuration, the kernel provides the driver and some basic logic, and if you want to do something fancier you use an initramfs and the initramfs can do anything you can do in linux userspace to find and mount root. It could download root from a webserver, or launch postfix and wait for somebody to send the root filesystem as an attachment, or whatever your imagination can come up with. Usually, though, it ends up just mounting /dev/sda2 or whatever. Most distros use an initramfs by default because it is more robust and can handle things like UUIDs and labels. That way if you plug in a new drive and your existing drives get renumbered the correct filesystem gets mounted. That, and it lets them use highly modular kernels without having to know what kind of filesystem you'll use for /, since it can just be modprobed at run time. This lets them build all the drivers as modules, which costs some disk space and a lot of one-time compile time, but gives the end-user more flexibility without any need to custom-build a kernel. Gentoo is a bit unusual in encouraging users to build their own kernels, but of course once you do that then there is no need to build all the drivers, or use an initramfs for modules needed to mount /. Otherwise, there is nothing special about modules loaded from the initramfs. They're just kernel modules. -- Rich
Re: [gentoo-user] Kernel Modules
On 15 June 2011, at 19:05, Peter Humphrey wrote: > On Wednesday 15 June 2011 17:25:23 Neil Bothwick wrote: >> On Wed, 15 Jun 2011 17:07:01 +0100, Peter Humphrey wrote: >>> I'd like to use this but I don't have shopt. Which package is it in? If >>> I ask Google I get a list of places to buy T-shirts. >> >> It's a Bash built-in. > > Hmm. It seems that the command from the Wiki can't be run as an ordinary > user via sudo; … Did you try: sudo bash -c 'whatever' ? Personally, I haven't used Gentoo's bash completion since 2009. http://www.gossamer-threads.com/lists/gentoo/user/189292 I don't really feel that I can trust it. Stroller.
Re: [gentoo-user] Kernel Modules
On 09/06/11 12:06, Alan McKinnon wrote: > why you making so much work for yourself? > > set the /usr/src/linux symlink to each set of installed sources in turn, > run emerge @module-rebuild > or run module-rebuild rebuild > > you could even script it > > cd /usr/src > for I in linux-* > do > ln -sfn $I linux > module-rebuild rebuils > done > > Fixing my bash syntax errors is left as an exercise for the interested reader Thanks very much! I am a former Arch user, so I was used for a lot of inconvenience while doing such things, but gentoo seems to make my life easier and easier. Ignas
Re: [gentoo-user] Kernel Modules
On Thursday 09 June 2011 11:52:42 Ignas Anikevicius wrote: > Hello list, > > I was wondering if it is possible to have a tool with which it would be > possible to have external modules installed for _all_ kernel versions in > my computer. Now I am using 2.6.38 kernel, but would like to try 2.6.39 > and the thing is that I would like to have tp_smapi and phc-intel > modules in both kernels. Is it possible to have it without any serious > hacking? > > I have only 3 ideas how I could achieve that: > * Making a custom ebuild, which would build the modules, but install > itself as a different package depending on the kernel version (eg > tp_smapi-2.6.39-gentoo)? > * Making a custom ebuild, which would build the modules for all kernel > versions in one go... (is this possible?) > * patching the gentoo-sources each time. > > Is any of these solutions sensible? > > Cheers, > Ignas why not emerging them several times with linux pointing to the different kernels? I that does not work: ebuild unpack ebuild compile ebuild install cp .ko from image directory to modules directory depmod -ae -- #163933
Re: [gentoo-user] Kernel Modules
Apparently, though unproven, at 12:52 on Thursday 09 June 2011, Ignas Anikevicius did opine thusly: > Hello list, > > I was wondering if it is possible to have a tool with which it would be > possible to have external modules installed for _all_ kernel versions in > my computer. Now I am using 2.6.38 kernel, but would like to try 2.6.39 > and the thing is that I would like to have tp_smapi and phc-intel > modules in both kernels. Is it possible to have it without any serious > hacking? > > I have only 3 ideas how I could achieve that: > * Making a custom ebuild, which would build the modules, but install > itself as a different package depending on the kernel version (eg > tp_smapi-2.6.39-gentoo)? > * Making a custom ebuild, which would build the modules for all kernel > versions in one go... (is this possible?) > * patching the gentoo-sources each time. why you making so much work for yourself? set the /usr/src/linux symlink to each set of installed sources in turn, run emerge @module-rebuild or run module-rebuild rebuild you could even script it cd /usr/src for I in linux-* do ln -sfn $I linux module-rebuild rebuils done Fixing my bash syntax errors is left as an exercise for the interested reader -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Kernel Modules
On Thu, Jun 09, 2011 at 11:52:42AM +0100, Ignas Anikevicius wrote: > Hello list, > > I was wondering if it is possible to have a tool with which it would be > possible to have external modules installed for _all_ kernel versions in > my computer. Now I am using 2.6.38 kernel, but would like to try 2.6.39 > and the thing is that I would like to have tp_smapi and phc-intel > modules in both kernels. Is it possible to have it without any serious > hacking? > > I have only 3 ideas how I could achieve that: > * Making a custom ebuild, which would build the modules, but install > itself as a different package depending on the kernel version (eg > tp_smapi-2.6.39-gentoo)? > * Making a custom ebuild, which would build the modules for all kernel > versions in one go... (is this possible?) > * patching the gentoo-sources each time. kernel modules are CONFIG_PROTECTED, so they are not automatically removed when you uninstall / remerge the package (you have to remove them manually), so you just have to remerge the package after you change the /usr/src/linux symlink there is also the module-rebuild utility, that automatically remerges packages that installed a kernel module i.e. ln -sfn linux-VERSION1 /usr/src/linux module-rebuild -X rebuild ln -sfn linux-VERSION2 /usr/src/linux module-rebuild -X rebuild ... you might have to do module-rebuild populate before the first time... yoyo
Re: [gentoo-user] Kernel modules not autoloading with 2.6.38-gentoo-r1
On Apr 11, 2011 3:42 AM, "du yang" wrote: > > On Monday 04/11/11 12:57:34 CST, James Wall wrote: > > Hi all, > > Has anyone run into an issue where the kernel is not detecting devices? The > > issue does not show up in 2.6.37 on amd64 testing branch. I just got done > > re-emerging world to rule out any hidden surprises. Any ideas? > > TIA, > > James Wall > > > > Could it be manually loaded? > you could try using modprobe to manually load it to see if there is any error. > > I have had my nvidia driver couldn't be loaded, finally I found it is kernel version no match. > > -- > oooO: > (..): > :\.(:::Oooo:: > ::\_)::(..):: > :::)./::: > ::(_/ > The modules will load if I modprobe them but the video driver which has been built-in does not detect the radeon 9200 card. I copied over the configuration from my working 2.6.37 kernel and ran make oldconfig. Thanks for the suggestion though. James Wall
Re: [gentoo-user] Kernel modules not autoloading with 2.6.38-gentoo-r1
On Monday 04/11/11 12:57:34 CST, James Wall wrote: > Hi all, > Has anyone run into an issue where the kernel is not detecting devices? The > issue does not show up in 2.6.37 on amd64 testing branch. I just got done > re-emerging world to rule out any hidden surprises. Any ideas? > TIA, > James Wall > Could it be manually loaded? you could try using modprobe to manually load it to see if there is any error. I have had my nvidia driver couldn't be loaded, finally I found it is kernel version no match. -- oooO: (..): :\.(:::Oooo:: ::\_)::(..):: :::)./::: ::(_/
