[gentoo-dev] Re: udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
Richard Yao posted on Sun, 18 Nov 2012 00:35:22 -0500 as excerpted: Having a builtin is a good idea, but the implementation as a mandatory dependency on kmod is not. The plan is to reintroduce it as an optional dependency, so that distributions (and Gentoo users) that do not want it can avoid it. None of us want to force dependencies on others and there is no need for this one. You do realize that you didn't really drop the dependency at all, right? kmod does not exist on my system and eudev builds without a problem. I am thinking of writing my own busybox-style code to handle module loading in the builtin when the configure script is told not to build with kmod. Does this not avoid the dependency? FWIW... I run a monolithic kernel here, no modules /to/ load. As a result, for quite some time I had module-init-tools in package.provided, because I really didn't need it at all. Then udev switched to kmod as a build-time dep. I could no longer package.provide kmod as I had module-init-tools, because it was required to /build/ udev. For no valid reason on my system. Like any unnecessary feature that can be used to load an exploit, it's worse than useless. But it was required to build, just because someone decided people had no valid reason to run a monolithic kernel system any longer, and that people who did so apparently no longer mattered, udev-wise. That's only one such decision of a whole list following a similar pattern, simply deciding that some segment of the Linux-using populace or another no longer matters, because it's not the segment that the udev folks are focused on. In many cases, they've already said they're not interested in patches resolving the issues, too. Thus, no, submitting the patches for inclusion upstream isn't working. Seems reason enough for a fork, to me. Back on subtopic, yes, I'm definitely interested in a udev fork that doesn't force the otherwise useless on my systems kmod as a build-time dep. package.provided worked for years as a workaround for the module- init-tools @system dep. And I'd like to get back to not having to have a module-loader package installed at all, since I don't have any modules to load anyway. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 12:06 AM, Duncan 1i5t5.dun...@cox.net wrote: Richard Yao posted on Sun, 18 Nov 2012 00:35:22 -0500 as excerpted: Having a builtin is a good idea, but the implementation as a mandatory dependency on kmod is not. The plan is to reintroduce it as an optional dependency, so that distributions (and Gentoo users) that do not want it can avoid it. None of us want to force dependencies on others and there is no need for this one. You do realize that you didn't really drop the dependency at all, right? kmod does not exist on my system and eudev builds without a problem. I am thinking of writing my own busybox-style code to handle module loading in the builtin when the configure script is told not to build with kmod. Does this not avoid the dependency? FWIW... I run a monolithic kernel here, no modules /to/ load. As a result, for quite some time I had module-init-tools in package.provided, because I really didn't need it at all. Then udev switched to kmod as a build-time dep. I could no longer package.provide kmod as I had module-init-tools, because it was required to /build/ udev. For no valid reason on my system. Like any unnecessary feature that can be used to load an exploit, it's worse than useless. But it was required to build, just because someone decided people had no valid reason to run a monolithic kernel system any longer, and that people who did so apparently no longer mattered, udev-wise. That's only one such decision of a whole list following a similar pattern, simply deciding that some segment of the Linux-using populace or another no longer matters, because it's not the segment that the udev folks are focused on. In many cases, they've already said they're not interested in patches resolving the issues, too. Thus, no, submitting the patches for inclusion upstream isn't working. Seems reason enough for a fork, to me. Back on subtopic, yes, I'm definitely interested in a udev fork that doesn't force the otherwise useless on my systems kmod as a build-time dep. package.provided worked for years as a workaround for the module- init-tools @system dep. And I'd like to get back to not having to have a module-loader package installed at all, since I don't have any modules to load anyway. # du -sh /var/tmp/portage/sys-apps/kmod-11-r1/image/ 240K/var/tmp/portage/sys-apps/kmod-11-r1/image/
Re: [gentoo-dev] Re: udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
Matt Turner schrieb: Then udev switched to kmod as a build-time dep. I could no longer package.provide kmod as I had module-init-tools, because it was required to /build/ udev. For no valid reason on my system. Like any unnecessary feature that can be used to load an exploit, it's worse than useless. # du -sh /var/tmp/portage/sys-apps/kmod-11-r1/image/ 240K /var/tmp/portage/sys-apps/kmod-11-r1/image/ I think the complaint was not about the installed size. Some people have install as little unnecessary code as possible as part of their security concepts. Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] Re: udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
Chí-Thanh Christopher Nguyễn posted on Sun, 18 Nov 2012 12:14:48 +0100 as excerpted: Matt Turner schrieb: Then udev switched to kmod as a build-time dep. I could no longer package.provide kmod as I had module-init-tools, because it was required to /build/ udev. For no valid reason on my system. Like any unnecessary feature that can be used to load an exploit, it's worse than useless. # du -sh /var/tmp/portage/sys-apps/kmod-11-r1/image/ 240K /var/tmp/portage/sys-apps/kmod-11-r1/image/ I think the complaint was not about the installed size. Some people have install as little unnecessary code as possible as part of their security concepts. That's true, but as a long-term gentooer, I've found over the years it's more than that. Every single installed package is another package that must be repeatedly rebuilt, as upgrades come in and/or as the system core toolchain changes over time and one wants to be sure the whole system is consistent and still buildable (emerge --emptytree @world). Every installed package I don't use is thus an installed package I'll spend a lot of otherwise unnecessary time on, over the years, simply keeping it and the system in general upto date. As one realizes the cost over time, one gets a rather higher motivation to keep the system as lean and mean as possible. I look at it this way, it's just that much more incentive to practice what has always been known as good security practice in any case, keeping everything off the system that doesn't have a solid, known reason, for being there. kmod itself is trivial in size time and space requirements, but it's the principle as much as anything, and in the case of an unneeded module loader there's an additional security concern as well, since an opportunity to load kernel modules is just that much more opportunity to install a kernel module that hides otherwise visible tell-tail (logs, strange open ports on netstat, strange startup services, etc) signs of being rooted. Sure, if someone has module-loading access already, it's not a big increased risk, but given that it's an unnecessary, any non- negative non-zero increase in risk or maintenance cost over time is unacceptable, and on a monolithic kernel gentoo system, a kernel module loader increases both, trivially sure, but when there's no justifiable reason for it in the first place... -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
Duncan wrote: kmod itself is trivial in size time and space requirements, but it's the principle as much as anything, and in the case of an unneeded module loader there's an additional security concern as well I'm afraid this is flawed. If you want to hinder modules from being loaded then you need to disable modules in the kernel, and not rely on insmod not being installed on the system. Look at insmod in asmutils, my guess is that actual work of loading a module is less than 42 instructions. risk or maintenance cost .. on a monolithic kernel gentoo system, a kernel module loader increases both Forget about the loader. Your knob is in a different configuration, specifically CONFIG_MODULES=n in the kernel. That said, it's a perfectly good point that kmod is a useless dependency on your system and all like it, and that it would be nice for Gentoo to know about this and not pull it in. I guess this could be accomplished with a USE=kernelmodules flag that makes the dep optional and applies a simple patch or two before building udev from systemd sources, and I guess that patches for the udev ebuild are welcome. :) //Peter
[gentoo-dev] Re: udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
Peter Stuge posted on Sun, 18 Nov 2012 19:00:59 +0100 as excerpted: Forget about the loader. Your knob is in a different configuration, specifically CONFIG_MODULES=n in the kernel. Just to note now that the specific topic has come up, yes, I am aware of and have that kernel option set to disable module loading. I was simply focusing on userland side, and thus didn't believe the kernel option apropos to that specific discussion. Still, just having a module loading userland on the system doesn't /increase/ security, and in fact, it slightly decreases it, on a system where a deliberate choice has been made to turn kernel module loading functionality off. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 11/18/2012 2:39 PM, Duncan wrote: Peter Stuge posted on Sun, 18 Nov 2012 19:00:59 +0100 as excerpted: Forget about the loader. Your knob is in a different configuration, specifically CONFIG_MODULES=n in the kernel. Just to note now that the specific topic has come up, yes, I am aware of and have that kernel option set to disable module loading. I was simply focusing on userland side, and thus didn't believe the kernel option apropos to that specific discussion. Still, just having a module loading userland on the system doesn't /increase/ security, and in fact, it slightly decreases it, on a system where a deliberate choice has been made to turn kernel module loading functionality off. Pointing out as a general statement, and not in response to anyone in particular, while I, too, am in the camp of minimalistic userlands, there is a kind of threshold one hits in this regard where keeping or removing something like a couple of module-loading utilities or systemd text files around really isn't going to increase or decrease your security /by that much/. /run-on-sentence I mean, if someone gains unauthorized access to the userland and somehow uses these unused components to launch an attack, successful or not, well, then there's a LOT of bigger problems to worry about. The goal of security isn't to prevent someone from gaining unauthorized access to a system, it's to deter them or otherwise make the effort required more than the potential gain. Design network firewalls well, audit the user accounts and review logs periodically, enabled hardened options, use PaX/grsec/selinux, deploy an IDS/IPS and a SEIM, etc...there's a lot of other things one can do that will have a bigger ROI on security than gutting module-loading tools or systemd scripts off of a system. Do I like them there? Not really (unless I'm developing a kernel driver, then modules come in handy). But it is what it is. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
