re: Proposal: Disable autoload of compat_xyz modules
> compat_linux > compat_linux32 > compat_netbsd32 all of these are used regularly by many netbsd users. please don't include them in your list of targets. saying "modload is OK" is not how we treat the GENERIC kernel -- if it's OK, then it's OK for GENERIC is how we treat that. the latter is also essential for our mips64 platforms. also, these "not now" items you listed: > exec_elf32 > exec_elf64 > exec_script how else do you expect to be able to run elf binaries or any sort of scripts? ie, these should never be targets for removal. .mrg.
Re: Proposal: Disable autoload of compat_xyz modules
Le 02/08/2017 à 10:19, matthew green a écrit : compat_linux compat_linux32 compat_netbsd32 all of these are used regularly by many netbsd users. please don't include them in your list of targets. saying "modload is OK" is not how we treat the GENERIC kernel -- if it's OK, then it's OK for GENERIC is how we treat that. the latter is also essential for our mips64 platforms. As said earlier, the last one indeed should not be in this list. But the first two should. If it's not how we treat the GENERIC kernel, then let's treat it this way from now on. There is a clear difference between "modload is ok" and "generic is ok"; the former needs root's intervention at some point, the latter is open to unprivileged users. Closing the door to unprivileged processes by default is precisely the goal here. When a vulnerability is found in compat_linux or compat_linux32 - which regularly is the case -, it won't affect the base system anymore.
Re: Proposal: Disable autoload of compat_xyz modules
>> exec_elf32 >> exec_elf64 >> exec_script > how else do you expect to be able to run elf binaries or any sort of > scripts? ie, these should never be targets for removal. Even elf64 on a 32-bit system, or elf32 on a 64-bit system? (Uhere "system" refers to userland; sparc32 userland under sparc64 kernel needs elf32 but not elf64) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Proposal: Disable autoload of compat_xyz modules
> Date: Wed, 02 Aug 2017 18:19:27 +1000 > from: matthew green > > > compat_linux > > compat_linux32 > > compat_netbsd32 > > all of these are used regularly by many netbsd users. please don't > include them in your list of targets. saying "modload is OK" is > not how we treat the GENERIC kernel -- if it's OK, then it's OK for > GENERIC is how we treat that. > > the latter is also essential for our mips64 platforms. Evidently my original message was very confusing, for which I apologize -- you're about the fourth person to have read it this way. Let me try to be a little clearer here. I propose to disable the following modules by default, but leave the code so you can still modload them or include them in your custom kernel config if you want: compat_freebsd compat_ibcs2 compat_linux compat_linux32 compat_ndis compat_osf1 compat_sunos compat_sunos32 compat_svr4 compat_svr4_32 compat_ultrix exec_coff exec_ecoff I *DO NOT* propose *ANY* changes to the following modules, and I make no representation about their notoriety or non-notoriety for bugginess, and I'm not asking about users of them, even though they appear at first glance to match or be relevant to the `compat_xyz' pattern mentioned in the subject or the other modules listed here: compat (i.e., old-NetBSD binary compat) compat_aoutm68k compat_netbsd32 exec_aout exec_elf32 exec_elf64 exec_script
Re: Proposal: Disable autoload of compat_xyz modules
> Date: Wed, 02 Aug 2017 18:19:27 +1000 > from: matthew green > > > compat_linux > > compat_linux32 > > all of these are used regularly by many netbsd users. please don't > include them in your list of targets. Does anyone use compat_linux without also doing the additional system configuration steps of setting up /emul? Is it an onerous burden to have to modload or add a line in /etc/modules.conf in those steps? For users like me who don't care about running proprietary binary blobs for Linux, compat_linux carries no benefit -- only the cost of additional attack surface. (This does not extend beyond compat_linux. E.g., random hardware devices for which we have drivers confer the benefit that I might run into the hardware some day. But I'm not going to run Linux binaries without a clear conscious decision.) For the users who do derive value from compat_linux, the cost of requiring modload to enable it seems negligible to me. > saying "modload is OK" is not how we treat the GENERIC kernel -- if > it's OK, then it's OK for GENERIC is how we treat that. That standard suggests we should remove the buggy unmaintained compat modules altogether, which struck me as a more extreme proposal than I care to push for now. (I'm also not sure the set of modules we build adheres to that standard as is, even outside the compat modules.) If you want to propose deletion, that's fine. What is not tenable is leaving everything as is, as we've done in the past, just because nobody has the energy either to maintain the code or to push for deletion.
Re: Proposal: Disable autoload of compat_xyz modules
> Does anyone use compat_linux without also doing the additional system > configuration steps of setting up /emul? Is it an onerous burden to > have to modload or add a line in /etc/modules.conf in those steps? Not me. Not for me (I build my custom kernels anyway).
Re: Proposal: Disable autoload of compat_xyz modules
Hello. My feeling is that the cost of requiring a modload to use compat_linux and compat_linux32 is fine. My concern is that by taking it out of the GENERIC kernel configuration, we lose the regular testing, such as it is, with the daily builds. Sure, the module gets built, but it could be a while before it gets loaded and run by the test harness. Today, with these modules in GENERIC, the modules get loaded as a matter of course. Is there a way to rig our test harness so that you can take the modules out of the GENERIC kernel configuration and still do more than compile-time test them? -thanks -Brian
Re: Proposal: Disable autoload of compat_xyz modules
On Wed, Aug 02, 2017 at 07:56:50AM -0700, Brian Buhrow wrote: > Hello. My feeling is that the cost of requiring a modload to use > compat_linux and compat_linux32 is fine. My concern is that by taking it > out of the GENERIC kernel configuration, we lose the regular testing, such > as it is, with the daily builds. Sure, the module gets built, but it could > be a while before it gets loaded and run by the test harness. Today, with > these modules in GENERIC, the modules get loaded as a matter of course. > Is there a way to rig our test harness so that you can take the modules out > of the GENERIC kernel configuration and still do more than compile-time > test them? The tests exercise quite a few modules, but currently testing compat stuff is tricky (due to the extra setup needed on the test machine to have a create the compat runtime environment). Just doing a few modctl and load some of them is simple, but what does that actually buy us? Martin
Re: Proposal: Disable autoload of compat_xyz modules
On Wed, Aug 02, 2017 at 01:04:27PM +, Taylor R Campbell wrote: > Does anyone use compat_linux without also doing the additional system > configuration steps of setting up /emul? Is it an onerous burden to > have to modload or add a line in /etc/modules.conf in those steps? Yes, COMPAT_LINUX is one of netbsd/pkgsrc's biggest user friendliness wins. I can 'cd pkgsrc/www/opera; make install; opera' and get a closed source browser that works as is, without even realizing it relies on COMPAT_LINUX to work. Unless some miracle happens, NetBSD will remain an esoteric operating system, and we won't have many closed source programs if any. A fairly small amount of code gives us access to a large number of programs that we would otherwise not have access to.
Re: Proposal: Disable autoload of compat_xyz modules
> Date: Wed, 2 Aug 2017 07:56:50 -0700 > From: Brian Buhrow > > Hello. My feeling is that the cost of requiring a modload to use > compat_linux and compat_linux32 is fine. My concern is that by taking it > out of the GENERIC kernel configuration, we lose the regular testing, such > as it is, with the daily builds. Sure, the module gets built, but it could > be a while before it gets loaded and run by the test harness. Today, with > these modules in GENERIC, the modules get loaded as a matter of course. > Is there a way to rig our test harness so that you can take the modules out > of the GENERIC kernel configuration and still do more than compile-time > test them? We do not currently automatically test the compat modules as far as I know. Volunteers are welcome to write automated tests of compat! (The code will also continue to be compile-tested as non-module via the ALL kernels.)
Re: Proposal: Disable autoload of compat_xyz modules
Taylor R Campbell wrote: >(The code will also continue to be compile-tested as non-module via >the ALL kernels.) Maybe we need an ALL kernel for sparc64.
Re: Proposal: Disable autoload of compat_xyz modules
> Unless some miracle happens, NetBSD will remain an esoteric operating > system, and we won't have many closed source programs if any. Wearing my iconoclast hat... ...would that be a bad thing? Those who want Linux do know where to find it, after all. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Proposal: Disable autoload of compat_xyz modules
> Date: Wed, 2 Aug 2017 16:11:16 + > From: m...@netbsd.org > > I can 'cd pkgsrc/www/opera; make install; opera' and get a closed source > browser that works as is, without even realizing it relies on > COMPAT_LINUX to work. % cd www/opera && bmake package ERROR: This package has set PKG_FAIL_REASON: ERROR: opera-12.16 has an unacceptable license condition: ERROR: opera-1200-license ERROR: You can mark the license ``opera-1200-license'' as acceptable by adding ERROR: ACCEPTABLE_LICENSES+= opera-1200-license ERROR: to /home/riastradh/pkgsrc/current/pkg/etc/mk.conf or by adding ERROR: ACCEPTABLE_LICENSES= opera-1200-license ERROR: to /home/riastradh/pkgsrc/current/pkg/etc/pkg_install.conf. ERROR: The following command will show you the license text: ERROR: /home/riastradh/pkgsrc/current/pkg/bin/bmake show-license > Unless some miracle happens, NetBSD will remain an esoteric operating > system, and we won't have many closed source programs if any. A fairly > small amount of code gives us access to a large number of programs that > we would otherwise not have access to. I'm not proposing removing the code. Just having a knob to turn it on before you're exposed to its attack surface. But it sounds like there are a number of people who want compat_linux to remain enabled, and of the compat modules I expect it is the best- maintained, so I will withdraw the proposal to disable it by default. However, we still need some way to automatically test it so that developers other than manu@ can apply security fixes without blindly breaking things.
Re: Proposal: Disable autoload of compat_xyz modules
Le 02/08/2017 à 18:11, m...@netbsd.org a écrit : On Wed, Aug 02, 2017 at 01:04:27PM +, Taylor R Campbell wrote: Does anyone use compat_linux without also doing the additional system configuration steps of setting up /emul? Is it an onerous burden to have to modload or add a line in /etc/modules.conf in those steps? Yes, COMPAT_LINUX is one of netbsd/pkgsrc's biggest user friendliness wins. I can 'cd pkgsrc/www/opera; make install; opera' and get a closed source browser that works as is, without even realizing it relies on COMPAT_LINUX to work. Unless some miracle happens, NetBSD will remain an esoteric operating system, and we won't have many closed source programs if any. A fairly small amount of code gives us access to a large number of programs that we would otherwise not have access to. Certainly. But the problem is, this small amount of code opens the door to a large number of potential vulnerabilities too. The last one was fixed only two or three months ago.
Re: Proposal: Disable autoload of compat_xyz modules
On 02.08.2017 20:02, Taylor R Campbell wrote: >> Date: Wed, 2 Aug 2017 16:11:16 + >> From: m...@netbsd.org >> >> I can 'cd pkgsrc/www/opera; make install; opera' and get a closed source >> browser that works as is, without even realizing it relies on >> COMPAT_LINUX to work. > > % cd www/opera && bmake package > ERROR: This package has set PKG_FAIL_REASON: > ERROR: opera-12.16 has an unacceptable license condition: > ERROR: opera-1200-license > ERROR: You can mark the license ``opera-1200-license'' as acceptable by adding > ERROR: ACCEPTABLE_LICENSES+= opera-1200-license > ERROR: to /home/riastradh/pkgsrc/current/pkg/etc/mk.conf or by adding > ERROR: ACCEPTABLE_LICENSES= opera-1200-license > ERROR: to /home/riastradh/pkgsrc/current/pkg/etc/pkg_install.conf. > ERROR: The following command will show you the license text: > ERROR: /home/riastradh/pkgsrc/current/pkg/bin/bmake show-license > >> Unless some miracle happens, NetBSD will remain an esoteric operating >> system, and we won't have many closed source programs if any. A fairly >> small amount of code gives us access to a large number of programs that >> we would otherwise not have access to. > > I'm not proposing removing the code. Just having a knob to turn it on > before you're exposed to its attack surface. > > But it sounds like there are a number of people who want compat_linux > to remain enabled, and of the compat modules I expect it is the best- > maintained, so I will withdraw the proposal to disable it by default. > However, we still need some way to automatically test it so that > developers other than manu@ can apply security fixes without blindly > breaking things. > I think we can go into a different direction. Instead of disabling the code - we could turn all compat_ into dynamically loadable modules. I would profit from it for functional out-of-the-box compat for older NetBSD releases (a.out executables). For security purposes people can raise securelevel and prevent any modules from insertion into the kernel. signature.asc Description: OpenPGP digital signature
Re: Proposal: Disable autoload of compat_xyz modules
On Wed, Aug 02, 2017 at 06:02:57PM +, Taylor R Campbell wrote: > % cd www/opera && bmake package > ERROR: This package has set PKG_FAIL_REASON: > ERROR: opera-12.16 has an unacceptable license condition: > ERROR: opera-1200-license > ERROR: You can mark the license ``opera-1200-license'' as acceptable by adding > ERROR: ACCEPTABLE_LICENSES+= opera-1200-license > ERROR: to /home/riastradh/pkgsrc/current/pkg/etc/mk.conf or by adding > ERROR: ACCEPTABLE_LICENSES= opera-1200-license > ERROR: to /home/riastradh/pkgsrc/current/pkg/etc/pkg_install.conf. > ERROR: The following command will show you the license text: > ERROR: /home/riastradh/pkgsrc/current/pkg/bin/bmake show-license Fair enough, I set SKIP_LICENSE_CHECK=yes always for vim.
Re: Proposal: Disable autoload of compat_xyz modules
p...@whooppee.com (Paul Goyette) writes: >If you're using /etc/modules.conf, why not just modunload the modules >you want to remove? (Modules "pushed" from /boot.conf cannot be >unloaded, as far as I understand.) It's the loading part that is prohibited :) -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Proposal: Disable autoload of compat_xyz modules
Le 02/08/2017 à 20:02, Taylor R Campbell a écrit : Date: Wed, 2 Aug 2017 16:11:16 + From: m...@netbsd.org I can 'cd pkgsrc/www/opera; make install; opera' and get a closed source browser that works as is, without even realizing it relies on COMPAT_LINUX to work. % cd www/opera && bmake package ERROR: This package has set PKG_FAIL_REASON: ERROR: opera-12.16 has an unacceptable license condition: ERROR: opera-1200-license ERROR: You can mark the license ``opera-1200-license'' as acceptable by adding ERROR: ACCEPTABLE_LICENSES+= opera-1200-license ERROR: to /home/riastradh/pkgsrc/current/pkg/etc/mk.conf or by adding ERROR: ACCEPTABLE_LICENSES= opera-1200-license ERROR: to /home/riastradh/pkgsrc/current/pkg/etc/pkg_install.conf. ERROR: The following command will show you the license text: ERROR: /home/riastradh/pkgsrc/current/pkg/bin/bmake show-license Unless some miracle happens, NetBSD will remain an esoteric operating system, and we won't have many closed source programs if any. A fairly small amount of code gives us access to a large number of programs that we would otherwise not have access to. I'm not proposing removing the code. Just having a knob to turn it on before you're exposed to its attack surface. But it sounds like there are a number of people who want compat_linux to remain enabled, and of the compat modules I expect it is the best- maintained, so I will withdraw the proposal to disable it by default. I disagree. The cost of doing a modload is low enough compared to the configuration needed to use compat_linux. Just like the command you quoted. People who regularly use compat_linux can modify /etc/modules.conf, and will never have to worry about it anymore. They may have to worry about the potential vulnerabilities in it, but what's more important, is that those who do not use compat_linux (still a majority of people) don't.
Re: Proposal: Disable autoload of compat_xyz modules
On Wed, Aug 02, 2017 at 09:17:05PM +0200, Kamil Rytarowski wrote: > I think we can go into a different direction. Instead of disabling the > code - we could turn all compat_ into dynamically loadable modules. I > would profit from it for functional out-of-the-box compat for older > NetBSD releases (a.out executables). No, please not. It is already quite unclear how many of them even work properly and a GENERIC kernel should continue to work as it is. If you want a MODULAR kernel, pick one. Don't force it on every one else. Joerg
Re: Proposal: Disable autoload of compat_xyz modules
On Wed, Aug 02, 2017 at 08:52:15PM +0200, Maxime Villard wrote: > I disagree. The cost of doing a modload is low enough compared to the > configuration needed to use compat_linux. Just like the command you quoted. If I wanted OpenBSD, I know were to get it. There is a balance between pissing off people and providing security. If you want to minimize the attack surface at all cost of *your* system, you are free to do so. Otherwise it has to be balanced. So far modules have primarily created problems for a lot of people without any gain. Disabling rarely used code is one thing, disabling commonly used code is something else. Stop pushing for "security" as a single goal above else. It doesn't make you more credible, it just makes people shot down sensible proposal as knee jerk reaction because they are waiting for the insane follow-up. Joerg
Re: Proposal: Disable autoload of compat_xyz modules
On Wed, 2 Aug 2017, Kamil Rytarowski wrote: I think we can go into a different direction. Instead of disabling the code - we could turn all compat_ into dynamically loadable modules. I would profit from it for functional out-of-the-box compat for older NetBSD releases (a.out executables). Most of the compat code is already available as dynamically-loadable modules. But there are a few exceptions. See my PRs kern/51597 and kern/52193 for a couple examples. For security purposes people can raise securelevel and prevent any modules from insertion into the kernel. They can also adjust kern.moudle.autoload to enable/disable automatic loading of modules (modulo securelevel). +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
Re: Proposal: Disable autoload of compat_xyz modules
Taylor R Campbell wrote: > This is a compromise between preserving the functionality and reducing > attack surface for what I hypothesize are a majority of users who do > not use it. Under this proposal, the code will remain, and still be > built, and still be usable -- it will just not be enabled by default. Once every compatibility module would not loaded by default, pehaps the compat_xxx module could be loaded automatically if /emul/xxx/ exists? The presence of that hierarchy means the system administrator really meant to use compat_xxx, and it would avoid breaking existing system at upgrade time. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: Proposal: Disable autoload of compat_xyz modules
On Aug 2, 5:02pm, Martin Husemann wrote: } On Wed, Aug 02, 2017 at 07:56:50AM -0700, Brian Buhrow wrote: } > Hello. My feeling is that the cost of requiring a modload to use } > compat_linux and compat_linux32 is fine. My concern is that by taking it } > out of the GENERIC kernel configuration, we lose the regular testing, such } > as it is, with the daily builds. Sure, the module gets built, but it could } > be a while before it gets loaded and run by the test harness. Today, with } > these modules in GENERIC, the modules get loaded as a matter of course. } > Is there a way to rig our test harness so that you can take the modules out } > of the GENERIC kernel configuration and still do more than compile-time } > test them? } } The tests exercise quite a few modules, but currently testing compat stuff } is tricky (due to the extra setup needed on the test machine to have a } create the compat runtime environment). } } Just doing a few modctl and load some of them is simple, but what does that } actually buy us? Originally, it was my thought that compiling it as a module and not using it is the same as compiling it into the kernel and not using it. However, it is possible to create a module that fails to load due to run time linking issues. So, having a test that does modload ensures that the module can still linked into the kernel. }-- End of excerpt from Martin Husemann
Re: Proposal: Disable autoload of compat_xyz modules
On Wed, Aug 02, 2017 at 08:52:15PM +0200, Maxime Villard wrote: > [stuff] If you insist on going on delete/disable sprees without discussing beforehand, can you at least, when doing these, go through and make sure the things you've removed don't leave behind dangling hooks in the main kernel? Or if they do, at least try to identify them? There was a namei special case in COMPAT_SVR4, and I'm not particularly unhappy to see the end of it, but I can't imagine it was the only such thing we're carrying around. -- David A. Holland dholl...@netbsd.org
